Процедура Р теперь упоминается в представлении DBA DDL LOCKS. На нее установлена блокировка разбора:

tkyte@TKYTE816> select * from dba ddl locks;

session

mode mode

Перекомпилируем процедуру и еще раз запросим представление:

tkyte@TKYTE816> alter procedure p compile; Procedure altered.

tkyte@TKYTE816> select * from dba ddl locks;

session

id OWNER

TKYTE

NAME

DBMS APPLICATION INFO DBMS APPLICATION INFO

DBMS OUTPUT DBMS OUTPUT TKYTE DATABASE

TYPE Body

ТаЫе/Procedure/Type Table/Procedure/Type Body

18 18

mode mode

held reqe

Null None

Null None

Null None

Null None

Null None

Null None

6 rows selected.

наша нарушаемая блокиров-

Теперь строки для процедуры Р в представлении нет ка снята.

Это представление пригодится разработчикам, когда обнаружится, что какой-то фрагмент кода не компилируется в тестовой среде или среде разработки - он зависает и в конечном итоге попытка завершается неудачно. Это показывает, что этот код использует (фактически - выполняет) какой-то другой сеанс, и представление позволяет понять, какой именно. То же самое происходит с операторами GRANT и другими типами операторов ЯОД, применяемыми к объекту. Нельзя, например, предоставить право на выполнение (EXECUTE) процедуры, работающей в настоящий момент. Для обнаружения потенциально блокирующих и ожидающих снятия блокировки сеансов можно использовать описанный выше метод.

Защелки и внутренние блокировки

Защелки и внутренние блокировки (enqueues) - простейшие средства обеспечения очередности доступа, используемые для координации многопользовательского доступа к общим структурам данных, объектам и файлам.

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

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

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

Блокирование вручную. Блокировки, определяемые пользователем

До сих пор мы рассматривали в основном блокировки, устанавливаемые сервером Oracle без нашего вмешательства. При изменении таблицы сервер Oracle устанавливает на нее блокировку ТМ, чтобы предотвратить ее удаление (как фактически и применение к ней большинства операторов ЯОД) другими сеансами. В изменяемых блоках оставляют блокировки ТХ - благодаря этому другие сеансы знают , что с данными рабо-

тают. Сервер использует блокировки ЯОД для защиты объектов от изменений по ходу их изменения сеансом. Он использует защелки и внутренние блокировки для защиты собственной структуры. Теперь давайте посмотрим, как включиться в процесс блокирования. У нас есть следующие возможности:

блокирование данных вручную с помощью оператора SQL;

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

Блокирование вручную

Мы уже описывали несколько случаев, когда может потребоваться блокирование вручную. Основным методом явного блокирования данных вручную является использование оператора SELECT...FOR UPDATE. Мы использовали его в предыдущих примерах для решения проблемы потерянного изменения, когда один сеанс может переписать изменения, сделанные другим сеансом. Мы видели, что этот оператор используется для установки очередности доступа к подчиненным записям, диктуемой бизнес-правилами (вспомните пример с планировщиком ресурсов, приведенный в главе 1).

Данные можно также заблокировать вручную с помощью оператора LOCK TABLE. На практике это используется редко в силу особенностей такой блокировки. Этот оператор блокирует таблицу, а не строки в ней. При изменении строк они блокируются как обычно. Так что это - не способ экономии ресурсов (как, возможно, в других реляционных СУБД). Оператор LOCK TABLE IN EXCLUSIVE MODE имеет смысл использовать при выполнении большого пакетного изменения, затрагивающего множество строк таблицы, и необходима уверенность, что никто не заблокирует это действие. Блокируя таким способом таблицу, можно быть уверенным, что все изменения удастся выполнить без блокирования другими транзакциями. Но приложения с оператором LOCK TABLE встречаются крайне редко.

Создание собственных блокировок

Сервер Oracle открывает для разработчиков свои механизмы блокирования для обеспечения очередности доступа с помощью пакета DBMS LOCK (который подробно описывается в приложении А). Может показаться странным, зачем вообще создавать собственные блокировки. Ответ обычно зависит от того, какое используется приложение. Например, этот пакет может применяться для обеспечения последовательного доступа к ресурсу, внешнему по отношению к серверу Oracle. Пусть используется подпрограмма пакета UTL FILE, позволяющая записывать информацию в файл в файловой системе сервера. Предположим, разработана общая подпрограмма передачи сообщений, вызываемая приложениями для записи сообщений. Поскольку файл является внешним, сервер Oracle не может координировать доступ нескольких пользователей, пытающихся его менять одновременно. В таких случаях как раз и пригодится пакет DBMS LOCK. Прежде чем открывать файл, записывать в него и закрывать, можно устанавливать блокировку с именем, соответствующим имени файла, в исключительном режиме, а после закрытия файла вручную снимать эту блокировку. В результате только один пользова-