È il NOLOCK (Server suggerimento Sql) cattiva pratica?

StackOverflow https://stackoverflow.com/questions/1452996

Domanda

Sono nel business di fare sito web e le applicazioni che sono non mission critical -> ad es. software bancario, il volo spaziale, intensa applicazione di monitoraggio di cura, ecc Si ottiene l'idea.

Così, con quella dichiarazione di non responsabilità enorme, è brutto utilizzando l'hint NOLOCK in qualche dichiarazione di sql? Un certo numero di anni fa, è stato suggerito da un collega Sql amministratore che dovrei usare NOLOCK se sono felice con una "lettura sporco" che mi darà un po 'più di prestazioni fuori del mio sistema perché ogni lettura non blocca il riga / tabella / qualunque cosa.

Mi è stato anche detto che è una grande soluzione se sto vivendo dead-lock. Così, ho iniziato a seguire quel pensiero per alcuni anni fino a quando un guru Sql mi stava aiutando con un codice casuale e notato che tutte le NOLOCKS nel mio codice SQL. Mi è stato gentilmente rimproverato e ha cercato di spiegare a me (perché non è una buona cosa) e mi sono perso sorta. Ho sentito che l'essenza della sua spiegazione è stata 'si tratta di una soluzione cerotto ad un problema più serio .. soprattutto se stai vivendo deadlocking. Come tale, fissare la radice del problema'.

Ho fatto un po 'googling di recente su di esso e sono imbattuto in questo post .

Quindi, possono alcuni sensei sql db guru si prega di illuminarmi?

È stato utile?

Soluzione

Con NOLOCK suggerimento, il livello di isolamento di transazione per l'istruzione SELECT è READ UNCOMMITTED. Ciò significa che la query può visualizzare i dati sporche e incoerenti.

Questa non è una buona idea di applicare come regola. Anche se questo comportamento lettura sporca è OK per la vostra applicazione mission critical basato sul web, una scansione NOLOCK può causare 601 errore che si concluderà la query a causa di spostamento dei dati a causa della mancanza di chiusura di protezione.

Quando Snapshot Isolation aiuta e quando fa male - MSDN consiglia di utilizzare READ COMMITTED SNAPSHOT piuttosto che ISTANTANEA nella maggior parte delle circostanze.

Altri suggerimenti

Prima di lavorare su Stack Overflow, ero contrario NOLOCK sul principio che si potrebbe potenzialmente eseguire una SELECT con NOLOCK e tornare risultati con i dati che possono essere aggiornati o incoerenti. Un fattore da pensare è il numero di record può essere inserito / aggiornati allo stesso tempo, un altro processo può essere la selezione dei dati dalla stessa tabella. Se questo accade molto poi c'è un'alta probabilità di deadlock a meno che non si utilizza una modalità di database come READ COMMITED SNAPSHOT .

Da allora ho cambiato il mio punto di vista sull'uso di NOLOCK dopo aver assistito come può migliorare le prestazioni SELECT così come eliminare situazioni di stallo su un server SQL in maniera massiccia caricato. Ci sono volte che non si possono preoccuparsi che i dati non è esattamente impegnato al 100% ed è necessario risultati indietro in fretta anche se possono non essere aggiornati.

Ponetevi una domanda quando si pensa di utilizzare NOLOCK:

  

La mia domanda comprendono una tabella che ha un elevato numero di INSERT / comandi UPDATE e me ne frega se i dati restituiti da una query può mancare questi cambiamenti in un dato momento?

Se la risposta è no, allora utilizzare NOLOCK per migliorare le prestazioni.

Ho appena eseguito una rapida ricerca per la parola chiave NOLOCK all'interno della base di codice per Stack Overflow e ho trovato 138 casi, in modo da utilizzare in alcuni posti.

Se non si cura di sporco legge (vale a dire in una situazione prevalentemente READ), poi NOLOCK va bene.

MA , essere consapevoli del fatto che la maggior parte dei problemi di bloccaggio sono causa di non avere gli indici 'corretto' per il carico di lavoro query (supponendo che l'hardware è all'altezza del compito).

E la spiegazione del guru era corretta. Di solito è una soluzione cerotto ad un problema più serio.

