Как обойти блокировку oracle

Русские Блоги

Запрос таблицы блокировки Oracle и метод разблокировки

Классификация операторов операций с базой данных

DDL: язык определения схемы базы данных, ключевое слово: create
DML: язык обработки данных, ключевые слова: вставка, удаление, обновление
DCL: язык управления базой данных, ключевые слова: предоставить, удалить
DQL: язык запросов к базе данных, ключевое слово: выберите

При каких обстоятельствах таблица оракула будет заблокирована

Блокировки DML можно разделить на блокировки строк, блокировки таблиц и взаимоблокировки.

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

Блокировка на уровне таблицы: когда транзакция получает блокировку строки, транзакция также автоматически получает блокировку таблицы (разделяемую блокировку), чтобы другие транзакции не влияли на обновление строки записи операторами DDL. Транзакция также может получить общую блокировку или эксклюзивную блокировку в процессе.Только когда транзакция показывает, что эксклюзивная блокировка определена с помощью оператора LOCK TABLE, транзакция может получить эксклюзивную блокировку для таблицы или ее можно отобразить с помощью LOCK TABLE Определите общую блокировку на уровне таблицы (см. Соответствующие документы для конкретного использования LOCK TABLE).

Тупик: когда двум транзакциям требуется набор конфликтующих блокировок, и транзакция не может быть продолжена, возникает тупик.
Например, транзакция 1 имеет монопольную блокировку в записи строки №3 таблицы A и ожидает, пока транзакция 2 освободит монопольную блокировку в записи №4 таблицы A, а транзакция 2 находится в таблице A В строке записи №4 имеется эксклюзивная блокировка, и в ожидании, когда транзакция 1 освободит исключительную блокировку в записи №3 в таблице A, транзакция 1 и транзакция 2 ждут друг друга, что вызывает взаимоблокировку. Взаимоблокировки обычно возникают из-за плохого дизайна транзакции.
Тупиковая ситуация может использоваться только в SQL: изменить сеанс уничтожения системы «sid, serial #»; или использовать команду соответствующего процесса уничтожения операционной системы, например kill -9 sid в UNIX, или использовать другие Инструмент убивает процесс тупика.

Блокировки DDL можно разделить на: эксклюзивные блокировки DDL, общие блокировки DDL, блокировки анализа.

Эксклюзивная блокировка DDL: операторы DDL, которые создают, изменяют и удаляют объект базы данных, получают монопольную блокировку рабочего объекта. Например, при использовании оператора alter table для поддержания полноты, согласованности и законности данных транзакция получает исключительную блокировку DDL.

Общие блокировки DDL: операторы DDL, которые должны устанавливать взаимные зависимости между объектами базы данных, обычно должны использоваться совместно для получения блокировок DDL.
Если пакет создан, процедуры и функции в пакете ссылаются на разные таблицы базы данных.Когда пакет компилируется, транзакция получает общую блокировку DDL указанной таблицы.

Блокировка анализа: ORACLE использует общий пул для хранения проанализированных и оптимизированных операторов SQL и программ PL / SQL, чтобы приложения, выполняющие один и тот же оператор, работали быстрее. Объект, кэшированный в общем пуле, получает блокировку анализа на объект базы данных, на который он ссылается. Блокировка анализа — это уникальный тип блокировки DDL, Oracle использует ее для отслеживания зависимостей между объектами общего пула и объектами базы данных, на которые он ссылается. Когда транзакция изменяет или удаляет объект базы данных, удерживающий блокировку анализа в разделяемом пуле, ORACLE делает недействительным объект в разделяемом пуле. В следующий раз, когда на этот оператор SQL / PLSQL будет сделана ссылка, ORACLE повторно проанализирует и компилирует этот оператор.

Запрос и разблокировка таблицы блокировки Oracle

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

Первый шаг: запросить информацию о заблокированной таблице через пользователя с полномочиями администратора

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

например: теперь я выполняю оператор DML через пользователя scott (например: select * from emp для обновления; или update scott.emp set sal = ‘2000’, где empno = ‘7788’;) после того, как не отправляю его, а затем выполняю его через системного пользователя Оператор SQL заблокированной таблицы в приведенном выше запросе Oracle найдет следующие записи:

