Individuazione dei blocchi acquisiti in una query su SQL Server?

Question

Ho una dichiarazione SQL dalla mia applicazione. Mi piacerebbe sapere quali serrature questa affermazione acquisisce; come posso farlo con il server SQL? La dichiarazione è stata coinvolta in un deadlock, che sto cercando di analizzare; Non riesco a riprodurre lo stallo. Sono in esecuzione su MS SQL Server 2005.

Answer 1

Suggerisco di attivare i flag di traccia di rilevamento deadlock in prima istanza, anziché eseguire una traccia di Profiler a tempo indeterminato.

In questo modo, i dettagli dell'evento verranno registrati nel log degli errori di SQL Server.

Rivedere la seguente documentazione di riferimento in linea per i dettagli dei vari flag di traccia. È necessario utilizzare il 1204 e/o 1222

http://msdn.microsoft.com/en-us/library/ms188396(SQL.90).aspx

Assicurarsi di abilitare il flag di traccia con ambito server e non solo la sessione corrente. Ad esempio, utilizzare:

DBCC TRACEON(1222,-1) 

Answer 2

eseguire una traccia nel profiler (selezionare il modello vuoto), selezionare l'evento del grafico di deadlock e nella nuova scheda visualizzata (Impostazioni di estrazione eventi), salvare ciascuno (controllare separatamente gli eventi XML deadlock) nel proprio file. Apri questo file in un visualizzatore xml e sarà facile dire cosa sta succedendo. Ogni processo è contenuto, con una serie di chiamate di procedura, ecc. E anche tutte le serrature sono presenti.

Lasciare eseguire questa traccia fino a quando non si verifica nuovamente il deadlock, le informazioni vengono registrate solo quando si verifica un deadlock, quindi non troppo carico. Se non succede mai più, bene è risolto, se non hai catturato tutte le informazioni.

Answer 3

È possibile eseguire l'istruzione in una transazione, ma non eseguire il commit della transazione. Poiché le serrature verranno conservate fino a quando la transazione non viene confermata, questo ti dà il tempo di ispezionare le serrature. (Non a tempo indeterminato, ma come 5 minuti per impostazione predefinita.)

come:

BEGIN TRANSACTION 
select * from table 

Poi aprire Management Studio e controllare le serrature. Sono in Gestione -> Monitoraggio attività -> Blocchi per oggetto o Blocchi per processo. Dopo aver terminato, esegui:

COMMIT TRANSACTION 

per liberare le serrature.

Answer 4

È possibile eseguire una traccia di profiler sulla casella di sviluppo per le query e vedere esattamente quali blocchi vengono presi. Solitamente si tratta di un'enorme quantità di dati, ma in gran parte si tratterà di modelli su cui è possibile sfogliare. Per esempio. per l'isolamento di read commesso, vedrai una serie di blocchi acquisiti e rilasciati mentre esegui una scansione di tabella o indice (ogni riga deve essere bloccata prima di essere letta, e viene immediatamente rilasciata dopo la lettura).

Quale isolamento corri? Che tipo di domande sono deadlocking? Stai usando transazioni esplicite che comprendono più aggiornamenti o sono un deadlocking di dichiarazioni singole?

Il caso più comune per un deadlock è una transazione con la sequenza (tabella di aggiornamento x, tabella di aggiornamento y) e una seconda transazione con la sequenza (tabella di aggiornamento y, tabella di aggiornamento x). La soluzione comune è assicurarsi di utilizzare la stessa sequenza di aggiornamento tra le query.

Facci sapere che tipo di query sono, ci sono diversi problemi comuni per diversi tipi di transazioni.

Answer 5

Ecco una query che mostra tutti i blocchi attivi, chi li ha ricevuti e su quale oggetto si trovano. L'ho estratto da un articolo tecnico o qualcosa anni e anni fa. Funziona su SQL 2000 e 2005 (modifica sysobjects in sys.objects per 2005.) Decommenta la clausola WHERE se desideri limitarla solo a questo databse e solo ai blocchi "EXCLUSIVE".

select 'Locks' as Locks, 
    spid, nt_username, name, hostname, loginame, waittime, open_tran, 
    convert(varchar ,getdate() - last_batch, 114) as TimeSinceLastCommand, 
    case req_mode 
    when 0 then 'Not granted' 
    when 1 then 'Schema stability' 
    when 2 then 'Schema modification' 
    when 3 then 'Intent shared' 
    when 4 then 'Shared intent update' 
    when 5 then 'Intent shared shared' 
    when 6 then 'Intent exclusive' 
    when 7 then 'Shared Intent Exclusive' 
    when 8 then 'Shared' 
    when 9 then 'Update' 
    when 10 then 'Intent insert NULL' 
    when 11 then 'Intent shared exclusive' 
    when 12 then 'Intent update' 
    when 13 then 'Intent shared-update' 
    when 14 then 'Exclusive' 
    when 15 then 'Bulk operation' 
    else str(req_mode) end as LockMode 
from master..syslockinfo 
    left join sysobjects so on so.id = rsc_objid 
    left join master..sysprocesses sp on sp.spid = req_spid 
--where rsc_dbid = (select db_id()) and ltrim(req_mode) in (6,7,11,14) 

Answer 6

Risoluzione dei problemi deadlock:

http://blogs.msdn.com/bartd/archive/2006/09/09/747119.aspx http://blogs.msdn.com/bartd/archive/2006/09/13/751343.aspx

deadlock riproduzione del

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/01/01/reproducing-deadlocks-involving-only-one-table.aspx