Ora-00060: обнаружен взаимоблокировка во время ожидания ресурса
у меня есть серия скриптов, работающих параллельно как nohup на сервере AIX, на котором размещен oracle 10g. Эти сценарии написаны кем-то другим и предназначены для одновременного выполнения. Все сценарии выполняют обновления таблицы. Я получаю ошибку
ORA-00060: обнаружен тупик ждем ресурса
Как я googled для этого, я найдено, http://www.dba-oracle.com/t_deadly_perpetual_embrace_locks.htm
несмотря на то, что скрипты выполняют обновление в одной таблице одновременно, они выполняют обновления для разных записей таблицы, определенных WHERE предложение без перекрытий записей между ними.
Так это вызвало бы ошибку?.
эта ошибка произойдет независимо от того, где обновления выполняются на стол?.
следует ли избегать одновременных обновлений таблицы в любое время?.
странно, что я также нашел на nohup.out log,
PL/SQL successfully completed после приведенной выше ошибки.
означает ли это, что oracle восстановилась из тупика и успешно завершила обновления или я должен повторно запустить эти сценарии последовательно? Любая помощь будет приветствоваться.
спасибо заранее.
3 ответов
вы можете получить блокировки не только на блокировках строк, например, см. этой. Сценарии могут конкурировать за другие ресурсы, такие как индексные блоки.
Я обошел это в прошлом, проектируя параллелизм таким образом, что разные экземпляры работают над частями рабочей нагрузки, которые с меньшей вероятностью влияют на блоки, которые близки друг к другу; например, для обновления большой таблицы вместо настройки параллельных рабов, используя что-то как MOD(n,10), Я хотел бы использовать TRUNC(n/10) что означает, что каждый подчиненный работал над непрерывным набором данных.
есть, конечно, гораздо лучшие способы разделения задания на параллелизм, например DBMS_PARALLEL_EXECUTE.
не уверен, почему вы получаете "PL / SQL успешно завершен", возможно, ваши скрипты обрабатывают исключение?
Я недавно боролся с подобной проблемой. Оказалось, что в базе отсутствовали индексы по внешним ключам. Это заставило Oracle заблокировать гораздо больше записей, чем требовалось, что быстро привело к взаимоблокировке во время высокого параллелизма.
вот отличная статья с большим количеством хороших деталей, предложений и деталей о том, как исправить тупик: http://www.oratechinfo.co.uk/deadlocks.html#unindex_fk
Я столкнулся с этой проблемой. Я не знаю технических деталей того, что происходило на самом деле. Однако,в моей ситуации, основной причиной было то, что в базе данных Oracle была установка каскадных удалений, и мой код JPA/Hibernate также пытался выполнить каскадные вызовы удаления. Поэтому мой совет-убедиться, что вы точно знаете, что происходит.