2010-05-24 21 views
6

Possiedo un pacchetto Oracle DB che causa abitualmente ciò che ritengo sia un deadlock ITL (Interest Transaction List). La parte rilevante di un file di traccia è sotto.Identificazione e risoluzione di Oracle ITL Deadlock

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row 

Non ci sono indici bitmap su questa tabella, quindi non è la causa. Per quanto posso dire, la mancanza di "Rows wait on" più la "S" nella colonna Waiter Waiting indica che si tratta di un deadlock ITL. Inoltre, la tabella viene scritta abbastanza spesso (circa 8 inserimenti o aggiornamenti contemporaneamente, fino a 240 volte al minuto), quindi un deadlock ITL sembra una forte possibilità.

Ho aumentato il parametro INITRANS della tabella e gli indici sono a 100 e ho aumentato il PCT_FREE sul tavolo da 10 a 20 (quindi ho ricostruito gli indici), ma i deadlock si verificano ancora. Il deadlock sembra accadere più spesso durante un aggiornamento, ma potrebbe essere solo una coincidenza, dato che l'ho tracciato solo un paio di volte.

Le mie domande sono duplice:
1) Si tratta di un blocco critico ITL?
2) Se si tratta di un deadlock ITL, che altro si può fare per evitarlo?


Si scopre che questo non era un problema di lire stallo a tutti, ma piuttosto un problema con le chiavi esterne non-indicizzati. L'ho scoperto grazie alla risposta di dpbradley, che mi ha fatto capire che non si trattava di un problema di ITL e mi ha spinto a scoprire quali potrebbero essere le altre cause di un deadlock con "nessuna riga".

+0

Si potrebbe prendere in considerazione la possibilità di postare questo messaggio su serverfault. La mia reazione iniziale è stata quella in cui questo appartiene, ma c'è anche un gusto di programmazione per la domanda. Ad ogni modo potresti catturare un altro paio di occhi che non sono qui. – DCookie

risposta

5

la migliore indicazione della pressione ITL è dalle viste prestazioni:

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc; 

mostra TX attese contesa, e

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc; 

mostra le tabelle e gli indici coinvolti.

(Come tutti i v$ vista, i risultati sono dal momento in cui è stata avviata l'istanza.)

Se questo dimostra che si hanno davvero ITL aspetta, allora i INITRANS ei parametri PCTFREE sono le principali manopole girare (ma INITRANS = 100 suona piuttosto alto per me e questi costano spazio).

Se ITL attende non è un problema, è necessario esaminare il codice dell'applicazione.

+0

La prima query mostra 23000+ attese "enq: TX - contention", ma la seconda query mostra solo 1 attesa ITL (su un indice per una tabella in cui non è stato rilevato un deadlock). Se capisco correttamente, questo sembra suggerire che questo non è in realtà un deadlock ITL? – Allan

+0

Sì, e vedo dalla tua modifica che da allora hai scoperto il problema sottostante. FK non indicizzati possono certamente essere un problema di blocco: ci sono un sacco di script in giro che riporteranno le chiavi esterne non indicizzate in uno schema. – dpbradley

2

L'opzione migliore è di aumentarla secondo necessità (iniziare dal valore predefinito 10 e incrementare per 10). Se vedi che la riduzione di ITL è in attesa, sei pronto. Di solito questi parametri correlati sono aggiustati per tentativi ed errori sia in Oracle che in SQL Server. La regolazione di questi parametri in tempo reale non costituirà un grosso problema, a meno che la risorsa non sia estremamente occupata. È possibile utilizzare la seguente query per vedere dopo ogni incremento, se l'ITL attende o andare via o è fortemente ridotto:

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc; 

Abbiamo effettuato diverse accordature per gli scenari di deadlock Oracle a causa di lire attende con questo metodo. NOTA: assicurarsi che l'indice sia ricostruito, se initrans viene modificato per gli indici. Assicurarsi inoltre che le statistiche non siano obsolete.

Per un controllo rapido, è possibile utilizzare SQL Tuning Advisor per visualizzare lo stato completo dell'interrogazione/dell'indice e delle statistiche.