MS Access (MDB) concurrency

Ответ 1

Это старый вопрос, но на него никто никогда не отвечал. Вот вопросы:

• Как параллельные чтения обрабатываются в MDB?
• Как параллельные обновления/удаления обрабатываются в MDB?
• Есть ли концепция блокировок и как я могу использовать ее в .NET-приложении?
• Помещает ли файл MDB в сетевой ресурс хорошей или ужасной идеей?

На первые два вопроса можно ответить на одно объяснение. Один из ключевых моментов здесь: ответы, которые я даю здесь, специфичны для Jet MDB (и их вариантов) и не полностью применяются к новому файловому формату, представленному начиная с A2007, то есть в формате ACCDB. Я не полностью изучил последствия удаления Jet ULS из ACE, и некоторые из комментариев ниже могут принять Jet ULS под капотом. Однако для многих вещей вы можете заменить "файл LACCDB" на "файл LDB", и результаты будут одинаковыми.

1-2) Параллельные чтения/обновления/удаления

Механизм базы данных Jet часто упоминается как база данных "файлового сервера", поскольку на стороне сервера нет демона, управляющего ввода-вывода, с файлами данных на сервере. Это означает, что все клиенты, использующие Jet MDB, напрямую читают файл.

Это, конечно же, рецепт катастрофы, если не существует какого-либо механизма для обработки параллельного доступа к файлу.

Jet использует файл блокировки записи, где, если ваш MDB является "MyFile.MDB", файл блокировки записи будет находиться в той же папке и называется "MyFile.LDB". Файл LDB записывает, какие пользователи Jet ULS открывают файл MDB, с какой рабочей станции подключен пользователь, и всю информацию, необходимую для обсуждения проблем concurrency.

Теперь, для тех, кто режет свои зубы на клиентских/серверных СУБД, это может показаться примитивным и опасным, но в то время, когда был создан движок базы данных Jet, его цель заключалась в использовании в качестве механизма базы данных для настольных компьютеров для небольших рабочих групп, и он конкурировал с другими операционными системами db, такими как xBase и Paradox, оба из которых использовали аналогичные файлы блокировки для управления одновременным использованием файлов данных из нескольких клиентов.

В файле базы данных Jet блокировки применяются либо на страницах данных (которые в Jet 4 были увеличены до 4K, тогда как в Jet 3.x и ранее они были 2K) или на уровне записи, если таблица данных была изначально созданный для использования блокировки уровня записи. В первые дни Jet 4 блокировка уровня записи была обнаружена многими довольно медленно, особенно при использовании пессимистической блокировки, поэтому многие разработчики Access никогда не использовали ничего, кроме блокировки на уровне страницы (@David Fenton поднимает руку!).

Фактически, при использовании оптимистической блокировки вы избегаете большинства проблем concurrency, которые будут иметь пессимистическую блокировку.

Некоторые оговорки:

• от DAO, блокировка уровня записи недоступна, и вы только когда-либо получаете блокировку на уровне страницы.

• из DAO существует несколько вариантов управления оптимистичной/пессимистической блокировкой, в частности аргумент LockEdits метода OpenRecordset, но также взаимодействует с некоторыми параметрами, указанными в аргументе OpenRecordset Options (например, Опция dbReadOnly не может использоваться с LockEdits). В дополнение к блокировке существуют также варианты для согласованных/несогласованных обновлений, и все это может взаимодействовать с транзакциями (например, изменения в рамках незавершенной транзакции не будут отображаться для других пользователей и, таким образом, не будут конфликтовать с ними, но это может помещать блокировки только для чтения в соответствующие таблицы).

От ADO/OLEDB эти управляющие структуры Jet concurrency будут отображены на соответствующие функции и аргументы, найденные в ADO/OLEDB. Поскольку я использую Jet только из Access, я взаимодействую с ним только через DAO, поэтому я не могу сообщить, как вы управляете ими с помощью ADO/OLEDB, но дело в том, что механизм базы данных Jet предлагает управлять блокировкой записи при доступе к ней программным способом (в отличие от интерфейса доступа) - это еще сложнее.

3) Замки и .NET

Я не могу предлагать какие-либо рекомендации здесь, кроме того, что вы, вероятно, будете использовать OLEDB в качестве вашего интерфейса данных, но дело в том, что функциональность блокировки/управление есть в самом устройстве db, поэтому существует вероятность того, что контролируйте его через OLEDB. Это может быть не очень красиво, хотя, как мне кажется, OLEDB спроектирован вокруг архитектур клиент/сервер, а блокировка на основе файлов Jet может не отображаться на нем элегантным способом.

4) MDB на сетевом ресурсе

Jet очень чувствителен к малейшей икоте в любом сетевом соединении. Из-за этого сети с малой пропускной способностью могут увеличить уязвимость баз данных Jet, открытых через медленное соединение.

