Rilevamento e interruzione di deadlock

Articolo
12/15/2008

Data aggiornamento: 5 dicembre 2005

Un deadlock si verifica quando due o più attività si bloccano a vicenda in modo permanente in quanto ognuna delle attività prevede un blocco su una risorsa che le altre attività stanno cercando di bloccare. Nel grafico seguente viene illustrata una vista di alto livello di uno stato di deadlock in cui:

L'attività T1 prevede un blocco sulla risorsa R1, indicato dalla freccia da R1 a T1, e ha richiesto un blocco sulla risorsa R2, indicato dalla freccia da T1 a R2.
L'attività T2 prevede un blocco sulla risorsa R2, indicato dalla freccia da R2 a T2, e ha richiesto un blocco sulla risorsa R1, indicato dalla freccia da T2 a R1.
Poiché nessuna attività può continuare fino a quando una risorsa diventa disponibile e nessuna risorsa può essere rilasciata fino a quando l'attività continua, si verifica una stato di deadlock.

Diagramma che illustra le attività in stato di deadlock

Motore di database di SQL Server rileva automaticamente i clicli di deadlock in SQL Server. Motore di database sceglie una delle sessioni come vittima del deadlock e la transazione corrente viene terminata con un errore per interrompere il deadlock.

Risorse che possono causare un deadlock

Per conto di ogni sessione utente possono essere in esecuzione una o più attività e ogni attività può acquisire o attendere di acquisire risorse diverse. Di seguito sono elencati i tipi di risorse che possono causare blocchi che potrebbero provocare un deadlock.

Blocchi. L'attesa di acquisizione di blocchi sulle risorse, ad esempio oggetti, pagine, righe, metadati e applicazioni, può causare deadlock. La transazione T1, ad esempio, prevede un blocco condiviso (S) sulla riga r1 ed è in attesa di ottenere un blocco esclusivo (X) su r2. La transazione T2 prevede un blocco condiviso (S) su r2 ed è in attesa di ottenere un blocco esclusivo (X) sulla riga r1. Il risultato è un ciclo di blocco in cui T1 e T2 attendono che le risorse bloccate vengano rilasciate dall'altra attività.
Thread di lavoro. Un'attività in coda in attesa di un thread di lavoro disponibile può causare un deadlock. Se l'attività in coda è proprietaria di risorse che bloccano tutti i thread di lavoro, si verifica un deadlock. La sessione S1 avvia ad esempio una transazione e acquisisce un blocco condiviso (S) sulla riga r1 e quindi va in pausa. Le sessioni attive in esecuzione in tutti i thread di laovor disponibili cercano di acquisire blocchi esclusivi (X) sulla riga r1. Poiché la sesisone S1 non riesce ad acquisire un thread di lavoro, non può eseguire la transazione e rilasciare il blocco sulla riga r1. Di conseguenza, si verifica un deadlock.
Memoria. Quando richieste simultanee sono in attesa di concessioni di memoria che non possono essere siddisfatte con la memoria disponibile, può verificarsi un deadlock. Due query simultanee, Q1 e Q2, vengono ad esempio eseguite come funzioni definite dall'utente che acquisiscono rispettivamente 10 MB e 20 MB di memoria. Se per ogni query sono necessari 30 MB e la memoria disponibile totale è di 20 MB, Q1 e Q2 devono attendere che ognuna rilasci memoria e di conseguenza si verifica un deadlock.
Risorse per l'esecuzione di query parallele Thread coordinator, producer o consumer associati a una porta di scambio possono bloccarsi a vicenda causando un deadlock, generalmente quando è incluso almeno un altro processo che non fa parte della query parallela. Quando inoltre viene avviata l'esecuzione di una query parallela, SQL Server determina il grado di parallelismo o il numero di thread di lavoro sulla base del carico di lavoro corrente. Se il carico di lavoro del sistema cambia inaspettatamente, ad esempio per l'avvio di nuove query o per l'esaurimento dei thread di lavoro, è possibile che si verifichi un deadlock.
Risorse MARS (Multiple Active Result Sets). Queste risorse sono utilizzate per controllare in che modo più richieste attive vengono intercalate con il servizio MARS. Per ulteriori informazioni, vedere Ambiente di esecuzione del batch e MARS.
- Risorsa utente. Quando un thread è in attesa di una risorsa che è potenzialmente controllata da un'applicazione utente, la risorsa viene considerata risorsa esterna o utente e viene trattata come un blocco.
- Mutex della sessione. Le attività in esecuzione in una sessione vengono intercalate, ovvero solo un'attività può essere eseguita in una sessione in un determinato momento. Per poter essere eseguita, l'attività deve disporre di accesso esclusivo al mutex della sessione.
- Mutex della transazione. Tutte le attività in esecuzione in una transazione vengono intercalate, ovvero solo un'attività può essere eseguita in una transazione in un determinato momento. Per poter essere esguita, l'attività deve disporre di accesso esclusivo al mutex della transazione.
Per essere eseguita in un servizio MARS, l'attività deve acquisire il mutex della sessione. Se l'attività è in esecuzione in una transazione, deve acquisire il mutex della transazione. Questo consente di garantire che sia attiva una sola attività per volta in una determinata sessione e in una determinata transazione. Dopo che i mutex richiesti sono stati acquisiti, l'attività può essere eseguita. Quando l'attività termine, oppure restituisce il risultato a metà della richiesta, viene rilasciato prima il mutex della transazione, seguito da quello della sessione, in ordine inverso rispetto a quello di acquisizione. In queste risorse, tuttavia, possono verificarsi deadlock. Nell'esempio di codice seguente vengono illustrate due attività, richiesta utente U1 e richiesta utente U2, in esecuzione nella stessa sessione.
```
U1:    Rs1=Command1.Execute("insert sometable EXEC usp_someproc");
U2:    Rs2=Command2.Execute("select colA from sometable");
```
La stored procedure in esecuzione dall'attività richiesta utente U1 ha acquisito il mutex della sessione. Se per l'esecuzione della stored procedure è necessario molto tempo, in Motore di database viene considerato che la stored procedure è in attesa dell'input dell'utente. La richiesta utente U2 è in attesa del mutex della sessione menttre l'utente è in attesa del set di risultati da U2 e U1 è in attesa di una risorsa utente. La rappresentazione logica di tale condizione di deadlock è la seguente:

