2. Спускаясь вниз по уровню иерархии (таблица – файл данных – экстент – страница), менеджер помечает элементы блокировками IS, IX или SIX, соответственно, - пока не достигнет требуемого уровня иерархии. Благодаря этому новые блокировки на вложенные элементы данных уже не будут накладываться. Менеджер дождется момента, когда можно будет поставить соответствующие блокировки на нужные элементы данных, после чего снимет установленные блокировки намерения.
Информация о совместимости типов блокировок представлена в табл. 5.3. Символом «*» отмечается, что тип запрашиваемой блокировки совместим с типом наложенной.
Таблица 5.3 – Совместимость типов блокировок
Тип запрашиваемой блокировки |
Тип наложенной блокировки |
|||||
S |
U |
X |
IS |
IX |
SIX |
|
S |
* |
* |
||||
U |
* |
* |
||||
X |
||||||
IS |
* |
* |
* |
* |
* |
|
IX |
* |
* |
||||
SIX |
* |
В Microsoft SQL Server 2005 поддерживаются также два специализированных типы блокировок.
1. Блокировки на основе логического условия.
Решают проблему чтения фантомов.
2. Блокировки схемы.
Используются при выполнении команд DDL и решают проблему модификации структуры объекта БД несколькими пользователями одновременно. Типичный случай конфликтной ситуации: пользователь запускает команду ALTER TABLE, чтобы удалить столбец из некоторой таблицы. Но к этому времени другая транзакция уже наложила монопольную блокировку таблицы, чтобы произвести запись как раз в удаляемый столбец. Именно от подобного рода конфликтов и защищают блокировки схемы. Данный тип блокировок имеет два подтипа:
· блокировка стабильности схемы (запрещает модификацию структуры объекта БД, заблокированного транзакцией);
· блокировка модификации схемы (запрещает транзакциям блокировать объект во время изменения его структуры).
5.2.3. Тупиковые ситуации, методы их предотвращения и обнаружения
Если транзакция претендует на использование уже заблокированного ресурса, ее выполнение приостанавливается до момента разблокирования. При этом нередко складывается ситуация, когда две и более транзакций находятся во взаимном ожидании разблокирования данных, удерживаемых каждой из них, и в результате оказываются не способными продолжать свою работу. Такая ситуация называется тупиковой; альтернативные названия – взаимная блокировка или мертвая блокировка. Типичная схема возникновения тупиковой ситуации представлена в табл. 5.4: вначале останавливается выполнение транзакции T1, ожидающей разблокирования ресурса таблица_2; но транзакция T2, которая и заблокировала ресурс таблица_2, не может завершиться, так как ей нужно прочитать строки из таблицы_1, заблокированной ранее транзакцией T1.
Таблица 5.4 – Пример тупиковой ситуации
Время |
Транзакция T1 |
Транзакция T2 |
t1 t2 t3 t4 t5 t6 |
начало_транзакции запись(таблица_1) ………………. чтение(таблица_2) ожидание ожидание |
начало_транзакции запись(таблица_2) …………………. чтение(таблица_1) ожидание |
Выход из сложившейся тупиковой ситуации может быть только один: принудительный откат одной или более транзакций, участвующих во взаимной блокировке. Если в приведенном примере принудительно завершить транзакцию T2, ресурс таблица_2 разблокируется, и транзакция T1 сможет прочитать нужные данные и завершиться; транзакцию T2 нужно будет перезапустить после завершения T1.
Предупреждение тупиковых ситуаций
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.