Come posso dimostrare che NOLOCK è la fonte di problemi di deadlock?

Non sto cercando di avviare una discussione di tipo Windows / Mac.

Personalmente, non ho bisogno di alcuna convinzione che NOLOCKnon sia una buona idea come pratica riflessiva. Sembra che quando stai sviluppando tutto dovrebbe essere intenzionale, non reazionario (/ amen)

Quindi ... insiste NOLOCKil programmatore responsabile è la strada da percorrere. Raccomanda con tutte le query ad hoc e ogni volta che si interroga la produzione. Non ho visto una procedura memorizzata senza suggerimenti nolock su ogni tabella.

Non voglio essere quel ragazzo che entra e dice a tutti che una convinzione fondamentale è tutta sbagliata senza qualcosa per sostenerla.

Basta guardare le sessioni di commento sotto i vari post del blog, inviare un collegamento potrebbe non essere sufficiente. Credenze di vecchia data ecc ... Alcune persone non sono convinte che sia un problema. Vedi: sezione Commenti sotto ogni post sul blog di nolock che ho letto.

Attualmente alcuni altri DBA stanno lottando con alcuni misteriosi deadlock. Come si determina se i NOLOCK sono la fonte?

È stato suggerito di guardare XML da tracce ecc., Ma questo non affermerà esplicitamente che i deadlock causano il problema, vero? Non ho mai visto messaggi di errore così diretti. è vero?

In quale altro modo questi deadlock potrebbero essere bloccati su questo?

Dichiarazioni DDL come CREATEsarebbero un indizio. C'è qualche output che potrei indicare o qualche dato che potrei trovare che possa aiutare a confermare la mia teoria prima di dare l'allarme?

O sto eseguendo flag di traccia o eventi estesi per identificare cosa è in esecuzione quando si verificano i deadlock e quindi deducendo dalle istruzioni DDL?

Osservando tutti i diversi modi in cui i dati possono essere confusi con i suggerimenti di Nolock, sembra un problema difficile da definire con precisione.

L'architetto responsabile come insiste NOLOCKè la strada da percorrere. Raccomanda con tutte le query ad hoc e ogni volta che si interroga la produzione. Non ho visto uno sproc senza accenni nolock su ogni tavolo.

Mi dispiace sentirlo. Questo è universalmente considerato un anti-modello tra i professionisti esperti di SQL Server, ma potrebbe non esserci nulla che tu possa fare per cambiare i fatti sul campo se la pratica è veramente radicata e basata sulle credenze sincere e profondamente radicate di una persona .

La domanda dice che "l'invio di un collegamento potrebbe non essere sufficiente", ma non è chiaro ciò che si desidera invece. Potremmo scrivere l'argomento più avvincente del mondo in una risposta qui, e rimarrebbe comunque "inviando un collegamento" ad esso. Alla fine, nessuno qui può sapere quale serie di argomenti avrà successo nella tua specifica situazione (se presente).

Tuttavia, quanto segue copre la maggior parte dei punti che alcune persone trovano abbastanza convincenti da cambiare una pratica precedentemente comune:

• Cattive abitudini: messa NOLOCKovunque da Aaron Bertrand
• NOLOCKSuggerimento di SQL Server e altre idee scadenti di David Lean (Microsoft)
• Il livello di isolamento letto senza impegno da parte mia
• Giustifica NON utilizzare il suggerimento (nolock) in ogni query (domande e risposte correlate qui)

Anche così, potresti non essere in grado di "vincere" questa battaglia. Ho lavorato in un ambiente che lo ha fatto, compreso i rischi e le ragioni per non farlo, ma ho continuato comunque. Erano persone brillanti e logiche, ma alla fine era un ambiente in cui non potevo essere felice di lavorare.

Attualmente alcuni altri DBA stanno lottando con alcuni misteriosi deadlock. Come si determina che NOLOCKssono la fonte.

Lo schema più usuale (forse più diffuso in passato) in quanto i NOLOCKsuggerimenti sono introdotti nel tentativo di ridurre l'incidenza di deadlock. Questo può "funzionare" nel senso che ridurre il numero di blocchi condivisi adottati riduce naturalmente le possibilità di blocchi bloccati, ma non è una buona soluzione al problema di fondo e viene fornito con tutti gli avvertimenti annotati nella sezione precedente.

Tuttavia, i NOLOCKsuggerimenti possono introdurre nuovi modi di deadlock. L'uso dell'isolamento di lettura senza commit può rimuovere una condizione di blocco transitorio (risolta quando la risorsa contesa diventa disponibile) in un deadlock irrisolvibile (dove nessuno dei due camerieri può fare progressi) semplicemente perché la contesa ora si verifica in un punto diverso, dove ad esempio operazioni di scrittura in un ordine diverso sovrapposizione. Dave Ballantyne ha un esempio qui:

• Crescente deadlock con NOLOCK

Per consigli più generali sulla gestione dei deadlock, come punto di partenza consiglio quanto segue:

• The Difficulty with Deadlocks di Jeremiah Peschka

Dovresti anche familiarizzare con la documentazione:

• Deadlock (e tutti e tre gli argomenti secondari lì)

Altre risorse utili:

• Deadlock di SQL Server per esempio di Gail Shaw
• Risoluzione dei problemi di deadlock di Bart Duncan