Diagramma logico che illustra il deadlock di un processo utente

Rilevamento di deadlock

Tutte le risorse elencate nella sezione precedente fanno parte dello schema di rilevamento dei deadlock di Motore di database. Il rilevamento dei deadlock viene esgeuito da un thread di monitoraggio dei blocchi tramite il quale viene periodicamente iniziata una ricerca in tutte le attività in un'istanza di Motore di database. Il processo di ricerca è descritto dai punti seguenti:

L'intervallo predefinito è 5 secondi.
Se tramite il thread di monitoraggio dei blocchi vengono individuati deadlock, l'intervallo di rilevamento dei deadlock scende da 5 secondi a un minimo di 100 millisecondi, in base alla frequenza dei deadlock.
Se tramite il thread di monitoraggio dei blocchi non vengono trovati ulteriori deadlock, in Motore di database gli intervalli tra le ricerche vengono aumentati a 5 secondi.
Se viene rilevato un deadlock, si presuppone che i thread successivi che devono attendete un blocco stiano entrando nel ciclo di deadlock. La prima coppia di attese di blocco dopo il rilevamento di un deadlock genera immediatamente una ricerca di deadlock senza che venga atteso l'intervallo successivo di rilevamento dei deadlock. Se, ad esempio, l'intervallo attuale è di 5 secondi ed è appena stato rilevato un deadlock, l'attesa di blocco successiva provoca l'avvio immediato della funzionalità di rilevamento di deadlock. Se l'attesa di blocco fa parte di un deadlock, verrà rilevata immediatamente e non nel corso della ricerca di deadlock succesisva.

