INF: Analisi ed evitare deadlock in SQL Server

Traduzione articoli Traduzione articoli
Identificativo articolo: 169960 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Microsoft SQL Server gestisce la consistenza transazionale di integrità e il database utilizzando i blocchi. SQL Server versione 6.5 si avvale di blocco a livello di riga per le operazioni di inserimento, facoltativamente e utilizza il blocco a livello di pagina per altre operazioni. Come è con qualsiasi sistema di database relazionale, il blocco può causare blocchi critici (deadlock) tra gli utenti.

Ad esempio, si supponga che Utente1 (o Connection1) di un blocco dati articolo "A" e richiede un blocco su elemento di dati "b". Utente2 ha un blocco di elemento di dati "B" e ora richiede un blocco su elemento di dati "a". In questo scenario di SQL Server, su Utente1 o Utente2 sarà una vittima del blocco critico (deadlock) e l'altro utente verrà concesso il blocco richiesto.

In SQL Server, lo sviluppatore dell'applicazione possibile decidere quale connessione potrà essere il candidato per la vittima del blocco critico (deadlock) utilizzando l'opzione SET DEADLOCK_PRIORITY. Se lo sviluppatore non indicato la priorità di blocchi critici (deadlock), SQL Server seleziona la vittima del blocco critico (deadlock) scegliendo il processo che viene completata la catena circolare di blocchi.

Applicazione di database sistemi potrebbero comportarsi in modo diverso quando a un altro, il porting da un database relazionale basato sull'implementazione del sistema di database relazionale. Blocco di una delle aree per individuare le modifiche funzionali. In questo articolo viene illustrato come analizzare il deadlock di SQL Server e le tecniche utilizzabili per evitarli.

Informazioni

In questo articolo evidenzia utilizzando l'output di flag di traccia T1204 per analizzare i blocchi critici (deadlock). Quando è impostato il flag di traccia T1204, SQL Server visualizza informazioni sul deadlock quando si verifica. Per utilizzare questo flag di traccia, è possibile utilizzare il comando riportato di seguito un prompt dei comandi per avviare SQL Server:
   sqlservr -c -T1204
				

I risultati di analisi vengono inviati nella finestra della console, a meno che non venga impostato flag di traccia T3605, che invia l'output di analisi nel log degli errori.

Deadlock possono verificarsi quando due connessioni di aggiornano le tabelle in ordine inverso. Ad esempio, una connessione inserito nella tabella "esempio1" primo e quindi in "esempio2", mentre un'altra connessione consente di inserire nella tabella "esempio2" primo e quindi in "esempio1" all'interno di una transazione. Uno scenario di esempio è utile per illustrare come evitare blocchi critici (deadlock).

Le istruzioni SQL utilizzate per creare la tabella utilizzata per questo esempio sono:
   create table example1 (column1 int, column2 char(20), column3 char(50))
   go
   create table example2 (column1 int, column2 char(20), column3 char(50))
   go
   declare @lvar int
   select @lvar = 0
   while @lvar < 500
   begin
   insert into example1 values (@lvar, 'AAA', 'CCC')
   insert into example2 values (@lvar, 'AAA', 'CCC')
   select @lvar = @lvar + 1
   end
   go
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
   create unique clustered index ex2ind1 on example2 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
				

Esempio 1: Tabella inserimenti nell'ordine opposto

In questo esempio, due tabelle inserite in ordine inverso, e si è verificato un blocco critico (deadlock). Blocchi critici (deadlock) d'acconto può inoltre verificarsi quando due o più connessioni eseguono aggiornamenti o eliminazioni su tabelle in ordine inverso.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
				

A questo punto, Connection1 potrebbe bloccare connessione poiché la riga di che inserimento di connessione potrebbe essere sulla stessa pagina in cui Connection1 già ha inserito una riga ed è un blocco.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

A questo punto, connessione potrebbe bloccare Connection1, perché la riga di che inserimento di Connection1 potrebbe essere sulla stessa pagina in cui connessione è già inserito almeno una riga e detiene un blocco. In questo modo un blocco critico (deadlock).

Di seguito è l'output per il flag di traccia 1204 quando si è verificato il deadlock:
97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES (100,
     'AAAA', 'CCC')
   spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (200,
   'AAAB', 'CCC')
   VICTIM: spid 13, pstat 0x0000 , cputime 30
				