Это связано с тем, что основные фрагменты файла базы данных необходимо перетащить через провод в RAM локального компьютера для обработки. Теперь многие люди ошибочно утверждают, что весь файл MDB вытаскивается через провод, или все целые таблицы вытягиваются через провод. Это неправда. Вместо этого Jet сначала запрашивает индексы (и запрашивает не более, чем необходимо для выполнения запроса), а затем из этого результата точно определяет, какие страницы данных нужны, а затем тянет только эти страницы. Это удивительно эффективно и быстро.

Кроме того, Jet делает очень умное кэширование, что может означать, что первый запрос данных может занять некоторое время, но последующие запросы на одни и те же данные происходят почти мгновенно из-за кеширования.

Теперь, если вы не хорошо проиндексировали свои таблицы, вы можете в конечном итоге вытащить всю таблицу и выполнить полное сканирование таблицы. Аналогично, если вы основываете критерии на клиентских функциях, которые не являются частью диалекта Jet SQL, вы можете в конечном итоге вытащить полную таблицу (сортировка, скажем, Replace (MyField, "A", "Z" ), вероятно, вызовет полное сканирование таблицы). Но такие вещи также будут неэффективны с архитектурой клиент/сервер, так что это просто схема схемы с понятным интерфейсом, чтобы правильно индексировать вещи и быть осторожным с использованием UDF или не-Jet-совместимых функций. В общем, те же самые вещи, которые эффективны с клиентом/сервером, будут эффективны с Jet (главное отличие в том, что с Jet вам лучше работать с постоянным подключением, чтобы избежать накладных расходов на воссоздание LDB файла, что является значительным).

Другая вещь, которую следует избегать, - это использовать данные Jet через соединение WiFi. Мы все знаем, насколько ненадежным является WiFi, и он просто просил проблемы с работой с данными Jet через WiFi-соединение.

Нижняя строка:

Если вы используете MDB в качестве хранилища данных для обслуживания данных с веб-сервера, вы должны поместить данные как можно ближе к ОЗУ веб-сервера. Это означает, что, если это возможно, на том диска, который подключен к физическому веб-серверу. Если это невозможно, вам нужно быстрое и надежное подключение к локальной сети. ГБ LAN в центрах обработки данных довольно распространены в наши дни, и мне было бы очень комфортно работать с данными Jet в этом соединении.

Для совместного использования, например, нескольких клиентских рабочих станций, работающих с настольным приложением VB.NET, использующим один Jet MDB в качестве хранилища данных, довольно безопасно иметь файл данных на надежном файловом сервере. Там, где это возможно, рекомендуется размещать файлы Jet MDB на компьютерах, которые не обслуживают несколько целей (например, ваш контроллер домена, на котором работает Exchange, SQL Server и действующий как файловый сервер и сервер печати, может оказаться не лучшим местом), Такие приложения, как Exchange, могут плохо влиять на функциональность файлового сервера, и я обычно рекомендую никогда не помещать файлы MDB на многозадачный сервер в качестве сервера Exchange, если только он не очень мал.

Другие соображения:

• никогда не пытайтесь распространять MDB на реплицированную файловую систему, если только все пользователи не используют одну и ту же реплика. То есть, если у вас есть два сервера, которые реплицируют файлы между ними, даже не думайте об изменении файла MDB с обоих серверов. Это приведет к повреждению файла почти сразу.

• Я бы рекомендовал не хранить любой MDB на чем-либо, кроме собственной файловой системы Windows, обслуживаемой через собственные сетевые SMB-сети. Это означает, что Novell, ни Linux, ни SAMBA. Основная причина этого заключается в том, что, по-видимому, есть крючки низкого уровня от Jet до некоторых функций блокировки низкого уровня в файловой системе Windows, которые не реплицируются на 100% в другой файл systsm. Теперь я очень консервативен в этом отношении, и многие компетентные разработчики Access сообщили о превосходных результатах с правильно настроенными файловыми серверами Novell (часто должны быть какие-то корректировки блокировки записи, хотя это может быть менее актуальным в наши дни - я не знаю даже не знаю, существует ли Novell больше!) и потрясающая производительность с файловыми серверами на базе Linux, работающими под управлением SAMBA. Я осторожно отношусь к этому и рекомендую против него любой клиент (это также различные устройства SAN, так как не многие из них основаны на Windows).

• Я бы никогда не запускал их в любой виртуализованной файловой системе по тем же причинам. Тем не менее, у меня есть клиент, который уже несколько лет запускает однопользовательское приложение Access под Parallels на Mac Air без каких-либо проблем. Но он однопользовательский, поэтому проблемы с блокировкой будут относительно незначительными.