Описание:
имя пользователя: имя пользователя oracle
sid: идентификатор процесса
серийный номер: серийный номер
имя_объекта: имя таблицы
osuser: имя пользователя операционной системы
machine: имя компьютера
программа: рабочий инструмент
logon_time: время входа в систему
lockwait: указывает, ожидает ли эта таблица в настоящее время, пока другие пользователи разблокируют эту таблицу.
locked_mode: режим блокировки счетчика (подробно описано ниже)

Шаг 2: Разблокируйте заблокированную таблицу (SID, SERIAL) в базе данных пользователем с правами администратора

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

Читать:

Как в adobe premiere pro вернуть окна по умолчанию

Примечание: sid и seial # — это номер процесса и серийный номер, запрашиваемые на первом этапе.

например: разблокировать стол на первом шаге

Теперь выполните оператор DML (например: select * from scott.emp для обновления; или update scott.emp set sal = ‘2000’, где empno = ‘7788’;) снова через систему.

Режим блокировки

Также есть более практичный SQL

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

Ловим блокировку на чтение в Oracle

Не буду тянуть и скажу сразу, ловить мы будем следующего зверя: enq: RC — Result Cache: Contention – внутренняя блокировка, использующая механизм очереди, для координации конкурентного доступа к кэшу. Для начала нам понадобится создать одну таблицу и функцию.

Далее в двух разных сессиях почти параллельно мы должны запустить практически один и тот же скрипт. Сначала запускаем скрипт «Сессия №1», потом переключаемся в другое окно и запускаем второй скрипт «Сессия №2». В общем, надо запустить второй скрипт до того как в первом истечет время сна.

В результате должо получиться следующее:

Первая сессия выполнится чуть более чем за 10 сек и напечатает в output
1
2
wait_time: 0

Вторая сессия тоже будет выполняться около 10 сек и напечатает в output
1
2
wait_time: 8077256

Естественно, последнее число будет у всех разное, оно показывает время ожидания блокировки enq: RC — Result Cache: Contention в микросекундах. Т.е. в моем случае ожидание было 8 сек. Что же произошло?
Когда первая сессия начинает извлекать данные из курсора, она формирует кэш по этому sql-запросу. После того как 2 строки были извлечены, сессия впадает в спячку. В это время вторая сессия начинает читать те же самые строки и т.к. кэш сформирован, то сессия пытается читать результат именно оттуда. И в этот самый момент она натыкается на блокировку. Казалось бы, кэш есть, чего блокируют-то? Дело в том, что первая сессия еще «читает» данные из курсора! Хоть и обе строки уже прочитаны, но еще не стало понятно, что курсор прочитал все что должен был. Это произойдет только после третьего fetch, тогда станет ясно что курсору больше нечего выдавать и блокировка снимется, а до этого момента первая сессия формирует кэш и держит все остальные сессии.
Если инвалидировать кэш и повторить эксперимент заново, но поставить sleep после третьего fetch, то скорее всего блокировку поймать не удастся либо будет совсем маленькое значение времени ожидания, т.к. теперь первая сессия не выполняет ничего долговременного во время формирования кэша.

Механизм result_cache был представлен как новая фича в 11 версии бд. Сам механизм достаточно специфичен, если в нем хорошо разобраться, то, возможно, окажется, что не так уж и много ситуаций есть в вашем проекте, где это действительно можно использовать. Поэтому будьте осторожны прежде чем использовать что-то новое не разобравшить до конца. Недавно был релиз 12 версии бд уже с другими новыми возможностями и поэтому поводу была интересная статья здесь же, на хабре.

Unlock An Oracle Table

What are the different techniques for Unlocking an oracle table?

Get the object ID of the locked table:

SELECT object_id FROM dba_objects WHERE object_name=’YOUR TABLE NAME’;

Get the SID values for this ID:

SELECT sid FROM v$lock WHERE id1=OBJECT ID FROM STEP1

Get the session values for these SIDs:

SELECT sid, serial# from v$session where sid in (COMMA SEPARATED LIST OF SIDs FROM STEP2.)

Kill the sessions causing the lock:

ALTER SYSTEM KILL SESSION (SID,SERIAL#)

pair values from step 3 e.g. ALTER SYSTEM KILL SESSION ‘231,23454’

But The Problem is I have lot of tables which has been locked is there any other technique for unlocking the tables.