Zuerst select -Anweisung sperrt niemals irgendetwas in Oracle, sondern verwendet nur die letzte verfügbare konsistente Version der Daten. Es ist kein Fall für select ... for update die Daten wie update sperrt seit Oracle 9i, aber es gibt kein for update Klausel in der Abfrage von Frage.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Sitzung Nr. 72 hält eine Sperre auf Tabellenebene (TM) mit dem Typ „Row Exclusive“ (SX) und möchte eine Sperre „Share Row Exclusive“ (SSX) für dieselbe Tabelle erwerben. Diese Sitzung wurde durch Sitzung Nr. 24 blockiert, die bereits eine Sperre auf Tabellenebene des gleichen Typs (SX) enthält und wartet, während die SSX-Sperre verfügbar wäre.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Dies (zweite Reihe) zeigt genau dieselbe Situation, aber in entgegengesetzter Richtung:Sitzung Nr. 24 wartet darauf, dass die SSX-Sperre verfügbar wird, wird jedoch von Sitzung Nr. 72 blockiert, die bereits eine SX-Sperre auf derselben Tabelle hält.
Sitzung Nr. 24 und Sitzung Nr. 72 blockieren sich also gegenseitig:Deadlock tritt auf.
Beide Sperrtypen (SX und SSX) sind Sperren auf Tabellenebene.
Um die Situation zu verstehen, empfehle ich, diesen Artikel von Franck Pachot zu lesen.
Unten finden Sie Zitate aus diesem Artikel, die für Ihre Situation direkt relevant sind (beachten Sie, dass die Abkürzungen SSX und SRX gleichwertig sind):
Die referenzielle Integrität erwirbt auch TM-Sperren. Beispielsweise führt das häufige Problem mit nicht indizierten Fremdschlüsseln zu S-Sperren auf untergeordneten Tabellen, wenn Sie eine Löschung oder Aktualisierung des Schlüssels auf der übergeordneten Tabelle vornehmen. Dies liegt daran, dass Oracle ohne einen Index keine einzelne Ressource auf niedrigerer Ebene sperren muss, um eine gleichzeitige Einfügung zu verhindern, die die referenzielle Integrität verletzen kann.
Wenn die Fremdschlüsselspalten die führenden Spalten in einem regulären Index sind, dann der erste Indexeintrag mit Der Elternwert kann als einzelne Ressource verwendet und mit einem TXlock auf Zeilenebene gesperrt werden.
Und was ist, wenn die referenzielle Integrität eine Löschkaskade hat? Zusätzlich zum S-Modus besteht die Absicht, Zeilen in der untergeordneten Tabelle zu aktualisieren, wie beim Modus Zeile X (RX). Hier kommt die Share Rowexclusive (SRX) vor:S+RX=SRX.
Die wahrscheinlichste Variante ist also, dass Sitzung Nr. 72 und Sitzung Nr. 24 einige Zeilen in EMPLOYEE löschen Tabelle zur gleichen Zeit, und es gibt on delete cascade Einschränkung für EMPSAL_EMP_ID in Verbindung mit fehlendem Index zu EMPLOYEE_SALARY Tabelle, in der EMPSAL_EMP_ID Spalte zuerst aufgeführt.
