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

16

Acquire blocks (Заблокированные запросы)

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

17

Spin count (Количество блокировок)

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

18

Mutex wait (Ожидание блокировок)

Процент попыток, которые были заблокированы, когда владелец старался обратиться к таблице блокировок - т.е. ((acquire blocks) / (acquires)) * 100

19

Hash slots (Сегменты хэша)

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

20

Hash lengths(Длина сегмента)

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

21

Remove node (Удаление узла)

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

22

Insert queue (Добавить очередь)

Эквивалент предыдущей схеме удаления узла, за исключением того, что здесь узел добавляется

23

Insert prior (Предыдущее добавление)

Для очистки ошибочного добавления необходимо знать не только, что было добавлено, но и где это размещалось. Это как раз где

24

Owners (Владельцы)

Количество владельцев, которые соединены с таблицей блокировок. Только один из этих владельцев может изменять таблицу в конкретный момент ("активный владелец"). Другие владельцы ожидают освобождения блокировок. В нашем примере существует четыре владельца, не являющихся активными. Два владельца подключены через isql; один может быть подключен через DSQL, а еще один - сама база данных

25

Free owners (Свободные владельцы)

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

26

Free locks (Свободные блокировки)

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

27

Free requests (Свободные запросы)

Группы запросов идентифицируют запросы на блокировки ресурсов, неважно, удовлетворенные или нет. Этот элемент является количеством групп запросов, которые были освобождены и не использованы повторно

28

Lock ordering (Порядок блокировок)

Порядок блокировок означает получение запросов на блокировку в порядке их поступления, даже если последующие запросы должны быть обслужены немедленно. Включено, если флаг LHB_lock_ordering (см. элемент 7) установлен, и является значением по умолчанию для Firebird, т. к. обеспечивает оптимальную производительность. Альтернативой является (не используется сейчас) предоставление блокировок всем владельцам, желающим совместно использовать и "подавлять" владельцев, которые имеют существующие запросы. Эта не используемая стратегия гарантирует, что участники будут обработаны быстро, однако с риском причинения вреда другим