In Motore di database vengono in genere eseguite solo attività di rilevameno di deadlock periodiche. Poiché il numero di deadlock di un sistema in genere è ridotto, il rilevamento periodico consente di ridurre l'overhead associato all'operazione di ricerca.

Dopo l'avvio di una ricerca di deadlock per un thread specifico, viene identificata la risorsa di cui il thread è in attesa e vengono individuati il proprietario o i proprietari della risorsa. La ricerca di deadlock viene quindi ripetuta in modo ricorsivo per gli stessi thread fino all'individuazione di un ciclo. Un ciclo identificato in questo modo crea un deadlock.

Dopo essere stato rilevato, un deadlock viene terminato da Motore di database tramite la scelta di una vittima del deadlock. Tramite Motore di database viene terminato il batch attualmente in esecuzione per il thread, viene eseguito il rollback della transazione della vittima del deadlock e viene restituito all'applicazione un errore 1205. Tramite il rollback della transazione per la vittima del deadlock vengon rilasciati tutti i blocchi della transazione. In questo modo, le transazioni degli altri thread vengono sbloccate e possono continuare. Tramite l'errore 1205 relativo alla vittima del deadlock vengono registrate nel log degli errori le informazioni sulle risorse e i thread coinvolti.

Per impostazione predefinita, tramite Motore di database viene scelta come vittima del deadlock la sessione in cui è in esecuzione la transazione il cui rollback è meno costoso. In alternativa, è possibile specificare la priorità delle sessioni in una situazione di deadlock utilizzando l'istruzione SET DEADLOCK_PRIORITY. Il valore di DEADLOCK_PRIORITY può essere impostato suLOW, NORMAL o HIGH oppure è possibile utilizzare qualsiasi valore intero compreso tra -10 e 10. L'impostazione predefinita per priorità di deadlock è NORMAL. Se le priorità di deadlock di due sessioni sono diverse, come vittima del deadlock verrà scelta la sessione con la priorità inferiore. Se entrambe le sessioni hanno la stessa priorità di deadlock, verrà scelta la sessione con la transazione il cui rollback è meno costoso. Se le sessioni coinvolte nel ciclo di deadlock hanno la stessa priorità di deadlock e lo stesso costo, la vittima viene scelta in modo casuale.

Quando si utilizza l'ambiente CLR, tramite la funzionalità di monitoraggio vengono automaticamente rilevati i deadlock per le risorse di sincronizzazione, ovvero monitor, blocchi di lettura/sacrittura e join di thread, a cui viene eseguito l'accesso all'interno di procedure gestite. Il deadlock viene tuttavia risolto generando un'eccezione nella procedura selezionata come vittima del deadlock. È importante comprendere che l'eccezione non comporta il rilascio automatico delle risorse attualemtne di proprietà della vittima, ma le risorse devono essere rilasciate esplicitamente. In modo coerente con il comportamente dell'eccezione, l'eccezione utilizzata per identificare una vittima del deadlock può essere intercettata e ignorata.

Strumenti di informazione sui deadlock

Per la visualizzazione di informazioni sui deadlock, il Motore di database offre strumenti di monitoraggio costituiti da due flag di traccia e da un evento grafico di deadlock in SQL Server Profiler.

Flag di traccia 1204 e flag di traccia 1222

In caso di deadlock, il flag di traccia 1204 e il flag di traccia 1222 restituiscono informazioni che vengono riportate nel log degli errori di SQL Server 2005. Il flag di traccia 1204 riporta informazioni sui deadlock formattate per ogni nodo interessato dal deadlock. Il flag di traccia 1222 formatta le informazioni sui deadlock, prima per processi e poi per risorse. È possibile attivare entrambi i flag di traccia per ottenere due diverse rappresentazioni dello stesso evento di deadlock.

Nella tabella seguente vengono illustrate le proprietà dei flag di traccia 1204 e 1222, nonché le relative similitudini e differenze.

Proprietà Flag di traccia 1204 e flag di traccia 1222 Solo flag di traccia 1204 Solo flag di traccia 1222

