Si vous pouviez mettre à jour votre question avec le graphique de blocage, ce serait une information utile. (Lorsque votre application rencontre un blocage, Oracle lèvera un ORA-00060 et un fichier de trace sera écrit dans user_dump_dest.) Si vous regardez dans le fichier de trace, vous trouverez une section appelée "Deadlock Graph". Si vous pouvez publier cela, ainsi que la déclaration qui a provoqué l'impasse et d'autres déclarations impliquées dans l'impasse, nous pourrons alors commencer à tirer des conclusions. (Toutes les informations que j'ai demandées sont disponibles dans le fichier de trace.)
Comme Alessandro l'a mentionné, il est possible que des sessions verrouillant différentes lignes dans la même table se bloquent en raison de clés étrangères non indexées sur la table enfant d'une relation parent/enfant. De plus, il est possible que vous ayez des interblocages sur deux sessions mettant à jour différentes lignes de la même table, même si la table ne fait pas partie d'une relation parent/enfant, si, par exemple, la table manque d'entrées ITL.
Encore une fois, publiez les informations demandées ci-dessus, et je suis convaincu que nous pourrons déterminer la cause première de votre blocage.
Ajouté le 30/07/2012 **
Ajout de ce qui suit, maintenant que le fichier de trace de blocage a été fourni :Ok, tout d'abord, sur la base du contenu du fichier de trace, il s'agit d'un simple blocage dû au chevauchement/collision des sessions sur les lignes qu'ils tentent de verrouiller. Malgré vos commentaires précédents sur le blocage étant sur différent lignes, je suis ici pour vous dire que ce blocage particulier est dû au verrouillage au niveau de la ligne sur le même lignes.
Le fait que le graphique de blocage indique que le mode dans lequel le verrou est maintenu est 'X' (exclusif) et que le mode dans lequel le verrou est attendu est 'X', m'indique qu'il s'agit d'un simple verrouillage au niveau de la ligne.
Dans ce cas, SID 20 exécute "delete from RPT_TABLE.TEMP_TABLE_T1 where TEMP_T1_ID=:1" et a déjà un verrou sur le rowid AAAPDIAAMAAAEfIAAA.
Pendant ce temps, le SID 790 exécute "RPT_TABLE.T1_UPDATE_StoredProc", tout en détenant déjà un verrou sur le rowid AAAPDIAAMAAAEfGAAA.
Notez dans la section "Lignes attendues" du fichier de trace que le SID 20 attend sur la ligne que le SID 790 contient et que le SID 790 attend sur la ligne que le SID 20 contient. C'est une impasse classique.
Quelques informations supplémentaires :
-
Le type de mise en file d'attente est TX (voir le graphique de blocage), donc, ce n'est certainement pas verrouillage dû à des clés étrangères non indexées. S'il se verrouillait en raison de FK non indexés, le type de mise en file d'attente serait TM, pas TX. (Il existe au moins un autre cas où des mises en file d'attente de TM sont impliquées, et il ne s'agit pas de FK non indexées. Ne présumez donc pas que la mise en file d'attente de TM signifie toujours des FK non indexées.)
-
Le mode d'attente du verrou est 'X' (exclusif), il s'agit donc d'un verrouillage au niveau de la ligne. Si le mode attendu était 'S' (partagé), alors ce ne serait pas être un verrouillage au niveau de la ligne. Il pourrait plutôt s'agir d'une pénurie d'ITL ou d'une application de la loi PK ou du Royaume-Uni.
J'espère que ça aide !