Ogni riga della traccia di blocco critico (deadlock) è possibile comunicare agli utenti informazioni su un blocco critico (deadlock). Connection1 è spid 13 e connessione è spid 14 (è possibile determinare lo spid associato a una connessione utilizzando la stored procedure di sp_who).
   >> 97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   The deadlock was detected between spid 13 and spid 14.
   >> spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES
   (100, 'AAAA', 'CCC')
				

SPID 13 è stata richiesta di blocco EX_PAGE ed è stata bloccata dal spid 14, dispone già di blocco EX_PAGE per pagina 0x188 tabella esempio2 dbid 6. Il blocco viene mantenuto nella pagina appartenenti a un indice cluster.
      Indid Value         Description
-------------------------------------
         0                Data page if there is no clustered index, or the
                          leaf page of a clustered index if there is one
         1                Non-leaf page of the clustered index page
       255                Text/image page
    Any other value       Non-clustered secondary index
				

Il comando corrente eseguito da spid 13 è un'istruzione INSERT e la traccia parte del buffer di input.
   >> spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES
   (200, 'AAAB', 'CCC')
				

14 SPID è in attesa di blocco EX_PAGE ed è stato bloccato da spid 13, che contiene già EX_PAGE blocco sulla stessa pagina.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

Di seguito è riportato una spiegazione del significano i vari blocchi nella traccia:

SH_INT e EX_INT
È possibile eseguire i blocchi preventivi vengono prelevati secondo un elemento di livello superiore (ad esempio, una tabella) prima di blocchi a livello inferiore (ad esempio, una pagina), perché il gestore di blocco è riconosce la relazione tra diversi tipi di elementi (in questo caso, le pagine e le tabelle). Se nella tabella, un blocco EX_INT non è stato richiesto prima di passare blocchi EX_PAG nelle pagine, un altro utente potrebbe richiedere un blocco EX_TAB nella stessa tabella e il gestore di blocco sarebbe non conosce l'esistenza di un conflitto. Attualmente, SQL Server sono i blocchi preventivi solo su tabelle. Esistono due tipi di blocchi preventivi: blocchi condivisi (SH_INT) ed esclusivo (EX_INT).

EX_PAGE
Si tratta di un blocco di pagina esclusivo che viene eseguito quando una pagina viene aggiornata a causa di un'istruzione DELETE, UPDATE, o l'istruzione INSERT con Inserisci blocco livello di riga (IRL) disattivato.

UP_PAGE
Questo è un blocco di pagina di aggiornamento che viene eseguito in sostituzione di un blocco di pagine condivise quando una pagina viene analizzata e l'utilità di ottimizzazione sa che la pagina verrà aggiornata (o viene utilizzato l'hint UPDLOCK).

PR_EXT, NX_EXT, UPD_EXT e EX_EXT
Questi blocchi vengono prese l'allocazione o la deallocazione di spazio su disco. UPD_EXT viene eseguita quando l'allocazione o la deallocazione di una pagina da un extent esistente e gli altri vengono utilizzati quando l'allocazione o la deallocazione di extent intero.

IX_PAGE e LN_PAGE
Questi sono i blocchi IRL. IX_PAGE è un blocco intento-a--riga-blocco su una pagina. LN_PAGE viene eseguita quando una pagina in cui venga eseguito IRL, deve essere divisa.

RLOCK e XRLOCK
Attraversamento di un indice b-tree vengono prese tali blocchi a breve termine. Esistono due tipi di questo tipo di blocco: condiviso (RLOCK) ed esclusivo (XRLOCK). I blocchi condivisi vengono eseguiti durante l'analisi, mentre i blocchi esclusivi vengono eseguiti nelle pagine di indice durante un aggiornamento.

EX_TAB
Si tratta di un blocco tabella esclusivo che si verifica quando in query optimizer di SQL Server viene determinato che una scansione della tabella è il modo più efficiente per risolvere una query di aggiornamento (ad esempio, quando non ci sono indici su una tabella). I blocchi EX_TAB visualizzato anche quando si blocca la tabella con TABLOCKX hint o SQL Server eseguita i blocchi di pagina in una tabella per un blocco di tabella.