Proprietà	Flag di traccia 1204 e flag di traccia 1222	Solo flag di traccia 1204	Solo flag di traccia 1222
Formato di output	L'output viene acquisito nel log degli errori di SQL Server 2005.	Mirato ai nodi interessati dal deadlock. Ogni nodo ha una sezione dedicata e la sezione finale descrive la vittima del deadlock.	Restituisce informazioni in un formato simile all'XML ma non conforme a uno schema XSD (XML Schema Definition). Il formato presenta tre sezioni principali. Nella prima sezione viene dichiarata la vittima del deadlock. Nella seconda sezione viene descritto ogni processo interessato dal deadlock. Nella terza sezione vengono descritte le risorse che rappresentano un sinonimo dei nodi indicati nel flag di traccia 1204.
Identificazione degli attributi	SPID:<x> ECID:<x>. Identifica il thread dell'ID del processo di sistema in presenza di processi paralleli. La voce `SPID:<x> ECID:0`, dove <x> viene sostituita dal valore di SPID, rappresenta il thread principale. La voce `SPID:<x> ECID:<y>`, dove <x> viene sostituita dal valore di SPID e <y> è maggiore di 0, rappresenta i sottothread dello stesso SPID. BatchID (sbid per il flag di traccia 1222). Identifica il batch da cui l'esecuzione del codice richiede o mantiene un blocco. Quando MARS (Multiple Active Result Sets) è disattivato, il valore di BatchID è 0. Quando MARS è attivato, il valore dei batch attivi è compreso tra 1 e n. Se la sessione non contiene batch attivi, BatchID è 0. Mode. Specifica il tipo di blocco per una determinata risorsa richiesta, concessa o attesa da un thread. Mode può essere IS (Preventivo condiviso), S (Condiviso), U (Aggiornamento), IX (Preventivo esclusivo), SIX (Condiviso preventivo esclusivo) e X (Esclusivo). Per ulteriori informazioni, vedere Modalità blocco. Line # (line per il flag di traccia 1222). Elenca il numero di riga del batch di istruzioni corrente che era in esecuzione quando si è verificato il deadlock. Input Buf (inputbuf per il flag di traccia 1222). Elenca tutte le istruzioni del batch corrente.	Node. Rappresenta il numero di voce nella catena del deadlock. Lists. Il proprietario del blocco può essere parte degli elenchi segunti: Grant List. Enumera i proprietari correnti della risorsa. Convert List. Enumera i proprietari correnti che stanno tentando di convertire i propri blocchi a un livello superiore. Wait List. Enumera le nuove richieste di blocco correnti per la risorsa. Statement Type. Descrive il tipo di istruzione DML (SELECT, INSERT, UPDATE o DELETE) su cui i thread hanno autorizzazioni. Victim Resource Owner. Specifica il thread partecipante che SQL Server sceglie come vittima per interrompere il ciclo di deadlock. Il thread scelto e tutti i sottothread esistenti vengono terminati. Next Branch. Rappresenta i due o più sottothread legati allo stesso SPID che sono interessati dal ciclo di deadlock.	deadlock victim. Rappresenta l'indirizzo di memoria fisica dell'attività (vedere sys.dm_os_tasks) selezionata come vittima del deadlock. In caso di deadlock risolto, il valore può essere 0 (zero). Un'attività in cui è in corso l'esecuzione del rollback non può essere scelta come vittima del deadlock. executionstack. Rappresenta il codice Transact-SQL in esecuzione al momento del deadlock. priority. Rappresenta la priorità di deadlock. In alcuni casi, la priorità di deadlock potrebbe essere modificata da Motore di database per un breve intervallo di tempo, per ottenere una concorrenza migliore. logused. Spazio del log utilizzato dall'attività. owner id. ID della transazione che ha il controllo della richiesta. status. Stato dell'attività. I possibili valori sono i seguenti: pending. In attesa di un thread di lavoro. runnable. Pronto per l'esecuzione ma in attesa di un quantum. running. In esecuzione nell'utilità di pianificazione. suspended. Esecuzione sospesa. done. Attività completata. spinloop. In attesa che venga liberato uno spinlock. waitresource. Risorsa necessaria per l'attività. waittime. Tempo, in millisecondi, di attesa per la risorsa. schedulerid. Utilità di pianificazione associata all'attività. Vedere sys.dm_os_schedulers. hostname. Nome della workstation. isolationlevel. Livello di isolamento delle transazioni corrente. Xactid. ID della transazione che ha il controllo della richiesta. currentdb. ID del database. lastbatchstarted. Ultima volta in cui un processo client ha avviato un'esecuzione del batch. lastbatchcompleted. Ultima volta in cui un processo client ha completato un'esecuzione del batch. clientoption1 e clientoption2. Opzioni SET nella connessione client. Si tratta di una maschera di bit che include informazioni sulle opzioni generalmente controllate da istruzioni SET, ad esempio SET NOCOUNT e SET XACTABORT. associatedObjectId. Rappresenta l'ID di HoBT (Heap Or B-Tree).
Attributi risorsa	RID. Identifica la singola riga di una tabella su cui un blocco viene mantenuto o richiesto. RID è rappresentato come RID: db_id:file_id:page_no:row_no. Ad esempio, `RID: 6:1:20789:0`. OBJECT. Identifica la tabella su cui un blocco viene mantenuto o richiesto. OBJECT è rappresentato come OBJECT: db_id:object_id. Ad esempio, `TAB: 6:2009058193`. KEY. Identifica l'intervallo di chiavi di un indice su cui un blocco viene mantenuto o richiesto. KEY è rappresentato come KEY: db_id:hobt_id (index key hash value). Ad esempio, `KEY: 6:72057594057457664 (350007a4d329)`. PAG. Identifica la risorsa di pagina su cui un blocco viene mantenuto o richiesto. PAG è rappresentato come PAG: db_id:file_id:page_no. Ad esempio, `PAG: 6:1:20789`. EXT. Identifica la struttura extent. EXT è rappresentato come EXT: db_id:file_id:extent_no. Ad esempio, `EXT: 6:1:9`. DB. Identifica il blocco del database. DB è rappresentato in uno dei modi seguenti: DB: db_id DB: db_id[BULK-OP-DB], che identifica il blocco di database applicato dal database di backup. DB: db_id[BULK-OP-LOG], che identifica il blocco applicato dal log di backup per un particolare database. APP. Identifica il blocco applicato da una risorsa di un'applicazione. APP è rappresentato come APP: lock_resource. Ad esempio, `APP: Formf370f478`. METADATA. Rappresenta le risorse di metadati interessate da un deadlock. Poiché METADATA ha molte sottorisorse, il valore restituito dipende dalla sottorisorsa interessata dal deadlock. METADATA.USER_TYPE restituisce ad esempio `user_type_id =` <integer_value>. Per ulteriori informazioni sulle risorse e le sottorisorse di METADATA, vedere sys.dm_tran_locks. HOBT. Rappresenta un heap o una struttura b-tree interessata da un deadlock.	Nessuna esclusiva di questo flag di traccia.	Nessuna esclusiva di questo flag di traccia.

