Om du kunde uppdatera din fråga med dödlägesdiagrammet skulle det vara användbar information. (När din applikation stöter på ett dödläge kommer Oracle att höja en ORA-00060, och en spårningsfil kommer att skrivas till user_dump_dest.) Om du tittar i spårningsfilen hittar du en sektion som heter "Deadlock Graph". Om du kan lägga upp det, och även lägga upp uttalandet som orsakade dödläget och andra påståenden som är involverade i dödläget, så kan vi börja dra några slutsatser. (All information jag begärde finns i spårningsfilen.)
Som Alessandro nämnde, är det möjligt för sessioner som låser olika rader i samma tabell till dödläge på grund av oindexerade främmande nycklar på undertabellen för en förälder/barn-relation. Det är också möjligt att du kan ha dödlägen på två sessioner som uppdaterar olika rader i samma tabell, även om tabellen inte är en del av en förälder/barn-relation, om tabellen till exempel har en brist på ITL-poster.
Återigen, posta informationen som begärts ovan, och jag är övertygad om att vi kan fastställa grundorsaken till ditt dödläge.
Tillagt 2012-07-30 **
Lägger till följande, nu när dödlägesspårningsfilen har tillhandahållits:Ok, först och främst, baserat på spårningsfilens innehåll, är detta ett enkelt dödläge på grund av att sessioner överlappar/kolliderar på raderna de försöker låsa. Trots dina tidigare kommentarer om att dödläget är på annorlunda rader, jag är här för att berätta att just detta dödläge beror på låsning på radnivå på samma rader.
Det faktum att dödlägesdiagrammet visar läge som låset hålls i är "X" (exklusivt) och läget som låset väntas på är "X", säger mig att detta är enkel låsning på radnivå.
I det här fallet kör SID 20 "radera från RPT_TABLE.TEMP_TABLE_T1 där TEMP_T1_ID=:1" och redan har ett lås på rowid AAAPDIAAMAAAEfIAAA.
Samtidigt kör SID 790 "RPT_TABLE.T1_UPDATE_StoredProc", medan den redan håller ett lås på rowid AAAPDIAAMAAAEfGAAA.
Notera från avsnittet "Rader väntade på" i spårningsfilen, att SID 20 väntar på raden som SID 790 håller och SID 790 väntar på raden som SID 20 håller. Det här är ett klassiskt dödläge.
Lite ytterligare information:
-
Enqueue-typen är TX (se dödlägesdiagrammet), så det här är definitivt inte låsning på grund av oindexerade främmande nycklar. Om det var låst på grund av oindexerade FK:er, skulle kötypen vara TM, inte TX. (Det finns åtminstone ett annat fall där TM-köer är inblandade, och det är inte oindexerade FK:er. Så, anta inte att TM-kö alltid betyder oindexerade FK:er.)
-
Läget som låset väntas på är 'X' (exklusivt), så detta är låsning på radnivå. Om läget som väntade på var 'S' (delat), så skulle det inte göra det vara låsande på radnivå. Snarare kan det vara ITL-brist eller PK eller Storbritanniens upprätthållande.
Hoppas det hjälper!