Modifica : non sto assolutamente suggerendo che NOLOCK dovrebbe essere usato. Credo che dovrei fatto che, ovviamente, chiaro. (Vorrei sempre e solo usarlo, in circostanze estreme dove l'avevo analizzato che era OK). A titolo di esempio, un po 'indietro ho lavorato su alcuni TSQL che era stato cosparso di NOLOCK per cercare di alleviare i problemi di bloccaggio. Li ho tutti rimossi, implementato gli indici corretti, e tutte le situazioni di stallo andato via.

dubbio è stato un "guru" che aveva avuto alcuna esperienza in alto traffico ...

I siti web sono di solito "sporco" dal momento in cui la persona che sta visualizzando la pagina completamente caricato. Prendere in considerazione una forma che i carichi dal database e quindi salva i dati che sono modificati ?? E 'stupido il modo in cui la gente va su circa sporca legge è tale un no no.

Detto questo, se si dispone di un numero di strati costruire sulle vostre seleziona, si potrebbe essere la costruzione di una ridondanza di pericoloso. Se hai a che fare in scenari di denaro o di stato, quindi è necessario non solo dati transazionali lettura / scrittura, ma una soluzione adeguata concorrenza (qualcosa di più "guru" Non perdete tempo con).

D'altra parte, se si dispone di una ricerca avanzata del prodotto per un sito web (cioè qualcosa che probabilmente non verrà memorizzata nella cache ed essere un po 'intensivo) e hai mai costruito un sito con più di un paio di utenti simultanei ( phenominal quanti "esperti" non hanno), è ridicolo a collo di bottiglia ogni altro processo dietro di esso.

so cosa vuol dire e usarlo al momento opportuno. Il database sarà quasi sempre il collo della bottiglia principale in questi giorni e di essere intelligente su come utilizzare NOLOCK è possibile salvare migliaia in infrastrutture.

EDIT:. Non è solo deadlock si aiuta con, è anche quanto si sta andando a fare tutti gli altri aspettare fino a quando hai finito, o viceversa

Utilizzando NOLOCK Hint in EF4?

Nessuna delle risposte è sbagliato, però un po 'di confusione, forse.

  • Quando l'interrogazione di valori singoli / righe è sempre cattiva pratica da usare NOLOCK -. Probabilmente non avete mai desidera visualizzare informazioni non corrette o forse anche di prendere qualsiasi azione su dati non corretti
  • Quando si visualizzano le informazioni statistiche ruvido, NOLOCK può essere molto utile. Prendere così come un esempio: Sarebbe una sciocchezza di prendere le serrature di leggere il esattamente numero di visualizzazioni di una domanda, o il numero esatto di domande per un tag. Nessuno si preoccupa se si indicano non correttamente 3360 domande con tag "sql-server" ora, ed a causa di un rollback della transazione, 3359 domande dopo un secondo.

Come uno sviluppatore professionista Direi che dipende. Ma io sicuramente seguo GATS e OMG Ponies consigli. Sapere cosa si sta facendo, sapere quando aiuta e quando fa male e

leggi suggerimenti e altre idee povere

quello che potrebbe farvi capire il server sql più profondo. Io generalmente seguire la regola che SQL suggerimenti sono il male, ma purtroppo loro ogni uso ora e poi quando mi stufo con costringendo SQL server fare le cose ... ma questi sono casi rari.

Luca

Quando app-supporto ha voluto rispondere alle query ad-Hock dalla produzione-server utilizzando SQL Server Management Studio (che non sono stati soddisfatti tramite la segnalazione) ho chiesto che usano nolock. In questo modo l'azienda 'main' non è interessato.

Sono d'accordo con alcuni commenti sul NOLOCK suggerimento e in particolare con quelli che dice "usarlo quando è opportuno". Se l'applicazione scritta male e sta usando la concorrenza modo inappropriato - che possono causare l'escalation di blocco. Altamente tabella transazionale anche sono sempre bloccato tutto il tempo a causa della loro natura. Avere una buona copertura dell'indice non aiuterà con il recupero dei dati, ma l'impostazione livello di isolamento READ UNCOMMITTED fa. Anche io credo che l'utilizzo di NOLOCK suggerimento è sicuro, in molti casi, quando la natura dei cambiamenti è prevedibile. Per esempio - nel settore manifatturiero, quando lavori con i viaggiatori stanno attraversando diversi processi con un sacco di inserti di misura, è possibile eseguire in modo sicuro query sul lavoro finito con NOLOCK suggerimento e in questo modo evitare la collisione con altre sessioni che mettono promossi o blocchi esclusivi sul tavolo /pagina. I dati si accede in questo caso è statica, ma può risiedere in un tavolo molto transazionale con centinaia di milioni di record e aggiornamenti migliaia / inserti al minuto. Acclamazioni

