Протокол преднамеренной блокировки

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

В основе протокола лежит следующая идея. Перед выполнением операции над кортежем r, входящим в состав отношения R, транзакция запрашивает захват R в некотором специальном режиме. Если этот запрос удовлетворён, то запрашивается захват r в режиме S или X, в зависимости от вида операции. Например, если транзакция намерена обновить значения атрибута в кортеже отношения, она должна заблокировать это отношение в режиме, допускающем использование отношения как объекта в других транзакциях. Получив нужную блокировку отношения, она должна заблокировать обновляемый кортеж в монопольном режиме.

Блокировка может осуществляться в одном из пяти режимов:

IS (Intent for Shared lock) – блокировка отношения (объекта верхнего уровня) с намерением разеляемого захвата его кортежей (объектов нижнего уровня);

IX (Intent for eXclusive lock) – блокировка отношения с намерением монопольного захвата его кортежей;

S (Shared lock) – блокировка отношения или кортежа (объекта любого уровня) в разделяемом режиме;

SIX (Shared Intent for eXclusive lock) – блокировка отношения с намерением как разделяемого, так и монопольного захвата его кортежей;

X (eXclusive lock) – блокировка отношения или кортежа в разделяемом режиме.

В общем случае уже знакомые нам режимы блокировки S и X могут применяться к объектам любого уровня, а новые – только к составным объектам.

Захват отношения в режиме IS осуществляется для выполнения операции чтения кортежей из отношения. Считываемые кортежи будут захвачены в режиме S.

Отношение захватывается в режиме IX, если транзакция будет не только считывать, но и обновлять или удалять некоторые его кортежи. Считываемые кортежи будут захвачены в разделяемом режиме, а обновляемые – в монопольном режиме. При этом другие транзакции также могут выполнять операции выборки и обновления кортежей этого отношения по обычным правилам блокировки.

Наконец, режим SIX подобен IX, но операции обновления кортежей может выполнять только транзакция, захватившая отношение в этом режиме.

Ниже приводится таблица совместимости преднамеренных блокировок.

Таблица 5.2 – Совместимость преднамеренныхблокировок

	X	SIX	IX	S	IS
X	нет	нет	нет	нет	нет
SIX	нет	нет	нет	нет	да
IX	нет	нет	да	нет	да
S	нет	нет	нет	да	да
IS	нет	да	да	да	да

Сформулируем теперь протокол преднамеренной блокировки.[4]

· Если транзакции необходимо захватить кортеж r отношения R в режиме S, она должна предварительно захватить отношение R в режиме IS или более сильном.

· Если транзакции необходимо захватить кортеж r отношения R в режиме X, она должна предварительно захватить отношение R в режиме IX или более сильном.

Блокировка L2 является более сильной по отношению к блокировке L2 тогда и только тогда, когда она конфликтует со всеми блокировками, конфликтующими с L2. Например, S сильнее IS, а SIX сильнее S и IX.

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

Тупиковые ситуации

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

Пример. Пусть транзакции Т1 и Т2 установили монопольные захваты объектов О1 и О2 соответственно. После этого Т1 запросила захват О2, а Т2 – захват О1. Обе транзакции «зависнут».

Никакого естественного выхода из тупиковых ситуаций не существует. Поэтому система должна уметь их обнаруживать и устранять. Многие промышленные СУБД используют для этого граф ожидания транзакций.

Граф ожидания транзакций – это двудольный ориентированный граф. Вершины типа Т соответствуют действующим в текущий момент времени транзакциям, вершины типа О – объектам захвата. Если для транзакции заблокирован объект, то существует дуга графа, ведущая из соответствующей Т -вершины в соответствующую О -вершину. Если транзакция ожидает удовлетворения запроса на блокировку объекта, то в графе существует противоположно ориентированная дуга.

Тупиковая ситуация в графе ожидания транзакций представляется циклом. Так, в примере графа ожидания, приведённом на рис. 5.2, существует цикл Т2 – О5 – Т4 – О4 – Т2. Следовательно, транзакции Т2 и Т4 «висят».

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

Рис. 5.2 Граф ожидания транзакций

Приложение, запустившее транзакцию-жертву, получает сообщение о возникшей ситуации и может обработать её своими средствами. Некоторые системы предусматривают автоматический перезапуск прерванной транзакции.

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

Восстановление состояния БД

Типичные разрушения данных

Ситуации, в результате которых база данных может оказаться в несогласованном состоянии, перечислены в п. 5.1. Обсудим их здесь подробнее.

Локальный сбой ­– это аварийное прекращение транзакции. Причиной может быть, например, попытка деления на ноль или нарушение ограничений целостности, или тупиковая ситуация. В этот же ряд следует поставить явное завершение транзакции оператором ROLLBACK. Если транзакция выполняла обновление данных, то состояние БД в момент локального сбоя окажется несогласованным. Для восстановления целостности данных необходимо устранить изменения данных, произведённые прерванной транзакцией – произвести индивидуальный откат транзакции.

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

Жёсткий сбой – это физическое разрушение базы данных. Ситуация весьма маловероятная, но её последствия для организации–владельца данных всегда катастрофические. Поэтому система должна быть в состоянии восстановить базу данных даже в этом случае.