Я не знаю, отвечает ли это на ваши вопросы или нет. Все это основано на моем 13-летнем регулярном использовании Jet в качестве разработчика доступа и изучении единственной опубликованной книги по Jet, Руководство программистов Jet Database Engine (только для Jet 3.5). Я не представил никаких реальных ссылок, но если кто-то нуждается в некоторых деталях во всем, что я сказал, я сделаю исследование, если смогу.

Ответ 2

В течение многих лет я создал дюжину небольших приложений для бизнеса. Большинство из них имеют максимум 10-20 пользователей одновременно. Базы данных разделяются между базой данных "приложение" и "данные". Производительность достойная и никаких проблем с совпадением. Также коррупция была в основном несуществующей с Access 2000 SP2.

Есть много людей, говорящих "никогда не пользуйтесь Access" - хорошо, если это делается правильно (т.е. профессиональным разработчиком). Доступ - довольно прекрасный пакет разработки, и я хорошо поработал над этим. Мои клиенты очень довольны тем, что я построил.

Ответ 3

Я написал два коммерческих продукта, которые используют базу данных Access, работающую от общего сетевого ресурса, как правило, до 10 пользователей. Если вы не злоупотребляете им, проблем нет; но, как вы можете видеть, многие разработчики никогда туда не попадают - и из-за своей низкой природы, на нем построено много дерьмовых хаков. В случае одного продукта мне пришлось перепроектировать приложение из-за всех проблем, подробно описанных другими; но после того, как я его очистил, у меня никогда не было проблемы с целостностью базы данных на сотнях установок.

Его одно большое преимущество - это единственная файловая база данных, которую легко создать резервную копию, восстановить и скопировать на ваш ноутбук, чтобы ее можно было анализировать. Практически все альтернативы, в том числе sqlite (хотя некоторые из них этого не допустят), время от времени требуют какой-то формы внимания DBA.

В большинстве случаев Access обеспечивает блокировку записи и блокировки файлов для некоторых DDL (например, изменений схемы) по умолчанию.

Но Microsoft в основном переустанавливает его, а некоторые из ваших коллег будут презирать вас за его использование.

(В этот момент я обычно уклоняюсь за обложку и кричу "ВХОДЬ!!!".)

Ответ 4

Доступ - это настольное решение с одним пользователем. На практике он имеет верхний предел пользователя "один".

Это также локальный движок. То есть, когда вы запускаете запрос, данные передаются по сети на локальный движок JET для обработки. Файл .ldb помещается в общий сетевой ресурс для управления блокировками.

Если вы используете серверный механизм (MSSQL, MySQL, Sybase, Orable и т.д.), вы отправляете запрос движку, который обрабатывает его и возвращает результаты. Замки удерживаются внутри.

Это имеет огромное значение для производительности, стабильности и целостности данных.

Если ваш пользователь решил нажать кнопку reset, у базы данных Access есть вероятность, что вы будете повреждены, и вам придется удалить .ldb.

С надлежащим механизмом базы данных (MSSQL, Sybase, Orable: мне не нравятся резервные копии MySQL), тогда у вас также есть возможность резервного копирования. Если у вас нет какого-либо свистящего программного обеспечения для резервного копирования inuse файлов, возможно, у вас не будет резервных копий ваших данных в базе данных доступа.

Я упоминал блокировки специально, потому что движок db может обрабатывать concurrency и транзакцию гораздо эффективнее и элегантнее, чем любая файловая система.

Я вижу, что использование проекта Access как front-end для механизма базы данных, но не вложение в полное клиентское приложение с бэкэндом Access.

Ответ 5

Я использую Access или, вернее, Jet, как back-end на очень маленьком частном сайте, который никогда не может расти, поскольку он ограничен размером профессии в этой маленькой стране. Через три года у меня не было никаких проблем. Менее чем 100 пользователей, каждый день их используют от тридцати до сорока. Таблицы содержат несколько тысяч записей.

Ответ 6

У меня нет большого опыта работы с Access, но эта ссылка может быть вам полезна:

http://office.microsoft.com/en-us/access/HP052408601033.aspx

"Вы можете поместить всю базу данных Access на сетевой сервер или в общую папку. Это самый простой способ для реализации. Каждый использует данные и использует те же формы, отчеты, запросы, макросы и модули. если вы хотите, чтобы все использовали базу данных Access так же или если вы не можете поддерживать пользователей, создающих свои собственные объекты".

"Когда вы открываете файл базы данных Access (.mdb) в режиме совместного доступа, Microsoft Access также создает файл информации о блокировке (.ldb) с тем же именем файла (например, Northwind.ldb) и в той же папке, что и файл базы данных. Этот файл блокировки хранит имя компьютера (например, mypc) и имя безопасности (например, Admin) каждого общего пользователя базы данных. Microsoft Access использует эту информацию для управления concurrency. В большинстве случаев Microsoft Access автоматически удаляет файл информации о блокировке, когда последний пользователь закрывает файл базы данных."

