Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

На рис. 40.7 показана группа ресурсов транзакции.

Рис. 40.7. Группа серии 4 (ресурсы транзакции)

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

Серии 5, 6 и 15: существование

На рис. 40.8 показаны группы блокировок существования для отношения.

Рис. 40.8. Серии 5, 6 и 15. Группы блокировок существования

Блокировки существования отношений (серия 5) предотвращают удаление таблицы, когда какой-нибудь процесс подготавливает запрос, который использует эту таблицу. Эта блокировка является источником ошибок "Object in use" (Объект находится в использовании), которая часто появляется при попытках удаления таблиц.

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

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

Эта блокировка существования отношения присутствует в отношении, которое имеет значением поля RDB$RELATION_ID 22.

Блокировки существования индексов предотвращают удаление или деактивацию индексов, когда другой процесс сохраняет запрос, использующий этот индекс.

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

Когда процесс собирается удалить или деактивировать индекс, он должен получить исключительную блокировку на существование этого индекса.

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

Идентификатор блокировки существования индекса 12 000, который равен идентификатору отношения, умноженному на 1000, плюс идентификатор индекса. Эта блокировка сообщает о заинтересованности в существовании индекса 0 для отношения 12.

Блокировки существования процедуры в точности аналогичны блокировкам существования отношения и индекса и служат аналогичным целям. Ключ является идентификатором процедуры из системной таблицы RDB$PROCEDURES.

Серия 8: теневая копия

На рис. 40.9 показаны группы блокировок ресурса теневой копии (shadow).

Рис. 40.9. Серии 8. Группы блокировок ресурса теневой копии

Каждый процесс, который подключается к базе данных, получает блокировку на совместное чтение на состояние теневого копирования базы данных. Если процесс собирается добавить новый файл теневой копии, он должен преобразовать его блокировку в исключительное состояние, что сообщает всем другим процессам о том, что появляется новый файл теневой копии и что они должны писать изменения в этот файл. Эта серия используется для общения между процессами в Классическом сервере. Она также используется в Суперсервере, хотя не при всех эффектах, когда не требуется IPC.

Группы запросов

На рис. 40.10 показаны некоторые группы запросов. В табл. 40.7 объясняется значение записей в группе запроса.

Рис. 40.10. Некоторые группы запросов

Таблица 40.7. Записи группы запросов

№

Значение

Объяснение

1

LOCK BLOCK

Идентифицирует конкретный запрос

2

Process (Процесс)

Смещение группы процесса, которая описывает процесс, выполнивший запрос

3

Lock (Блокировка)

Смещение группы блокировки, которая описывает блокируемый ресурс

4

State (Состояние)

Состояние блокировки, которое назначено этому ресурсу

5

Mode(Режим)

Состояние, которое было запрошено для блокировки. В первых двух примерах состояние (state) такое же, как и режим (mode). Это предоставленные блокировки. Первой был предоставлен режим защищенного чтения, второй - исключительный. В третьем примере находится в состоянии ожидания, следовательно, ее состояние 0 (нет блокировки), но режим 3 (защищенное чтение)

6

Flags (Флаги)

Флаг запроса содержит биты, которые могут комбинироваться. Это:

1: блокировка; 2: ожидание; 4: преобразование; 8: отмена

7

AST

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

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

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

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

8

Argument (Аргумент)

Адрес чего-либо, что может понадобиться подпрограмме AST. В случае BDB это адрес структуры в процессе, которая описывает буфер.

В случае блокировок базы данных и теневой копии это адрес главной группы (DBB), которая описывает базу данных

Группа истории

Менеджер блокировок отслеживает действия ввода/вывода, которые он выполнял для каждого владельца. Самые последние действия выводятся в виде двух последних элементов отчета- истории (History) и событий (Events). На рис. 40.11 показана последовательность записей истории.

Рис. 40.11. Вывод записей истории

Владельцу 11 628 предоставлена блокировка на ресурс 11 744. Владелец 12 056 ставит в очередь запрос на тот же ресурс, запрашивая его в режиме NO WAIT. Блокировка у владельца 11 628 находится в несовместимом режиме, следовательно, этому запросу будет отказано (DENY). Владелец 12 056 опять приходит и ставит в очередь другой запрос, снова запрашивая блокировку, но уже в режиме WAIT. Менеджер блокировок отправляет сообщения владельцу 11 628 по поводу ресурса 11 744. Как было сказано, владелец находится в состоянии ожидания. Через 10 секунд владелец 12 056 все еще в состоянии ожидания, поэтому Менеджер блокировок запускает сканирование взаимных блокировок. Это не дает никаких результатов, и Менеджер блокировок опять отправляет сообщения владельцу 11 628 (POST, POST, POST). В конце концов владелец 11 628 снимает блокировку, и она предоставляется владельцу 12 056.

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

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