ORA-00060: impasse détectée en attente de ressource

J’ai une série de scripts exécutés en parallèle sous forme de nohup sur un serveur AIX hébergeant oracle 10g. Ces scripts sont écrits par quelqu’un d’autre et sont destinés à être exécutés simultanément. Tous les scripts effectuent des mises à jour sur une table. Je reçois l’erreur,

ORA-00060: impasse détectée en attente de ressource

Comme je l’ai cherché sur Google, j’ai trouvé, http://www.dba-oracle.com/t_deadly_perpetual_embrace_locks.htm

Même si les scripts exécutent simultanément la mise à jour sur la même table, ils effectuent des mises à jour sur différents enregistrements de la table déterminés par la clause WHERE sans chevauchement des enregistrements entre eux.

Cela aurait-il causé l’erreur?

Cette erreur se produira-t-elle quel que soit l’endroit où les mises à jour sont effectuées sur une table?

Dois-je éviter les mises à jour simultanées sur une table à tout moment?

Étrangement, j’ai également trouvé dans le journal nohup.out, PL/SQL successfully completed après l’erreur citée ci-dessus.

Est-ce que cela signifie que Oracle a récupéré de l’impasse et a complété les mises à jour avec succès ou devrais-je relancer ces scripts en série? Toute aide serait la bienvenue.

Merci d’avance.

Vous pouvez obtenir des blocages sur plus que des verrous de ligne, par exemple voir ceci . Les scripts peuvent concurrencer d’autres ressources, telles que des blocs d’index.

J’ai contourné ce problème en concevant le parallélisme de telle manière que différentes instances travaillent sur des parties de la charge de travail moins susceptibles d’affecter des blocs proches les uns des autres. par exemple, pour une mise à jour d’une grande table, au lieu de configurer les esclaves parallèles en utilisant quelque chose comme MOD(n,10) , j’utiliserais TRUNC(n/10) ce qui signifie que chaque esclave travaillait sur un dataset contigu .

Bien entendu, il existe de meilleurs moyens de diviser un travail en parallélisme, par exemple DBMS_PARALLEL_EXECUTE .

Vous ne savez pas pourquoi vous obtenez “PL / SQL avec succès”, peut-être vos scripts traitent-ils l’exception?

Je me débattais récemment avec un problème similaire. Il s’est avéré que la firebase database manquait d’index sur les clés étrangères. Cela a obligé Oracle à verrouiller beaucoup plus d’enregistrements que nécessaire, ce qui a rapidement conduit à une impasse pendant les périodes de forte concurrence.

Voici un excellent article avec beaucoup de bons détails, des suggestions et des détails sur la façon de résoudre un blocage: http://www.oratechinfo.co.uk/deadlocks.html#unindex_fk

J’ai également rencontré ce problème. Je ne connais pas les détails techniques de ce qui se passait réellement. Cependant, dans mon cas , la cause principale était la configuration en cascade des suppressions dans la firebase database Oracle et mon code JPA / Hibernate essayait également de faire les appels de suppression en cascade. Donc, mon conseil est de vous assurer que vous savez exactement ce qui se passe.