Credo che è praticamente mai corretto da utilizzare nolock.

Se stai leggendo una singola riga, quindi l'indice corretto significa che non avrete bisogno di NOLOCK le azioni delle righe individuali vengono completate rapidamente.

Se stai leggendo molte righe per qualcosa di diverso visualizzazione temporanea, e le cure di poter ripetere il risultato, o difendere dal numero prodotto, allora NOLOCK non è appropriato.

NOLOCK è un tag surrogato "non mi importa se questa risposta contiene righe duplicate, file che vengono cancellati, o le righe che non sono mai stati inseriti per cominciare a causa di rollback"

Gli errori che sono possibili sotto NOLOCK:

  • Righe che partita non sono restituiti a tutti.
  • singole righe vengono restituite più volte (tra cui più istanze della stessa chiave primaria)
  • Righe che non corrispondono vengono restituiti.

Qualsiasi azione che può causare una divisione di pagina, mentre il NOLOCK selezionare è in funzione può causare queste cose accadano. Quasi ogni azione (anche una cancellazione) può causare una divisione di pagina.

Quindi:. Se si "sa" che la riga non verrà modificata durante l'esecuzione, non usare nolock, come indice consentirà il recupero efficiente

Se si sospetta che la riga può cambiare mentre la query è in esecuzione, e vi preoccupate per la precisione, non utilizzare nolock.

Se state pensando di NOLOCK a causa di situazioni di stallo, esaminare la struttura piano di query per le scansioni di tabella inaspettati, tracciare le situazioni di stallo e capire perché si verificano. NOLOCK intorno scrive può significare che le query che in precedenza in fase di stallo saranno potenzialmente sia scrivere la risposta sbagliata.

Le soluzioni migliori, quando possibile sono:

  • replica dei dati (utilizzando log-replica) a un database di report.
  • Utilizza snapshot SAN e montare una versione coerente del DB
  • Utilizzare un database che ha un livello migliore fondamentale di isolamento delle transazioni

Il livello di isolamento di transazione di snapshot è stato creato perché MS stava perdendo vendite a Oracle. Oracle utilizza undo / redo log per evitare questo problema. Postgres utilizza MVCC. In futuro MS Heckaton utilizzerà MVCC, ma che è anni di distanza da essere pronti per la produzione.

NOLOCK viene spesso sfruttata come un modo magico per accelerare database di legge, ma cerco di evitare di utilizzarlo whever possibile.

Il set di risultati può contenere le righe che non sono ancora stati commessi, che sono spesso in seguito rollback.

Un errore o risultati possono essere vuote, essere righe mancanti o mostrano la stessa riga più volte.

Questo è perché le altre operazioni si stanno muovendo i dati allo stesso tempo si sta leggendo.

READ COMMITTED aggiunge un ulteriore problema in cui i dati sono danneggiati all'interno di una singola colonna in cui più utenti modificano la stessa cella contemporaneamente.

Nella vita reale, dove si incontrano i sistemi già scritto e l'aggiunta di indici per le tabelle poi drasticamente rallenta il caricamento dei dati di una tabella di dati 14gig, si sono a volte costretti a utilizzare CON NOLOCK nei rapporti e la fine del mese, proessing in modo tale che l'aggregato funtions (somma, conteggio ecc) non fanno riga, pagina, chiusura tavolo e deteriate le prestazioni complessive. Facile a dirsi in un nuovo sistema di non usare mai CON NOLOCK e sull'uso di indici - ma l'aggiunta di indici downgrade gravemente il caricamento dei dati, e quando mi hanno detto, allora, beh, modificare il codice di base per eliminare gli indici, quindi il caricamento di massa quindi ricreare gli indici - che è cosa buona e giusta, se si sta sviluppando un nuovo sistema. Ma non quando si dispone di un sistema già in atto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top