Hvis du kunne opdatere dit spørgsmål med dødvandsgrafen, ville det være nyttig information. (Når din applikation støder på et dødvande, vil Oracle rejse en ORA-00060, og en sporingsfil vil blive skrevet til user_dump_dest.) Hvis du kigger i sporingsfilen, vil du finde en sektion kaldet "Deadlock Graph". Hvis du kan poste det, og også poste det udsagn, der forårsagede dødvandet og andre udsagn involveret i dødvandet, så kan vi begynde at drage nogle konklusioner. (Alle de oplysninger, jeg anmodede om, er tilgængelige i sporingsfilen.)
Som Alessandro nævnte, er det muligt for sessioner, der låser forskellige rækker i den samme tabel til deadlock på grund af uindekserede fremmednøgler på den underordnede tabel i et forældre/barn-forhold. Det er også muligt, at du kan have deadlocks på to sessioner, der opdaterer forskellige rækker i den samme tabel, selvom tabellen ikke er en del af et forældre/barn-forhold, hvis for eksempel tabellen mangler ITL-poster.
Igen, post de oplysninger, der anmodes om ovenfor, og jeg er sikker på, at vi kan fastslå årsagen til dit dødvande.
Tilføjet den 30/7/2012 **
Tilføjelse af følgende, nu hvor deadlock-sporingsfilen er blevet leveret:Ok, først og fremmest, baseret på sporingsfilens indhold, er dette en simpel deadlock på grund af sessioner, der overlapper/kolliderer på de rækker, de forsøger at låse. På trods af dine tidligere kommentarer om, at dødvandet er på anderledes rækker, er jeg her for at fortælle dig, at denne særlige dødvande skyldes låsning på rækkeniveau på samme rækker.
Det faktum, at dødlåsegrafen viser tilstanden, låsen er holdt i, er 'X' (eksklusiv), og den tilstand, låsen ventes på er 'X', fortæller mig, at dette er simpel låsning på rækkeniveau.
I dette tilfælde udfører SID 20 "slet fra RPT_TABLE.TEMP_TABLE_T1 hvor TEMP_T1_ID=:1" og allerede har en lås på rowid AAAPDIAAMAAAEfIAAA.
I mellemtiden udfører SID 790 "RPT_TABLE.T1_UPDATE_StoredProc", mens den allerede holder en lås på rowid AAAPDIAAMAAAEfGAAA.
Bemærk fra sektionen "Rækker ventet på" i sporingsfilen, at SID 20 venter på den række, som SID 790 holder, og SID 790 venter på den række, som SID 20 holder. Dette er et klassisk dødvande.
Nogle yderligere oplysninger:
-
Enqueue-typen er TX (se deadlock-grafen), så dette er bestemt ikke låsning på grund af uindekserede fremmednøgler. Hvis det var låst på grund af uindekserede FK'er, ville køtypen være TM, ikke TX. (Der er mindst ét andet tilfælde, hvor TM-køer er involveret, og det er ikke uindekserede FK'er. Så antag ikke, at TM-kø altid betyder uindekserede FK'er.)
-
Den tilstand, som låsen ventes på, er 'X' (eksklusiv), så dette er låsning på rækkeniveau. Hvis den ventede tilstand var 'S' (delt), så ville den ikke være række-niveau låsning. Det kunne snarere være ITL-mangel eller håndhævelse af PK eller UK.
Håber det hjælper!