10.4. Проблемы параллелизма и пути их решения

10.4.1. Параллелизм

При параллельном выполнении операций над базой данных мо­гут возникать некоторые проблемы. Одна из них - проблема утра­ченных (потерянных) обновлений (Lost update) - заключается в том, что если пользователи параллельно обновляют одни и те же данные, то запомненным будет то обновление, которое было проведено по­следним. Остальные обновления будут потеряны (рис. 10.4).

Другая проблема - зависимость от незафиксированных обновлений - состоит в том, что пользователь А может увидеть данные, кото­рые уже были обновлены пользователем В, но эти обновления еще не были окончательно зафиксированы. Далее пользователь В может в силу [различных причин, например из-за выявленных ошибок ввода, провести откат базы данных в исходное состояние (рис. 10.5). Пользо­ватель А в этом случае будет предпринимать действия над ошибоч­ными (данными. Иногда для такого рода проблем используется тер­мин преждевременное чтение (Dirty read).

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

Эта ситуация не приводит к искажению информации в базе дан­ных и поэтому в некоторых ситуациях считается допустимой, Напри­мер в случае, если специалист проектирует форму отчета и в этом процессе получает черновые отчеты.

10.4.2. Блокировки

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

Обобщенная схема классификации блокировок приведена на рис. 10.6.

Блокировки накладываются в соответствии с правилами совмес­тимости блокировок, исключающими конфликты чтение-запись, запись-чтение и запись-запись. Сериализуемость транзакций заведомо гарантируется, если блокировки, относящиеся к одновременно вы­полняемым транзакциям, удовлетворяют следующему правилу: «Ни одна блокировка от имени какой-либо транзакции не должна уста­навливаться, пока не будет снята ранее установленная блокировка». Это правило известно под названием двухфазового блокирования, поскольку транзакция проходит при этом сначала фазу роста, когда она устанавливает блокировки, а затем фазу сжатия, когда блоки­ровки снимаются. В общем случае снятие блокировок до завершения транзакции проблематично, поэтому в большинстве алгоритмов уп­равления одновременным доступом применяется подход, когда бло­кировки не снимаются до конца транзакции.

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

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

Бывает, что уровни блокирования определяются в терминах фи­зических единиц информации. Уровень блокирования может зависеть не только от СУБД, но и от операционной системы и даже от архитек­туры компьютера. В этом случае необходимо знать специфику конк­ретной платформы, на которой реализована система. Объектами бло­кирования могут являться страница (page), группа страниц, область базы данных (dbspace) и др. Терминология и реализация в значитель­ной степени зависят от конкретной системы.

Физическая единица может включать как часть таблицы, так и несколько разных таблиц. Все это скажется на частоте возникнове­ния конфликтов и времени обработки, что необходимо учитывать при физическом проектировании БД и при управлении параллельным доступом.

В конкретных СУБД могут быть реализованы не все, а только не­которые из перечисленных уровней блокировок. Так, практически нигде не реализована блокировка на уровне поля. В Microsoft SQL Server только начиная с версии 6.5 был добавлен уровень блокировки записи, и то только для операций типа INSERT. В dBase, FoxPro предусматривается блокировка на уровне таблиц и записей.

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

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

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

Оптимистические блокировки разрешают параллельное выпол­нение транзакций, отслеживают случаи возникновения конфликтов и обеспечивают их разрешение.