Formato di output

L'output viene acquisito nel log degli errori di SQL Server 2005.

Mirato ai nodi interessati dal deadlock. Ogni nodo ha una sezione dedicata e la sezione finale descrive la vittima del deadlock.

Restituisce informazioni in un formato simile all'XML ma non conforme a uno schema XSD (XML Schema Definition). Il formato presenta tre sezioni principali. Nella prima sezione viene dichiarata la vittima del deadlock. Nella seconda sezione viene descritto ogni processo interessato dal deadlock. Nella terza sezione vengono descritte le risorse che rappresentano un sinonimo dei nodi indicati nel flag di traccia 1204.

Identificazione degli attributi

SPID:<x> ECID:<x>. Identifica il thread dell'ID del processo di sistema in presenza di processi paralleli. La voce SPID:<x> ECID:0, dove <x> viene sostituita dal valore di SPID, rappresenta il thread principale. La voce SPID:<x> ECID:<y>, dove <x> viene sostituita dal valore di SPID e <y> è maggiore di 0, rappresenta i sottothread dello stesso SPID.

BatchID (sbid per il flag di traccia 1222). Identifica il batch da cui l'esecuzione del codice richiede o mantiene un blocco. Quando MARS (Multiple Active Result Sets) è disattivato, il valore di BatchID è 0. Quando MARS è attivato, il valore dei batch attivi è compreso tra 1 e n. Se la sessione non contiene batch attivi, BatchID è 0.

