Группы запросов
На рис. 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 показана последовательность записей истории, выводимых в части событий отчета.
Читать дальше