Individuazione della causa dell'errore deadlock dal file di traccia oracle

Question

Ho riscontrato spesso questo errore "ora-00060 rilevato durante l'attesa della risorsa" ora nella mia applicazione quando più utenti utilizzano l'applicazione. Ho ricevuto il file di traccia dall'amministratore di Oracle, ma ho bisogno di aiuto per leggerlo. Di seguito sono riportati alcuni bit di dati del file di traccia, che spero possano aiutare a individuare la causa.

*** 2013-06-25 09:37:35.324 
DEADLOCK DETECTED (ORA-00060) 

[Transaction Deadlock] 

The following deadlock is not an ORACLE error. It is a deadlock due 
to user error in the design of an application 
or from issuing incorrect ad-hoc SQL. The following 
information may aid in determining the deadlock: 

Deadlock graph: 
        ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

session 72: DID 0001-00D2-000000C6 session 24: DID 0001-00D0-00000043 
session 24: DID 0001-00D0-00000043 session 72: DID 0001-00D2-000000C6 

Rows waited on: 
Session 72: no row 
Session 24: no row 

----- Information for the OTHER waiting sessions ----- 
Session 24: 
sid: 24 ser: 45245 audsid: 31660323 user: 90/USER 
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- 
    flags2: (0x40009) -/-/INC 
pid: 208 O/S info: user: zgrid, term: UNKNOWN, ospid: 2439 
    image: oracle@xyz.local 
client details: 
    O/S info: user: , term: , ospid: 1234 
    machine: xyz.local program: 
current SQL: 
    delete from EMPLOYEE where EMP_ID=:1 

----- End of information for the OTHER waiting sessions ----- 

Information for THIS session: 

----- Current SQL Statement for this session (sql_id=dyfg1wd8xa9qt) ----- 
delete from EMPLOYEE where EMP_ID=:1 
=================================================== 

Sarei grato se qualcuno possa dirmi cosa dice il "grafico del deadlock". Anche le file in attesa sulla sezione non dicono righe.

Ho anche letto in alcuni blog che la sezione "sqltxt" del file di traccia può suggerire la causa. Di seguito è la query che vedo in quella sezione.

select /*+ all_rows */ count(1) from "USERS"."EMPLOYEE_SALARY" where EMPSAL_EMP_ID=:1 

La tabella employee_salary ha un vincolo di foreignkey sulla colonna EMPSAL_EMP_ID.

Il suggerimento sql dice "all_rows", quindi vuol dire che questa tabella ottiene il blocco del livello di tabella quando si eliminano i record dalla tabella dei dipendenti? non ho un indice sulla colonna chiave straniera attualmente. Sarebbe utile aggiungere un indice su questa colonna?

Gentilmente inviare, nel caso in cui siano necessarie ulteriori informazioni.

Grazie

Answer 1

Prima di tutto, select dichiarazione mai blocco nulla in Oracle, utilizza solo l'ultima versione coerente a disposizione dei dati. Non è il caso di select ... for update che blocca i dati come update da Oracle 9i, ma non ci sono clausole for update nella query dalla domanda.

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 

Session # 72 detiene blocco a livello di tabella (TM) con "Linea Exclusive" tipo (SX) e vogliono acquisire "Condividi Row Exclusive" (SSX) blocco sulla stessa tavola. Questa sessione è bloccata dalla Sessione 24 che già detiene il blocco a livello di tabella di uno stesso tipo (SX) e attende mentre il blocco SSX sarà disponibile.

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

Questa (seconda riga) dimostra esattamente stessa situazione, ma in direzione opposta: Session # 24 attende SSX Serratura diventano disponibili, ma respinto da Session # 72 che contiene già serratura SX sulla stessa tabella.

Quindi, la sessione n. 24 e la sessione n. 72 si bloccano: si verifica un deadlock.

Entrambi i tipi di blocco (SX e SSX) sono blocchi a livello di tabella.
Per capire la situazione, consiglio di leggere this article di Franck Pachot.

seguito è citazione di questo articolo, che direttamente relativi alla situazione (si noti che SSX e SRX abbreviazioni sono equivalenti):

integrità referenziale acquisisce anche serrature TM. Ad esempio, il problema comune di con chiavi esterne non indicizzate porta a blocchi S sulla tabella figlio quando si esegue una eliminazione o un aggiornamento sulla chiave nella tabella padre. Questo è perché senza un indice, Oracle non ha un'unica risorsa di livello inferiore al blocco per impedire un inserto concorrente che può violare l'integrità referenziale .
Se le colonne chiave esterna sono le colonne principali in un indice regolare, la prima voce di indice con il valore genitore può essere utilizzata come singola risorsa e bloccata con un blocco TX a livello di riga.
E cosa succede se l'integrità referenziale ha un on cancella in cascata? Nella versione aggiunta alla modalità S, è prevista l'aggiornamento delle righe nella tabella figlio , come nella modalità Riga X (RX). Qui si trova la riga condivisa esclusiva (SRX): S + RX = SRX.

Quindi, più probabile variante è che Session # 72 e Session # 24 elimina alcune righe in EMPLOYEE tavolo stesso tempo, e ci sono on delete cascade vincolo per EMPSAL_EMP_ID in congiunzione con assenza di indice su EMPLOYEE_SALARY tabella nella quale EMPSAL_EMP_ID colonna elencato per primo