Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

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

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

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

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

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

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

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

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

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

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

Менеджер блокировок отслеживает действия ввода/вывода, которые он выполнял для каждого владельца. Самые последние действия выводятся в виде двух последних элементов отчета- истории (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) при доступе к ресурсу, записал свой идентификатор владельца в заголовочную группу блокировки, а затем был уничтожен, в то время как он все еще хранился в таблице блокировок. Однако вторая заголовочная группа блокировки должна иметь достаточно информации, чтобы позволить второму процессу отменить все действия, частично завершенные уничтоженным процессом.