Se potessi aggiornare la tua domanda con il grafico dello stallo, sarebbe un'informazione utile. (Quando la tua applicazione incontra un deadlock, Oracle solleverà un ORA-00060 e un file di traccia verrà scritto in user_dump_dest.) Se guardi nel file di traccia, troverai una sezione chiamata "Grafico di deadlock". Se puoi pubblicarlo e pubblicare anche la dichiarazione che ha causato lo stallo e altre dichiarazioni coinvolte nello stallo, allora possiamo iniziare a trarre alcune conclusioni. (Tutte le informazioni che ho richiesto sono disponibili nel file di traccia.)
Come accennato da Alessandro, è possibile che le sessioni blocchino righe diverse nella stessa tabella in deadlock a causa di chiavi esterne non indicizzate nella tabella figlio di una relazione padre/figlio. Inoltre, è possibile che tu possa avere deadlock su due sessioni che aggiornano righe diverse della stessa tabella, anche se la tabella non fa parte di una relazione padre/figlio, se, ad esempio, la tabella ha una carenza di voci ITL.
Ancora una volta, pubblica le informazioni richieste sopra e sono sicuro che possiamo determinare la causa principale del tuo deadlock.
Aggiunto il 30/07/2012 **
Aggiungendo quanto segue, ora che il file di traccia del deadlock è stato fornito:Ok, prima di tutto, in base al contenuto del file di traccia, questo è un semplice deadlock dovuto alla sovrapposizione/collisione delle sessioni sulle righe che stanno cercando di bloccare. Nonostante i tuoi commenti precedenti sullo stallo fossero diversi righe, sono qui per dirti che questo particolare deadlock è dovuto al blocco a livello di riga sullo stesso righe.
Il fatto che il grafico del deadlock mostri che la modalità in cui è mantenuto il blocco è "X" (esclusiva) e la modalità in cui il blocco è in attesa è "X", mi dice che si tratta di un semplice blocco a livello di riga.
In questo caso, SID 20 sta eseguendo "cancella da RPT_TABLE.TEMP_TABLE_T1 dove TEMP_T1_ID=:1" e ha già un blocco su Rowid AAAPDIAAMAAAEfIAAA.
Nel frattempo, SID 790 sta eseguendo "RPT_TABLE.T1_UPDATE_StoredProc", mentre tiene già un blocco su rowid AAAPDIAAMAAAEfGAAA.
Nota dalla sezione "Righe in attesa" del file di traccia, che SID 20 è in attesa sulla riga che contiene SID 790 e SID 790 è in attesa sulla riga che contiene SID 20. Questo è un classico punto morto.
Alcune informazioni aggiuntive:
-
Il tipo di coda è TX (vedi il grafico del deadlock), quindi questo è sicuramente non blocco dovuto a chiavi esterne non indicizzate. Se fosse bloccato a causa di FK non indicizzati, il tipo di coda sarebbe TM, non TX. (C'è almeno un altro caso in cui sono coinvolti gli accodamenti TM e non si tratta di FK non indicizzati. Quindi, non dare per scontato che accodamento TM significhi sempre FK non indicizzati.)
-
La modalità in cui il blocco è in attesa è "X" (esclusivo), quindi questo è il blocco a livello di riga. Se la modalità in attesa era "S" (condivisa), allora non essere il blocco a livello di riga. Piuttosto, potrebbe essere la carenza di ITL o l'applicazione della PK o del Regno Unito.
Spero di esserti stato d'aiuto!
