Tout d'abord, select L'instruction ne verrouille jamais rien dans Oracle, utilise simplement la dernière version cohérente disponible des données. Ce n'est pas un cas pour select ... for update qui verrouille les données comme update depuis Oracle 9i, mais il n'y a pas de for update clause dans la requête de question.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
La session #72 détient un verrou au niveau de la table (TM) avec le type "Row Exclusive" (SX) et souhaite acquérir un verrou "Share Row Exclusive" (SSX) sur la même table. Cette session a été bloquée par la session 24 qui détient déjà un verrou au niveau de la table d'un même type (SX) et attend pendant que le verrou SSX serait disponible.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Cette (deuxième ligne) montre exactement la même situation, mais dans le sens opposé :la session 24 attend que le verrou SSX soit disponible, mais est bloquée par la session 72 qui détient déjà le verrou SX sur la même table.
Ainsi, les sessions #24 et session #72 se bloquent :l'impasse se produit.
Les deux types de verrous (SX et SSX) sont des verrous de niveau table.
Pour comprendre la situation, je vous recommande de lire cet article de Franck Pachot.
Vous trouverez ci-dessous une citation de cet article, qui concerne directement votre situation (notez que les abréviations SSX et SRX sont équivalentes) :
L'intégrité référentielle acquiert également des verrous TM. Par exemple, le problème courant avec les clés étrangères non indexées conduit à des verrous S sur la table enfant lorsque vous émettez une suppression ou une mise à jour sur la clé, sur la table parent. En effet, sans index, Oracle ne dispose d'aucune ressource de niveau inférieur à verrouiller afin d'empêcher une insertion simultanée susceptible de violer l'intégrité référentielle.
Lorsque les colonnes de clé étrangère sont les colonnes de tête d'un index normal, la première entrée d'index avec la valeur parent peut être utilisée comme une ressource unique et verrouillée avec un TXlock au niveau de la ligne.
Et si l'intégrité référentielle a une cascade de suppression ? En plus du mode S, il est prévu de mettre à jour les lignes dans la table enfant, comme avec le mode Ligne X (RX). C'est là que le partage rowexclusive (SRX) se produit :S+RX=SRX.
Ainsi, la variante la plus probable est que la session #72 et la session #24 suppriment certaines lignes dans EMPLOYEE table en même temps, et il y a on delete cascade contrainte pour EMPSAL_EMP_ID en conjonction avec l'absence d'index sur EMPLOYEE_SALARY table dans laquelle EMPSAL_EMP_ID colonne répertoriée en premier.
