Wenn Sie Ihre Frage mit dem Deadlock-Diagramm aktualisieren könnten, wären das nützliche Informationen. (Wenn Ihre Anwendung auf einen Deadlock stößt, löst Oracle ein ORA-00060 aus, und eine Tracedatei wird in user_dump_dest geschrieben.) Wenn Sie in der Tracedatei nachsehen, finden Sie einen Abschnitt namens "Deadlock Graph". Wenn Sie das posten können und auch die Aussage, die den Deadlock verursacht hat, und andere Aussagen, die an dem Deadlock beteiligt sind, können wir damit beginnen, einige Schlussfolgerungen zu ziehen. (Alle angeforderten Informationen sind in der Ablaufverfolgungsdatei verfügbar.)
Wie Alessandro erwähnt hat, ist es möglich, dass Sitzungen verschiedene Zeilen in derselben Tabelle aufgrund von nicht indizierten Fremdschlüsseln in der untergeordneten Tabelle einer Eltern-Kind-Beziehung blockieren. Außerdem ist es möglich, dass Sie Deadlocks in zwei Sitzungen haben, die verschiedene Zeilen derselben Tabelle aktualisieren, selbst wenn die Tabelle nicht Teil einer Eltern-/Kind-Beziehung ist, wenn die Tabelle beispielsweise einen Mangel an ITL-Einträgen aufweist.
Veröffentlichen Sie erneut die oben angeforderten Informationen, und ich bin zuversichtlich, dass wir die Ursache Ihres Deadlocks ermitteln können.
Hinzugefügt am 30.07.2012 **
Fügen Sie Folgendes hinzu, nachdem die Deadlock-Trace-Datei bereitgestellt wurde:Ok, zunächst einmal, basierend auf dem Inhalt der Trace-Datei, ist dies ein einfacher Deadlock, da sich Sitzungen in den Zeilen, die sie zu sperren versuchen, überlappen/kollidieren. Trotz Ihrer vorherigen Kommentare zum Deadlock auf anders Zeilen, ich bin hier, um Ihnen zu sagen, dass dieser spezielle Deadlock auf das Sperren auf Zeilenebene auf demselben zurückzuführen ist Zeilen.
Die Tatsache, dass das Deadlock-Diagramm den Modus anzeigt, in dem die Sperre gehalten wird, ist 'X' (exklusiv) und der Modus, auf den die Sperre gewartet wird, 'X' ist, sagt mir, dass dies eine einfache Sperrung auf Zeilenebene ist.
In diesem Fall führt SID 20 "delete from RPT_TABLE.TEMP_TABLE_T1 where TEMP_T1_ID=:1" aus und bereits eine Sperre für die Zeilen-ID AAAPDIAAMAAEfIAAA.
Währenddessen führt SID 790 "RPT_TABLE.T1_UPDATE_StoredProc" aus, während es bereits eine Sperre auf die Zeilen-ID AAAPDIAAMAAAAEfGAAA hält.
Beachten Sie aus dem Abschnitt "Zeilen, auf die gewartet wird" der Ablaufverfolgungsdatei, dass SID 20 auf die Zeile wartet, die SID 790 enthält, und SID 790 auf die Zeile wartet, die SID 20 enthält. Dies ist ein klassischer Deadlock.
Einige zusätzliche Informationen:
-
Enqueue-Typ ist TX (siehe Deadlock-Diagramm), also ist dies definitiv nicht Sperren aufgrund nicht indizierter Fremdschlüssel. Wenn es wegen nicht indizierter FKs sperren würde, wäre der Enqueue-Typ TM, nicht TX. (Es gibt mindestens einen weiteren Fall, in dem TM-Enqueues beteiligt sind, und es handelt sich nicht um nicht indizierte FKs. Gehen Sie also nicht davon aus, dass TM-Enqueue immer nicht indizierte FKs bedeutet.)
-
Der Modus, auf den auf die Sperre gewartet wird, ist 'X' (exklusiv), also handelt es sich um eine Sperrung auf Zeilenebene. Wenn der Modus, auf den gewartet wird, 'S' (gemeinsam) wäre, dann nicht Sperren auf Zeilenebene sein. Vielmehr könnte es sich um ITL-Mangel oder PK- oder UK-Durchsetzung handeln.
Hoffe das hilft!