Mode. Specifica il tipo di blocco per una determinata risorsa richiesta, concessa o attesa da un thread. Mode può essere IS (Preventivo condiviso), S (Condiviso), U (Aggiornamento), IX (Preventivo esclusivo), SIX (Condiviso preventivo esclusivo) e X (Esclusivo). Per ulteriori informazioni, vedere Modalità blocco.

Line # (line per il flag di traccia 1222). Elenca il numero di riga del batch di istruzioni corrente che era in esecuzione quando si è verificato il deadlock.

Input Buf (inputbuf per il flag di traccia 1222). Elenca tutte le istruzioni del batch corrente.

Node. Rappresenta il numero di voce nella catena del deadlock.

Lists. Il proprietario del blocco può essere parte degli elenchi segunti:

Grant List. Enumera i proprietari correnti della risorsa.
Convert List. Enumera i proprietari correnti che stanno tentando di convertire i propri blocchi a un livello superiore.
Wait List. Enumera le nuove richieste di blocco correnti per la risorsa.

Statement Type. Descrive il tipo di istruzione DML (SELECT, INSERT, UPDATE o DELETE) su cui i thread hanno autorizzazioni.

Victim Resource Owner. Specifica il thread partecipante che SQL Server sceglie come vittima per interrompere il ciclo di deadlock. Il thread scelto e tutti i sottothread esistenti vengono terminati.

Next Branch. Rappresenta i due o più sottothread legati allo stesso SPID che sono interessati dal ciclo di deadlock.

deadlock victim. Rappresenta l'indirizzo di memoria fisica dell'attività (vedere sys.dm_os_tasks) selezionata come vittima del deadlock. In caso di deadlock risolto, il valore può essere 0 (zero). Un'attività in cui è in corso l'esecuzione del rollback non può essere scelta come vittima del deadlock.

executionstack. Rappresenta il codice Transact-SQL in esecuzione al momento del deadlock.

priority. Rappresenta la priorità di deadlock. In alcuni casi, la priorità di deadlock potrebbe essere modificata da Motore di database per un breve intervallo di tempo, per ottenere una concorrenza migliore.

logused. Spazio del log utilizzato dall'attività.

owner id. ID della transazione che ha il controllo della richiesta.

status. Stato dell'attività. I possibili valori sono i seguenti:

pending. In attesa di un thread di lavoro.
runnable. Pronto per l'esecuzione ma in attesa di un quantum.
running. In esecuzione nell'utilità di pianificazione.
suspended. Esecuzione sospesa.
done. Attività completata.
spinloop. In attesa che venga liberato uno spinlock.

waitresource. Risorsa necessaria per l'attività.

waittime. Tempo, in millisecondi, di attesa per la risorsa.

schedulerid. Utilità di pianificazione associata all'attività. Vedere sys.dm_os_schedulers.

hostname. Nome della workstation.

isolationlevel. Livello di isolamento delle transazioni corrente.

Xactid. ID della transazione che ha il controllo della richiesta.

currentdb. ID del database.

lastbatchstarted. Ultima volta in cui un processo client ha avviato un'esecuzione del batch.

lastbatchcompleted. Ultima volta in cui un processo client ha completato un'esecuzione del batch.

clientoption1 e clientoption2. Opzioni SET nella connessione client. Si tratta di una maschera di bit che include informazioni sulle opzioni generalmente controllate da istruzioni SET, ad esempio SET NOCOUNT e SET XACTABORT.

associatedObjectId. Rappresenta l'ID di HoBT (Heap Or B-Tree).

Attributi risorsa

