Повторим наш пример.
В первом окне обновим данные следующим запросом:
Во втором окне так выполним соответствующую команду:
Результат:
ORA-00054: resource busy AND acquire with NOWAIT specified or timeout expired
00054. 00000 — «resource busy AND acquire with NOWAIT specified or timeout expired»
*Cause: INterested resource IS busy.
*Action: Retry if necessary or INcreASe timeout.
Команды в языке SQL подразделяются на два типа: команды изменения данных и команды описания данных.
К первому типу команд (команды изменения данных) относятся операторы выбора (SELECT), вставки (INSERT, INSERT ALL), обновления данных (UPDATE, MERGE), удаления данных (DELETE).
К командам описания данных относятся команды создания структуры таблиц, изменения структуры таблиц (CREATE TABLE, MODIFY, ALTER TABLE), команды создания индексов и ограничений (CREATE INDEX, CHECK).
Транзакционная модель распространяется только на команды изменения данных, то есть команды вставки, обновления, удаления данных. То есть данные команды должны завершаться специальными операторами COMMIT или ROLLBACK для фиксации изменений в базе данных или отката изменений в базе данных.
Все изменения в базе данных, которые произведены с помощью операторов описания данных (CREATE TABLE, ALTER TABLE…), применяются немедленно.
Также к операторам описания данных можно отнести команду TRUNCATE, которая применяется для быстрой очистки таблицы.
Как посмотреть блокировки с помощью запроса?
Вот пример такого запроса:
Как посмотреть запросом, кто кого блокирует?
Воспользуемся для этого специальным запросом:
Какие права требуются при выполнении данного запроса?
Для этого запроса требуются привилегии на системное представление V$LOCK, которые может выдать администратор базы данных.
Что такое DEADLOCK?
Это нестандартная ситуация в базе данных.
Такая ситуация возникает, когда одна сессия блокирует вторую сессию, а первая сессия, в свою очередь, блокирует первую, то есть это ситуация, когда две сессии взаимно блокируют друг друга.
Пример подобной ситуации:
Как разрешить ситуацию DEADLOCK?
Данную ситуацию сможет корректно разрешить администратор базы данных.
Контрольные вопросы и задания для самостоятельного выполнения
1. Что такое DEADLOCK?
2. Как разрешается ситуация DEADLOCK?
3. Как посмотреть блокировки, кто кого блокирует?
4. Какой избежать ситуации с блокировками?
Шаг 84. Режим SERIALIZABLE
Как мы убедились на предыдущем шаге, разные пользователи могут видеть разные данные. Однако в СУБД ORACLE есть возможность, чтобы пользователь всегда видел только те данные в таблицах, которые были с начала его сессии.
Такой режим (уровень изоляции) называется SERIALIZABLE. Для того чтобы включить этот режим, используется команда:
Следующий пример показывает отличие режима SERIALIZABLE от стандартного режима эксплуатации СУБД уровня изоляции READ COMMITTED.
Откроем в двух разных окнах программу SQL DEVELOPER (или создадим новый WORKSHEET), подключимся к схеме SYS как администратор. Как создать такое подключение, подробно описано в шаге 51.
На прошлом шаге мы создали таблицу MAN5.
В одном окне выполним следующие команды:
Напишем запрос:
Запрос вернул 3 строки.
Теперь перейдем во второе окно.
Напишем запрос:
Очистим нашу таблицу с помощью команды DELETE.
Рассмотрим, как работает режим SERIALIZABLE;
Во втором окне задействуем режим изоляции данных SERIALIZABLE.
ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE;
В первом окне:
Запрос возвращает 7 строк.
Во втором окне, там, где включен режим (уровень изоляции) SERIALIZABLE, пишем запрос:
Запрос возвращает 3 строки.
В первом окне пишем команду удаления данных:
Данный запрос возвращает нам пустое множество.
Переходим в окно, где используется уровень изоляции SERIALIZABLE.
По-прежнему возвращает 3 строки.
Данный режим обеспечивает изолированный собственный набор данных, на который не могут повлиять внешние сессии.
Интересен и обратный пример. Закроем и заново откроем два окна SQL DEVELOPER.
Очистим таблицу MAN5:
Во втором окне перейдем в режим SERIALIZABLE.
Введем команду:
Вернет 5 записей.
Переходим в первое окно:
3 записи.
То есть при уровне изоляции SERIALIZABLE также справедливо утверждение, что данные во внешних сессиях так же изолированы от изменений данных в сессии SERIALIZABLE.
Читать дальше
Конец ознакомительного отрывка
Купить книгу