Anche se sappiamo tutti che il blocco è essenziale per l'integrità dei dati, non cambia il fatto che può essere una seria spina nel fianco!
Quando vediamo un blocco nel nostro database, spesso assumiamo che qualcosa non va, ma non è sempre così. Nella mia esperienza, la maggior parte del blocco di SQL Server è legittima, ma deve essere studiata e compresa. I deadlock, d'altra parte, sono raramente legittimi! I deadlock sono considerati critici nel mondo di SQL Server perché i processi vengono uccisi automaticamente, poiché SQL Server risolve i deadlock senza richiedere un intervento manuale. Anche in questo caso, anche se sono “risolti”, hanno sicuramente bisogno di essere indagati e compresi.
Esistono alcune strategie di progettazione che possono aiutare a ridurre le occorrenze di blocchi e deadlock di SQL Server nel database:
- Utilizza indici cluster su tabelle ad alto utilizzo
- Evita istruzioni SQL con numero di righe elevato
- Scomponi le transazioni lunghe in molte transazioni più brevi
- Assicurati che le istruzioni UPDATE e DELETE utilizzino gli indici
- Non pianificare la sovrapposizione dei lavori di aggiornamento batch
- Mantieni aggiornate le tue statistiche
E sono sicuro che ce ne sono molti di più, ma la realtà è che puoi seguire tutte le migliori pratiche che ti vengono in mente e avere ancora blocchi e deadlock. Questo perché, nella maggior parte dei casi, i deadlock sono causati da codice dell'applicazione mal progettato. (La tana del coniglio della progettazione delle applicazioni:codifica, isolamento delle transazioni e modelli di accesso. Ma per ora, concentriamoci sull'analisi e la comprensione di blocchi e deadlock).
Blocco e deadlock di SQL Server
La prima sfida con blocchi e deadlock è identificare quando e dove si verificano perché di solito non vengono segnalati, segnalati a posteriori o risolti automaticamente. Per avere una comprensione reale di ciò che sta accadendo nel tuo database in merito a blocchi e deadlock, devi vedere le loro occorrenze nel tempo. Inoltre, per correggere il problema e fermare gli eventi futuri, è necessario arrivare alla causa principale del blocco, armandosi delle informazioni necessarie per ritrasmettere agli sviluppatori dell'applicazione e ponendo così fine al gioco di colpe tra Devs e DBA.
Questo è il motivo per cui mi piace molto Workload Analyzer in Spotlight Cloud. Posso selezionare un intervallo di tempo (un'ora, un giorno o un intervallo personalizzato) e visualizzare il Blocco -attività correlata per quell'intervallo. Immediatamente, ho una migliore comprensione di cosa sta succedendo! Posso vedere i modelli di blocco, confrontare il tasso di blocco nel tempo con un intervallo di tempo precedente, vedere il tasso di blocco in un intervallo di tempo specifico e visualizzare KPI di blocco come Blocco esclusivo, Condiviso e Aggiorna.
Quindi ora voglio arrivare alla causa principale:ecco dove Albero delle dimensioni entra. Posso approfondire e filtrare le informazioni per un intervallo di tempo specifico, consentendomi di vedere le stesse informazioni in dimensioni più profonde come Database , Utenti , Programmi e Istruzioni SQL , mentre elimino il "rumore bianco" mentre procedo, identificando chiaramente la fonte o le fonti del mio problema.
Qui sto guardando quali database stanno riscontrando il maggior numero di blocchi durante l'intervallo di tempo:
Ora approfondirò gli Utenti all'interno del database selezionato:
Quindi, sceglierò di visualizzare l'elenco di Istruzioni SQL causando il blocco che è stato eseguito dall'Utente selezionato nel Database selezionato per l'Intervallo di tempo specificato .
Ora posso vedere tutti i Blocco informazioni correlate per l'istruzione SQL selezionata .
Quindi, se vuoi arrivare alla fine dei tuoi problemi di blocco, blocco e deadlock, ti consiglio di controllare Spotlight Cloud. Spotlight Cloud rende più semplice che mai indagare e comprendere i problemi di blocco all'interno del database e, in definitiva, garantire che il codice dell'applicazione sia privo di deadlock.