RID. Identifica la singola riga di una tabella su cui un blocco viene mantenuto o richiesto. RID è rappresentato come RID: db_id:file_id:page_no:row_no. Ad esempio, RID: 6:1:20789:0.

OBJECT. Identifica la tabella su cui un blocco viene mantenuto o richiesto. OBJECT è rappresentato come OBJECT: db_id:object_id. Ad esempio, TAB: 6:2009058193.

KEY. Identifica l'intervallo di chiavi di un indice su cui un blocco viene mantenuto o richiesto. KEY è rappresentato come KEY: db_id:hobt_id (index key hash value). Ad esempio, KEY: 6:72057594057457664 (350007a4d329).

PAG. Identifica la risorsa di pagina su cui un blocco viene mantenuto o richiesto. PAG è rappresentato come PAG: db_id:file_id:page_no. Ad esempio, PAG: 6:1:20789.

EXT. Identifica la struttura extent. EXT è rappresentato come EXT: db_id:file_id:extent_no. Ad esempio, EXT: 6:1:9.

DB. Identifica il blocco del database. DB è rappresentato in uno dei modi seguenti:

DB: db_id
DB: db_id[BULK-OP-DB], che identifica il blocco di database applicato dal database di backup.
DB: db_id[BULK-OP-LOG], che identifica il blocco applicato dal log di backup per un particolare database.

APP. Identifica il blocco applicato da una risorsa di un'applicazione. APP è rappresentato come APP: lock_resource. Ad esempio, APP: Formf370f478.

METADATA. Rappresenta le risorse di metadati interessate da un deadlock. Poiché METADATA ha molte sottorisorse, il valore restituito dipende dalla sottorisorsa interessata dal deadlock. METADATA.USER_TYPE restituisce ad esempio user_type_id = <integer_value>. Per ulteriori informazioni sulle risorse e le sottorisorse di METADATA, vedere sys.dm_tran_locks.

HOBT. Rappresenta un heap o una struttura b-tree interessata da un deadlock.

Nessuna esclusiva di questo flag di traccia.

Esempio di flag di traccia 1204

Nell'esempio seguente viene illustrato l'output che si ottiene quando il flag di traccia 1204 è attivo. In questo caso, la tabella in Node 1 è un heap senza indici e la tabella in Node 2 è un heap con un indice non cluster. La chiave di indice in Node 2 è in corso di aggiornamento quando si verifica il deadlock.

Deadlock encountered .... Printing deadlock information
Wait-for graph

Node:1

RID: 6:1:20789:0               CleanCnt:3 Mode:X Flags: 0x2
 Grant List 0:
   Owner:0x0315D6A0 Mode: X        
     Flg:0x0 Ref:0 Life:02000000 SPID:55 ECID:0 XactLockInfo: 0x04D9E27C
   SPID: 55 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event: 
BEGIN TRANSACTION
EXEC usp_p2
 Requested By: 
   ResType:LockOwner Stype:'OR'Xdes:0x03A3DAD0 
     Mode: U SPID:54 BatchID:0 ECID:0 TaskProxy:(0x04976374) Value:0x315d200 Cost:(0/868)

Node:2

KEY: 6:72057594057457664 (350007a4d329) CleanCnt:2 Mode:X Flags: 0x0
 Grant List 0:
   Owner:0x0315D140 Mode: X        
     Flg:0x0 Ref:0 Life:02000000 SPID:54 ECID:0 XactLockInfo: 0x03A3DAF4
   SPID: 54 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event: 
     BEGIN TRANSACTION
EXEC usp_p1
 Requested By: 
   ResType:LockOwner Stype:'OR'Xdes:0x04D9E258 
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

Victim Resource Owner:
 ResType:LockOwner Stype:'OR'Xdes:0x04D9E258 
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

Esempio di flag di traccia 1222

Nell'esempio seguente viene illustrato l'output che si ottiene quando il flag di traccia 1222 è attivo. In questo caso, una tabella è un heap senza indici e l'altra tabella è un heap con un indice non cluster. Nella seconda tabella, la chiave di indice è in corso di aggiornamento quando si verifica il deadlock.