SH_TAB
Questo è un condivisa verrà analizzato il blocco di tabella viene utilizzata quando l'utilità di ottimizzazione si presuppone che la maggior parte della tabella (o blocco di pagina eseguita) o viene utilizzato l'hint TABLOCK.

Nell'esempio di blocco critico (deadlock) precedente può essere evitato se le due connessioni aggiornano le tabelle nel seguente ordine:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Esempio 2: Inserimenti parti diverse della stessa tabella

Questo blocco critico può verificarsi anche quando due connessioni inserire in parti diverse della stessa tabella in ordine inverso quando righe condividono le pagine. Ad esempio:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example1 VALUES (400, 'AAAA', 'CCC')
				

In questa tabella di esempio, è un indice cluster sulla prima colonna della tabella esempio1. Righe con gli stessi valori per la prima colonna verranno tendono a rientrare nella stessa pagina. Nell'esempio, la seconda riga inserita da Connessione1 probabilmente corrisponderà sulla stessa pagina come prima riga inserita, connessione, perché entrambi hanno un valore di indice cluster di 400. In questo modo connessione al blocco Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Ora connessione potrebbe essere bloccato da Connessione1, causando un blocco critico (deadlock). Di seguito è riportato l'analisi di blocco critico (deadlock):
   97/04/20 12:56:01.40 spid16   *** DEADLOCK DETECTED with spid 15 ***
   spid 16 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 15, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (100,
   'AAAB', 'CCC')
   spid 15 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 16, dbid 6, page 0x8bd, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (400,
   'AAAA', 'CCC')
   VICTIM: spid 16, pstat 0x0000 , cputime 130
				

La richiesta di spid 16 di blocco EX_PAGE per pagina 0x2c5 è bloccata da spid 15, che contiene già blocco EX_PAGE per pagina 0x2c5 dopo era l'inserimento di prima. E spid 15 ottenuto inoltre bloccato da spid 16 in attesa di un blocco EX_PAGE per pagina 0x8db iniziale per il blocco critico (deadlock).

È possibile evitare questo blocco critico di utilizzando il seguente comando per attivare IRL per tabella esempio1:
   sp_tableoption 'example1', 'insert row lock', true
				

Esempio 3: Inserimenti tramite IRL

IRL consente agli utenti due o più di condividere una pagina quando inserisce solo operazioni, che spesso dà come risultato una migliore velocità effettiva. Tuttavia, l'attivazione di IRL non sempre riduce blocchi critici (deadlock). In alcuni casi, IRL può introdurre blocchi critici (deadlock).
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

Con IRL attivato, entrambe le connessioni conterrà un blocco IX_PAGE nella pagina contenente due nuove righe. Se disabilitata IRL, Connection1 sarebbe stato acquistato un blocco EX_PAGE e connessione sarebbe sono stati bloccati immediatamente.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

Connessione a questo punto, è necessario un blocco di pagina esclusivo per eseguire un'istruzione UPDATE, che è incompatibile con blocco IX_PAGE del Connection1. Di conseguenza, attenderà connessione.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

Ora Connection1 potrebbe essere bloccato per la connessione, causando un blocco critico (deadlock). Di seguito è riportato l'analisi di blocco critico (deadlock):
   97/04/20 15:13:50.07 spid17   *** DEADLOCK DETECTED with spid 18 ***
   spid 17 requesting UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 18, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 100 and column2 = 'AAAA'
   spid 18 waiting for UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 17, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   VICTIM: spid 17, pstat 0x0000 , cputime 20
				

SPID 17 (connessione uno) è in attesa per un blocco UP_PAGE, ovvero il primo passaggio per ottenere un blocco di pagina esclusivo. È stato bloccato da spid 18, che contiene il blocco IX_PAGE nella pagina 0x2c5. 18 SPID è in attesa di blocco UP_PAGE sulla stessa pagina e viene bloccato dal blocco IX_PAGE da spid 17. Questo conduce a un blocco critico (deadlock) poiché IX_PAGE blocco è condivisibile, mentre non UP_LOCK. Durante i primo inserimenti, sia il spids ottenuto IX_PAGE blocco sulla stessa pagina e in un secondo momento è tentato di aggiornare il blocco al blocco UP_PAGE, che non è possibile perché blocco UP_PAGE è esclusivo.

