OWN blocking
|
1
|
Владелец заблокирован. Если установлен, значит процесс имеет, по меньшей мере, один блок, который другой процесс не хочет совместно использовать
|
OWN scanned
|
2
|
Владелец был проверен в текущем сканировании взаимных блокировок
|
OWN manager
|
4
|
Системы, которые отключают сообщения между группами, имеют привилегированный Менеджер блокировок, который передает сообщения. Этот владелец является таким менеджером
|
OWN signal
|
8
|
Владелец должен был выдать сообщение, но не смог это сделать из-за ошибки, поэтому сигнал будет вызван менеджером блокировок
|
OWN wakeup
|
32
|
Владелец сообщил об освобождении блокировки
|
OWN starved
|
128
|
Может быть, этот поток завис. Зависание случается в многопоточной системе Solaris и означает, что владелец (процесс) выполнил более 500 неудачных попыток получения доступа к таблице блокировок для освобождения блока
|
OWN signaled
|
16
|
Предполагается, что сигнал был отправлен. Он обращается к флагу OWN ast flags, но был суммирован по OR с указанными флагами. Обратите внимание: похоже, что выведенное здесь шестнадцатеричное число 202 является ошибкой синтаксического анализатора
|
Группы блокировок (группы ресурсов)
Группы блокировок следуют после групп запросов в выходном протоколе, однако группы запросов будут проще в понимании, если мы вначале рассмотрим группы блокировок. Группа блокировок представляет блокируемый ресурс.
Типы блокировок"серии"
Блокировки ресурсов приходят различных типов или в виде серий в соответствии с типом ресурса, блокировку которого владельцы запрашивают у таблицы блокировок. В табл. 40.5 определяются и описываются различные типы блокировки ресурсов и их назначение.
Таблица 40.5. Типы ресурсов (серии)
Символ
|
Серия
|
Тип
|
LCK_database
|
1
|
Корень дерева блокировки. В Классическом сервере блокировка базы данных выполняется для каждого процесса, который соединяется с базой данных. Первый процесс получает исключительную блокировку. Следующий процесс сообщает о конфликте и сигнализирует первому о необходимости понижения уровня его блокировки от исключительной до уровня совместного использования. После этого все блокировки самой базы данных создаются для совместного чтения. В Суперсервере база данных получает на себя исключительную блокировку
|
LCK_relation
|
2
|
Индивидуальная таблица блокировки. Таблица блокировки указывает, что процесс читает и пишет в указанную таблицу в своей текущей транзакции или что он использует предложение RESERVING в операторе START TRANSACTION для сообщения своего намерения читать таблицу или писать в таблицу. В этой таблице ключевым полем является RDB$RELATION_ID. Заметьте, что оба запроса сообщают ее состояние как 2(2), указывая, что они запросили и получили блокировку на совместное чтение из таблицы
|
LCK_bdb
|
3
|
Индивидуальный блок буфера. Блокировка BDB является блокировкой страницы базы данных. Такие блокировки возводятся, когда два или более владельца соединяются с базой данных в Классическом сервере. Они устанавливаются, когда процесс собирается читать или писать страницу, и освобождаются, когда процесс завершает работу с буфером и требует освобождения памяти, или когда другому владельцу нужна эта страница
|
LCK_tra
|
4
|
Блокировка индивидуальной транзакции. Каждое действие получает исключительную блокировку для своей транзакции при ее старте. Другие владельцы могут получать пустую блокировку для чтения их состояния
|
LCK_rel_exist
|
5
|
Блокировка существования отношения. Предотвращает удаление таблиц, в то время как любые другие владельцы подготавливают запрос, который использует эту таблицу
|
LCK idx exist
|
6
|
Блокировка существования индекса. Предотвращает удаление или дезактивацию индекса, в то время как любые другие владельцы подготавливают запрос, который использует этот ресурс
|
LCK_attachment
|
7
|
Не используется. Блокировка соединения для поддержания блокировок записей dBase, которые могут присутствовать в пределах транзакции
|
LCK shadow
|
8
|
Блокировка для синхронизации добавления теневых копий (shadow). Главным образом для Классического сервера
|
Читать дальше