ORA-00060: во время ожидания ресурса обнаружена тупиковая ситуация

Question

У меня есть серия сценариев, работающих параллельно как nohup на сервере AIX, на котором установлен Oracle 10g. Эти сценарии написаны кем-то другим и предназначены для одновременного выполнения. Все сценарии выполняют обновления на столе. Я получаю ошибку,

ORA-00060: при обнаружении тупика в ожидании ресурса

Пока я гуглил, я обнаружил, http://www.dba -oracle.com / t_deadly_perpetual_embrace_locks.htm

Несмотря на то, что сценарии выполняют обновление для одной и той же таблицы одновременно, они выполняют обновления для разных записей таблицы, определенных в предложении WHERE, без перекрытия записей между ними.

Так это могло бы вызвать ошибку?

Произойдет ли эта ошибка независимо от того, где выполняются обновления для таблицы?.

Стоит ли избегать одновременных обновлений таблицы постоянно.

Странно я тоже нашел в журнале nohup.out, PL/SQL successfully completed после вышеуказанной ошибки.

Означает ли это, что oracle восстановился из тупика и успешно завершил обновления, или я должен повторно запустить эти сценарии поочередно? Любая помощь будет приветствоваться.

Заранее спасибо.

Answer 1

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

Вот отличная статья с множеством полезных деталей, предложений и деталей о том, как исправить тупик: http://www.oratechinfo.co.uk/deadlocks.html#unindex_fk

Answer 2

Вы можете получить взаимные блокировки не только для блокировки строк, например, см. this .Сценарии могут конкурировать за другие ресурсы, такие как индексные блоки.

В прошлом я справлялся с этим, разрабатывая параллелизм таким образом, чтобы разные экземпляры работали с меньшими частями рабочей нагрузки.может повлиять на блоки, которые находятся близко друг к другу;например, для обновления большой таблицы вместо установки параллельных ведомых устройств, использующих что-то вроде MOD(n,10), я бы использовал TRUNC(n/10), что означает, что каждый ведомый работал с непрерывным набором данных.

Конечно, существуют гораздо лучшие способы разделения работы для параллелизма, например, DBMS_PARALLEL_EXECUTE .

Не уверен, почему вы получаете "PL / SQL успешно завершен", возможно, вашсценарии обрабатывают исключение?

Answer 3

Я тоже столкнулся с этой проблемой. Я не знаю технических деталей того, что на самом деле происходило. Однако в моей ситуации основной причиной было то, что в базе данных Oracle была установлена ​​каскадная установка удалений, и мой код JPA / Hibernate также пытался выполнить каскадные вызовы удаления. Поэтому я советую вам точно знать, что происходит.

Answer 4

Я тестировал функцию, которая содержала несколько операторов UPDATE в блоках IF-ELSE.

Я тестировал все возможные пути, поэтому каждый раз перед повторным запуском функции я возвращал таблицам прежние значения, используя операторы UPDATE.

Я заметил, что проблемапроизойдет сразу после этих UPDATE заявлений;

Я добавил COMMIT; после оператора UPDATE, который использовал для сброса таблиц, и это решило проблему.

Так что, проблема не быласама функция ...