deadlock-list
 deadlock victim=process689978
  process-list
   process id=process6891f8 taskpriority=0 logused=868 
   waitresource=RID: 6:1:20789:0 waittime=1359 ownerId=310444 
   transactionname=user_transaction 
   lasttranstarted=2005-09-05T11:22:42.733 XDES=0x3a3dad0 
   lockMode=U schedulerid=1 kpid=1952 status=suspended spid=54 
   sbid=0 ecid=0 priority=0 transcount=2 
   lastbatchstarted=2005-09-05T11:22:42.733 
   lastbatchcompleted=2005-09-05T11:22:42.733 
   clientapp=Microsoft SQL Server Management Studio - Query 
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user 
   isolationlevel=read committed (2) xactid=310444 currentdb=6 
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks.dbo.usp_p1 line=6 stmtstart=202 
     sqlhandle=0x0300060013e6446b027cbb00c69600000100000000000000
     UPDATE T2 SET COL1 = 3 WHERE COL1 = 1;     
     frame procname=adhoc line=3 stmtstart=44 
     sqlhandle=0x01000600856aa70f503b8104000000000000000000000000
     EXEC usp_p1     
    inputbuf
      BEGIN TRANSACTION
EXEC usp_p1
   process id=process689978 taskpriority=0 logused=380 
   waitresource=KEY: 6:72057594057457664 (350007a4d329)   
   waittime=5015 ownerId=310462 transactionname=user_transaction 
   lasttranstarted=2005-09-05T11:22:44.077 XDES=0x4d9e258 lockMode=U 
   schedulerid=1 kpid=3024 status=suspended spid=55 sbid=0 ecid=0 
   priority=0 transcount=2 lastbatchstarted=2005-09-05T11:22:44.077 
   lastbatchcompleted=2005-09-05T11:22:44.077 
   clientapp=Microsoft SQL Server Management Studio - Query 
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user 
   isolationlevel=read committed (2) xactid=310462 currentdb=6 
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks.dbo.usp_p2 line=6 stmtstart=200 
     sqlhandle=0x030006004c0a396c027cbb00c69600000100000000000000
     UPDATE T1 SET COL1 = 4 WHERE COL1 = 1;     
     frame procname=adhoc line=3 stmtstart=44 
     sqlhandle=0x01000600d688e709b85f8904000000000000000000000000
     EXEC usp_p2     
    inputbuf
      BEGIN TRANSACTION
EXEC usp_p2    
  resource-list
   ridlock fileid=1 pageid=20789 dbid=6 objectname=AdventureWorks.dbo.T2 
   id=lock3136940 mode=X associatedObjectId=72057594057392128
    owner-list
     owner id=process689978 mode=X
    waiter-list
     waiter id=process6891f8 mode=U requestType=wait
   keylock hobtid=72057594057457664 dbid=6 objectname=AdventureWorks.dbo.T1 
   indexname=nci_T1_COL1 id=lock3136fc0 mode=X 
   associatedObjectId=72057594057457664
    owner-list
     owner id=process6891f8 mode=X
    waiter-list
     waiter id=process689978 mode=U requestType=wait

Evento Deadlock Graph di Profiler

Si tratta di un evento in SQL Server Profiler che presenta una descrizione grafica delle attività e delle risorse coinvolte in un deadlock. Nell'esempio seguente viene illustrato l'output prodotto da SQL Server Profiler quando l'evento Deadlock Graph è attivo.

Diagramma di flusso logico che illustra il deadlock di un processo utente

Per ulteriori informazioni sull'esecuzione di un evento Deadlock Graph di SQL Server Profiler, vedere Analisi dei deadlock con SQL Server Profiler.

Vedere anche

Cronologia modifiche

Versione	Cronologia
5 dicembre 2005	Contenuto modificato Aggiunta di una tabella in cui vengono confrontati il flag di traccia 1204 e il flag di traccia 1222. Aggiunta di informazioni sugli attributi di entrambi i flag di traccia. Revisione degli esempi per maggiore chiarezza.