Подтвердить что ты не робот

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

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

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

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

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

Так это вызвало бы ошибку?.

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

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

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

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

Спасибо заранее.

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Есть, конечно, гораздо лучшие способы разделения задания на parallelism, например. DBMS_PARALLEL_EXECUTE.

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

Ответ 2

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

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

Ответ 3

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