Эскалация блокирования

Когда происходит эскалация блокирования, система увеличивает размер блокируем1х объектов. Примером может служить блокирование системой всей таблицы вместо 100 отдельных ее строк. В результате одной блокировкой удерживается намного больше данных, чем перед эскалацией. Эскалация блокирования часто используется в СУБД, когда требуется избежать лишнего расходования ресурсов.

В СУБД Oracle никогда не применяется эскалация блокирования, однако выполняется преобразование блокировок (lock conversion) или распространение блокировок (lock promotion). Эти термины часто путают с эскалацией блокирования.

Термины преобразованиеблокировок и распространениеблокировок - синонимы. Вконтексте Oracle обычно говорят о преобразовании.

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

Если установлено ограничение ON DELETE CASCADE и подчиненная таблица не проиндексирована. Например, таблица EMP является подчиненной по отношению к DEPT. Оператор DELETE DEPTNO = 10 должен вызвать каскадное удаление (CASCADE) соответствующих строк в таблице EMP. Если столбец DEPTNO в таблице ЕМР не проиндексирован, придется выполнять полный просмотр (full table scan) таблицы ЕМР. Полный просмотр обычно нежелателен, поскольку при удалении большого количества строк из главной таблицы приводит к большим расходам времени и ресурсов.

При выполнении запроса из главной таблицы в подчиненную. Вернемся опять к примеру с таблицами ЕМР и DEPT. Очень часто таблица ЕМР запрашивается с учетом DEPTNO. Если постоянно для генерации отчета выполняется, например, следующий запрос, то отсутствие индекса замедлит работу:

select * from dept, emp

where emp.deptno = dept.daptno and dept.deptno = :X;

Итак, когда индекс по внешнему ключу не нужен? В общем случае, когда выполнены следующие условия:

не удаляются строки из главной таблицы;

не изменяется значение уникального/первичного ключа главной таблицы (следите за непреднамеренным обновлением первичного ключа используемыми инструментальными средствами!);

не выполняется соединение главной и подчиненной таблиц (как в случае с DEPT

и ЕМР).

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

Типы блокировок

Ниже перечислены пять основных классов блокировок в Oracle. Первые три - общие (используются во всех базах данных Oracle), а две остальные - только в OPS (Oracle Parallel Server - параллельный сервер). Специфические блокировки OPS мы рассмотрим лишь вкратце, зато общие блокировки - очень подробно.

Блокировки ЯМД (DML locks). ЯМД означает язык манипулирования данными (Data Manipulation Language), т.е. операторы SELECT, INSERT, UPDATE и DELETE. К блокировкам ЯМД относятся, например, блокировки строки данных или блокировка на уровне таблицы, затрагивающая все строки таблицы.

Блокировки ЯОД (DDL locks). ЯОД означает язык определения данных (Data Definition Language), т.е. операторы CREATE, ALTER и так далее. Блокировки ЯОД защищают определения структур объектов.

Внутренние блокировки (internal locks) и защелки (latches). Это блокировки, используемые сервером Oracle для защиты своих внутренних структур данных. Например, разбирая запрос и генерируя оптимизированный план его выполнения, сервер Oracle блокирует с помощью защелки библиотечный кэш, чтобы поместить в него этот план для использования другими сеансами. Защелка - это простое низкоуровневое средство обеспечения последовательности обращений, используемое сервером Oracle, и по функциям аналогичное блокировке.

Берется блокировка самого низкого из возможных уровней (наименее ограничивающая блокировка) и преобразуется к более высокому (ограничивающему) уровню. Например, при выборе строки из таблицы с конструкцией FOR UPDATE будет создано две блокировки. Одна из них устанавливается на выбранную строку (или строки); это - исключительная блокировка: ни один сеанс уже не сможет заблокировать соответствующие строки в исключительном режиме. Другая блокировка, ROW SHARE TABLE (совместное блокирование строк таблицы), устанавливается на соответствующую таблицу. Это предотвратит исключительную блокировку таблицы другими сеансами и, следовательно, возможность изменения, например, структуры таблицы. Все остальные операторы смогут работать с таблицей. Другой сеанс может даже сделать таблицу доступной только для чтения с помощью оператора LOCK TABLE X IN SHARE MODE, предотвратив тем самым ее изменение. Однако этот другой сеанс не должен иметь права предотвращать изменения, которые уже происходят. Поэтому, как только будет выполнена команда фактического изменения строки, сервер Oracle преобразует блокировку ROW

SHARE TABLE в более ограничивающую блокировку ROW EXCLUSIVE TABLE, и

изменение будет выполнено. Такое преобразование блокировок происходит само собой независимо от приложений.

Эскалация блокировок - не преимущество базы данных. Это - нежелательное свойство. Тот факт, что СУБД поддерживает эскалацию блокировок, означает, что ее механизм блокирования расходует слишком много ресурсов, что особенно ощутимо при управлении сотнями блокировок. В СУБД Oracle расходы ресурсов в случае одной или миллиона блокировок одинаковы, - ресурсы просто не расходуются.

Распределенные блокировки (distributed locks). Эти блокировки используются сер-

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

Блокировки параллельного управления кэшем (PCM - Parallel Cache Management Locks). Такие блокировки защищают блоки данных в кэше при использовании их несколькими экземплярами.

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

Блокировки ЯМД

Блокировки ЯМД позволяют гарантировать, что в каждый момент времени только одному сеансу позволено изменять строку и что не может быть удалена таблица, с которой работает сеанс. Сервер Oracle автоматически, более или менее прозрачно для пользователей, устанавливает эти блокировки по ходу работы.

ТХ - блокировки транзакций

Блокировка ТХ устанавливается, когда транзакция инициирует первое изменение, и удерживается до тех пор, пока транзакция не выполнит оператор COMMIT или ROLLBACK. Она используется как механизм организации очереди для сеансов, ожидающих завершения транзакции. Каждая измененная или выбранная с помощью SELECT FOR UPDATE строка будет указывать на соответствующую блокировку ТХ. Казалось бы, это должно повлечь большие расходы ресурсов, но на самом деле этого не происходит. Чтобы понять, почему, необходимо разобраться, где живут блокировки и как сервер ими управляет. В Oracle блокировки хранятся как атрибут данных (см. описание формата блока Oracle в главе 2). У сервера Oracle нет традиционного диспетчера блокировок, поддерживающего длинный список со всеми строками, заблокированными в системе. Другие СУБД делают именно так, поскольку для них блокировки - дорогостоящий ресурс, за использованием которого надо следить. Чем больше блокировок, тем сложнее ими управлять, отсюда и заботы о том, не слишком ли много блокировок используется в системе.

Если бы сервер Oracle имел традиционный диспетчер блокировок, при блокировании строки нужно было бы выполнить примерно такую последовательность действий.

1. Найти адрес строки, которую необходимо заблокировать.

2. Подключиться к диспетчеру блокировок (необходимо выполнять по очереди, поскольку используются общие структуры в памяти.)

3. Заблокировать список.

4. Просмотреть список, чтобы проверить, не заблокирована ли эта строка другим сеансом.