L'uno per evitare i deadlock consiste inserire il valore aggiornato direttamente nella tabella anziché l'inserimento e quindi l'aggiornamento della riga nella stessa transazione. Se non è possibile, utilizzando il seguente comando per disattivare IRL sarà di aiuto per evitare il blocco critico (deadlock):
   sp_tableoption 'example1', 'insert row lock', false
				

Esempio 4: Inserimenti a righe nella stessa pagina

Un blocco critico (deadlock) potrebbero anche quando le righe che stanno lavorando la due spids sono diverse ma appartengono alla stessa pagina.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 405
   and column2 = 'AAAA'
				

A questo punto, potrebbe essere bloccato Connection1 dalla connessione. Questa situazione può verificarsi perché Connection1 desidera aggiornare una riga in una pagina di connessione è già inserito in cui una riga.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

A questo punto, connessione potrebbe essere bloccato da Connessione1, che verrà portare a un blocco critico (deadlock). Questa situazione può verificarsi quando tenta di aggiornare una riga in una pagina in cui Connection1 è inserita una riga di connessione. Di seguito è riportato l'analisi di blocco critico (deadlock):
   97/04/20 15:48:21.18 spid20   *** DEADLOCK DETECTED with spid 19 ***
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x2c4, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0xc48, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 405 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 60
				

