Модели блокировок в базах данных

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

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

Монопольный доступ обычно используется в двух случаях:

• во-первых, когда требуется исключить доступ к объектам со стороны других пользователей (например, при работе с конфиденциальной информацией);

• во-вторых, когда производятся ответственные операции с БД, не допус­кающие других действий, например, изменение структуры БД.

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

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

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

Процессор базы данных обеспечивает три уровня блокировок:

· Блокировка базы данных. На этом уровне блокировки к Базе Данных может обращаться только один пользователь. Такой уровень блокировки применяется для глобального изменения или обновления данных или при техническом обслуживании Базы Данных- сжатии;

· Блокировка таблицы. На этом уровне блокировки к таблице может обращаться только один пользователь. Такой уровень блокировки применяется в тех случаях, когда необходимо обработать сразу несколько записей таблицы.

· Блокировка страницы. На этом уровне к заблокированной странице может обращаться только один пользователь. Это самый нижний уровень блокировки.

Тупики

Если не управлять доступом к совместно используемым объектам, то меж­ду потребителями ресурсов могут возникать тупиковые ситуации (клинчи, «смертельные объятия» или блокировки). Следует отличать понятие блоки­ровки в смысле контроля доступа к объектам (мы придерживаемся такого термина) от блокировки в смысле тупикового события.

Существует два основных вида тупиков: взаимные (deadlock) и односто­ронние (livelock).

Простейшим случаем взаимного тупика является ситуация, когда каждый из двух пользователей стремится захватить данные, уже захваченные другим пользователем (рис. а). В этой ситуации пользователь-1 ждет освобождения ресурса N, в то время как пользователь-2 ожидает освобождения от захвата ре­сурса М. Следовательно, никто из них не может продолжить работу.

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

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

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

Пользователи и разработчики приложений в распределенной среде долж­ны предусматривать обработку сигналов о тупиках.