Ответ 7

Доступ должен быть многопользовательским - я думаю, что Microsoft рекомендует его для 4 или 5 пользователей, но на практике я бы рекомендовал вам никогда не использовать базу данных Access, где есть более одного пользователя, хотя если у вас действительно нет выбора, приемлемого для двух или трех, учитывая определенные оговорки.

У меня был опыт работы с четырьмя или пятью системами с использованием базы данных Access Access - все они получены от других разработчиков, и во всех случаях я перенес их на SQL Server в качестве приоритета после любых мгновенных обновлений и исправления, необходимые при принятии контракта - как правило, как только я мог поговорить с боссом, оплачивающим счет. Временной интервал для этого обычно составляет несколько месяцев, поэтому я видел, что он работает параллельно в течение разумного промежутка времени в нескольких разных приложениях.

На самом деле, как правило, он работает неплохо, если система не имеет много параллельных вставок/обновлений и не используется в значительной степени. Основные практические проблемы в моем опыте - это...

• Это подлежит коррупции - это просто так. Как правило, это не слишком большая проблема, так как открытие файла и работа компактного и ремонта будут устранять проблемы, но хороший резервный режим абсолютно необходим.

• Это медленно. Каждый раз, когда я обновлял систему до SQL Server, я получил много наград за ускорение работы системы от пользователей.

• Файл базы данных вздувается из-за того, что метки доступа записываются как обновленные или удаленные. Это еще больше замедляет работу системы, так как файл должен загружаться по сети. Следовательно, необходим какой-то режим, который сжимает данные, как правило, ежедневно.

Все вышеперечисленное представляет собой гораздо более сложную проблему с однопользовательскими системами, поскольку основные проблемы, которые подсказывают, что они намного менее заметны.

В целом я должен подчеркнуть, что никогда не рекомендую Access для любой многопользовательской системы. Однако, если это действительно так, вы, вероятно, избегаете этого, пока это легко применяемое приложение, и вы устанавливаете процедуры резервного копирования и обслуживания.

Ответ 8

При работе с сетевым ресурсом я бы пошел с сетевой базой данных (mysql/firebird/mssql) вместо доступа.

В ситуации, описывающей использование Access, не будет проблемой.

Я использовал Access в более сложных ситуациях, тогда это чаще всего при работе с веб-сайтами, когда Access не подвергается злоупотреблениям, это не так уж плохо для механизма базы данных. (не говоря о формах и т.д. только таблицы и записи)

Когда вы делаете вставляете/обновляете/удаляете несколько пользователей одновременно, он становится немного волосатым. Это тот момент, когда вы начинаете думать о реальных механизмах баз данных.

Кроме того, если вам нужна небольшая накладная база данных, которая является потокобезопасной, вы можете посмотреть vistadb (медленнее, затем доступ, а не всегда бесплатно, 100%.NET)

Я думаю, что доступ использует блокировки на уровне таблицы с каким-то механизмом покоя, которые должны работать нормально. Если вы беспокоитесь об этом, вы всегда можете бросить имитационный стресс-тест.

Ответ 9

Я думаю, вы можете определить его в своей строке подключения приложения .net. Я googled для JET, доступ и запись блокировки

здесь ссылка, которая может помочь.

Пожалуйста, см. принятый ответ для получения подробной информации о том, как Access и JET получают данные.

Ответ 10

Уже несколько раз было сказано использовать реальную многопользовательскую бесплатную платформу базы данных. Но одна из причин, почему это не было заявлено. Эта причина заключается в том, сколько существующих, грязных, проблемных, больших баз данных Access началось как "несколько записей, один или два пользователя max"? Я бы рискнул сказать им все.

Если у всей компании всего два или три сотрудника, вероятность того, что если вы разработаете полезную часть программного обеспечения, она в конечном итоге будет использоваться более, чем у двух или трех оригинальных пользователей, имеет больше, чем оригинал несколько тысяч записей, и с течением времени расширится, включив в него множество форм, множество других таблиц и многое другое. Вы не можете переделать фундамент дома, как только дом будет построен. Создайте прочный фундамент сегодня, и вы можете расширить дом до вашего сердца. То же самое для программного обеспечения.

Ответ 11

Пожалуйста, не используйте Access для многопользовательского сценария.

Я только что пережил две недели боли, потому что мой предшественник в проекте выбрал Access как задний конец.

Конкретные причины:

• Нет такой вещи, как Linq-to-Access
• Доступ имеет множество причуд, подобных зависимостям, от порядка добавления параметров к командам, которые потребуют от вас времени для отладки
• Доступ не масштабируется.
• Обновления баз данных - это сложность по сравнению с использованием SQL Server