È possibile evitare questo blocco critico di distribuzione in uscita le righe su pagine diverse. Di un metodo per effettuare questa operazione consiste di ricreare l'indice cluster in questa tabella con un fattore di riempimento di grandi dimensioni. Di seguito è riportato un'istruzione che crea un indice cluster con un fattore di riempimento del 50 %:
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Questa istruzione crea l'indice cluster lasciando metà delle pagine vuoto, tra cui i livelli non foglia dell'indice cluster (a causa dell'opzione PAD_INDEX). Nella tabella occupa doppio la dimensione effettiva, e il numero di righe per pagina è metà di quelle in uso.

Il fattore di riempimento non viene mantenuto in una tabella, la tabella è re-organized al fattore di riempimento specificato solo durante la fase di creazione di indice. Con il passare del tempo, le righe per pagina verranno modificato dal fattore di riempimento specificato durante la creazione dell'indice. In questo caso, potrebbe essere una buona idea ricreare l'indice cluster con il fattore di riempimento desiderato.

Un'altra soluzione per evitare la situazione di blocco critico (deadlock) precedente consiste nel riquadro tabella con colonne fittizie (ad esempio, dummy1 char(255)). Questo aumenta la dimensione di riga e conduce a meno di righe per pagina (come minimo di una riga per pagina). Poiché questo tipo di spaziatura interna è nel tempo, non è necessario ricreare l'indice cluster per mantenere la spaziatura interna (anche se è possibile che si desidera ricreare l'indice cluster per altri motivi). Lo svantaggio di questa tecnica è che lo spazio di archiviazione è sprecato nei campi fittizi.

Esempio 5: Spaziatura righe

Spaziatura righe comporta meno righe per pagina (pertanto un minor numero di deadlock), ma non eliminerà completamente di blocchi critici (deadlock).

Nella tabella di questo esempio, viene riempita esempio1 per occupare una riga per pagina. Le istruzioni utilizzate per creare la tabella per questo esempio sono:
   create table example1 (column1 int, column2 char(20), column3 char(50),
   dummy_column4 char (255), dummy_column5 char (255), dummy_column6 char
   (255))
   go
   create unique index ex1ind5 on example1 (column3, column2, column1,
   dummy_column4, dummy_column5, dummy_column6) with fill factor = 85
   go
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 401
   and column2 = 'AAAA'
				

A questo punto, Connection1 è bloccato da connessione durante l'aggiornamento della riga. Poiché SQL Server deve mantenere la sequenza di pagine puntatori, blocca alla pagina precedente, la pagina successiva e la pagina che viene aggiornata. Poiché la connessione contiene un blocco nella pagina precedente, Connection1 deve attendere connessione esegue il commit della transazione.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

A questo punto, connessione è bloccata da Connessione1 perché è necessario bloccare la pagina precedente, in cui è attualmente bloccata da Connessione1. Il risultato è un blocco critico (deadlock). Di seguito è riportato l'analisi di blocco critico (deadlock):
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x12b5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 101 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0x1531, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 401 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 300
				

Questo blocco critico può essere evitato inserendo righe fittizie tra le righe che vengono viene inserite, aggiornati o eliminati. Ad esempio, se Connection1 funziona (inserimenti, aggiornamenti o eliminazioni) con pk riga = 1 e la connessione funziona con riga pk = 5, inserire una riga tra queste due righe (ad esempio una riga contenente pk = 3) per evitare blocchi critici (deadlock). Anche questo metodo aumenta la dimensione nella tabella, ma potrebbe essere la soluzione migliore per le tabelle di coda fondamentale per l'applicazione.

Esempio 6: Indici non cluster

In alcuni casi, gli indici secondari non cluster potrebbero introdurre blocchi critici (deadlock). In questo esempio, la manutenzione dell'indice secondario introduce blocco critico (deadlock).

Di seguito è riportato l'istruzione che consente di creare l'indice secondario utilizzato in questo esempio:
   create index ex1ind2 on example1 (column3) with fill factor = 90,
   PAD_INDEX
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCBA', ' ', '
   ', ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (300, 'AAAB', 'CCCZ', ' ', '
   ', ' ', ' ')
   Connection2 > UPDATE example1 SET column3 = 'CCBA' where column1 = 105
				

Connessione a questo punto, potrebbe essere bloccato da Connessione1 perché Connection1 potrebbe essere mantiene la pagina di indice non cluster secondario in cui la connessione debba aggiornare.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

Connessione1 a questo punto, potrebbe essere bloccato per la connessione, in un blocco critico (deadlock). Questa situazione può verificarsi quando Connection1 è in attesa di un blocco di aggiornare l'indice non cluster secondario in cui connessione è già inserito e contiene un blocco in tale pagina. Di seguito è riportato l'analisi di blocco critico (deadlock) per questo esempio di blocco critico (deadlock):
   97/04/20 19:05:38.75 spid11   *** DEADLOCK DETECTED with spid 12 ***
   spid 11 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 12, dbid 6, page 0x112f, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCZ' where column1 = 305
   spid 12 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 11, dbid 6, page 0x1108, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCBA' where column1 = 105
   VICTIM: spid 11, pstat 0x0000 , cputime 50
				

Questo blocco critico può essere evitato trascinando l'indice secondario. Non è possibile per l'indice contiene una riga per pagina, in modo che questa situazione può essere evitata solo da eliminando l'indice secondario non cluster o modificando l'applicazione.

Deadlock possono verificarsi con più di due connessioni, nel qual caso l'analisi di blocco critico (deadlock) Elenca la spids di blocco critico e inoltre i blocchi in conflitto. Deadlock possono verificarsi con RLOCK e XRLOCK blocchi, che vengono acquisiti durante l'attraversamento di indice. Blocchi critici (deadlock) può inoltre verificarsi a causa di blocchi di extent (PR_EXT, NX_EXT UPD_EXT & EX_EXT).

Per ulteriori informazioni sull'analisi dei blocchi critici (deadlock), è possibile abilitare i seguenti flag di traccia:

T1200
Stampa tutte le informazioni e rilascio di richiesta di blocco in caso contrario, se un blocco critico (deadlock) è interessato o non. Questo è costoso in termini di prestazioni, ma può essere utile per l'analisi.

T1206
Stampa tutti i blocchi mantenuti attivi da partecipanti spids nel blocco critico.

T1208
Stampa il nome host e il nome del programma fornito dal client. Questo consente di identificare un client partecipano a un blocco critico (deadlock), supponendo che il client specifica un valore univoco per ogni connessione.

Proprietà

Identificativo articolo: 169960 - Ultima modifica: giovedì 16 ottobre 2003 - Revisione: 3.0
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 6.5 Standard Edition
Chiavi: 
kbmt kbhowto kbusage KB169960 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 169960
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.
Dichiarazione di non responsabilità per articoli della Microsoft Knowledge Base su prodotti non più supportati
Questo articolo è stato scritto sui prodotti per cui Microsoft non offre più supporto. L?articolo, quindi, viene offerto ?così come è? e non verrà più aggiornato.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com