Che cos'è "with (nolock)" in SQL Server?

Qualcuno può spiegare le implicazioni dell'uso with (nolock)sulle query, quando non dovresti / non dovresti usarlo?

Ad esempio, se si dispone di un'applicazione bancaria con tassi di transazione elevati e molti dati in determinate tabelle, in quali tipi di query non andrebbe bene? Ci sono casi in cui dovresti sempre usarlo / non usarlo mai?

WITH (NOLOCK) è l'equivalente dell'utilizzo di READ UNCOMMITED come livello di isolamento della transazione. Pertanto, si corre il rischio di leggere una riga senza commit che viene successivamente ripristinata, ovvero i dati che non sono mai stati inseriti nel database. Pertanto, sebbene possa impedire il blocco delle letture da parte di altre operazioni, comporta un rischio. In un'applicazione bancaria con alti tassi di transazione, probabilmente non sarà la soluzione giusta per qualsiasi problema che stai cercando di risolvere con esso.

La domanda è cosa è peggio:

• un punto morto, o
• un valore sbagliato?

Per i database finanziari, i deadlock sono molto peggiori dei valori errati. So che suona all'indietro, ma ascoltami. L'esempio tradizionale delle transazioni DB è l'aggiornamento di due righe, sottraendo da una e aggiungendole a un'altra. Questo è sbagliato.

In un database finanziario si utilizzano transazioni commerciali. Ciò significa aggiungere una riga a ciascun account. È della massima importanza che queste transazioni vengano completate e che le righe vengano scritte correttamente.

Misurare temporaneamente il saldo del conto non è un grosso problema, ecco a cosa serve la riconciliazione di fine giornata. E è molto più probabile che si verifichi uno scoperto da un conto perché due bancomat vengono utilizzati contemporaneamente rispetto a una lettura non impegnata da un database.

Detto questo, SQL Server 2005 ha corretto la maggior parte dei bug resi NOLOCKnecessari. Pertanto, a meno che non si utilizzi SQL Server 2000 o versioni precedenti, non è necessario.

Ulteriori letture
Versioning a livello di riga

Sfortunatamente non si tratta solo di leggere dati non impegnati. Sullo sfondo potresti finire per leggere le pagine due volte (nel caso di una divisione di pagina) o potresti perdere del tutto le pagine. Quindi i tuoi risultati potrebbero essere molto distorti.

Dai un'occhiata all'articolo di Itzik Ben-Gan . Ecco un estratto:

"Con il suggerimento NOLOCK (o impostando il livello di isolamento della sessione su LEGGI UNCOMMITTED) dici a SQL Server che non ti aspetti coerenza, quindi non ci sono garanzie. Ricorda però che" dati incoerenti "non significa solo che è possibile che vengano visualizzate modifiche senza commit che sono state successivamente ripristinate o modifiche dei dati in uno stato intermedio della transazione. Ciò significa anche che in una semplice query che esegue la scansione di tutti i dati di tabella / indice SQL Server potrebbe perdere la posizione di scansione o si potrebbe finire ottenere la stessa riga due volte . "

L'esempio del libro di testo per l'uso legittimo del suggerimento nolock è il campionamento dei report rispetto a un database OLTP con aggiornamento elevato.

Per fare un esempio attuale. Se una grande banca americana di strada voleva eseguire un rapporto orario alla ricerca dei primi segni di una corsa a livello di città sulla banca, una query non valida poteva scansionare le tabelle delle transazioni che sommavano depositi in contanti e prelievi di contanti per città. Per tale report, la minima percentuale di errore causata dalle transazioni di aggiornamento rollback non ridurrebbe il valore del report.

Non sono sicuro del motivo per cui non stai avvolgendo le transazioni finanziarie nelle transazioni del database (come quando trasferisci fondi da un conto a un altro - non commetti un lato della transazione alla volta - ecco perché esistono transazioni esplicite). Anche se il tuo codice è associato alle transazioni commerciali come sembra, tutte le banche dati transazionali hanno il potenziale per eseguire rollback impliciti in caso di errori o guasti. Penso che questa discussione sia finita per la testa.

In caso di problemi di blocco, implementare il controllo delle versioni e ripulire il codice.

Nessun blocco non restituisce solo valori errati ma restituisce record e duplicati fantasma.

È un'idea sbagliata comune che fa sempre funzionare le query più velocemente. Se non ci sono blocchi di scrittura su una tabella, non fa alcuna differenza. Se nella tabella sono presenti blocchi, è possibile che la query sia più veloce, ma in primo luogo è stato inventato un blocco.

In tutta onestà, qui ci sono due scenari speciali in cui un suggerimento nolock può fornire utilità

1) Database SQL Server pre-2005 che deve eseguire query lunghe su database OLTP live, questo potrebbe essere l'unico modo

2) Applicazione scritta male che blocca i record e restituisce il controllo all'interfaccia utente e i lettori vengono bloccati indefinitamente. Nolock può essere utile qui se l'applicazione non può essere riparata (terze parti ecc.) E il database è pre-2005 o non è possibile attivare il controllo delle versioni.

NOLOCKè equivalente a READ UNCOMMITTED, tuttavia Microsoft dice che non dovresti usarlo per UPDATEo DELETEdichiarazioni:

Per istruzioni UPDATE o DELETE: questa funzionalità verrà rimossa in una versione futura di Microsoft SQL Server. Evita di utilizzare questa funzione nel nuovo lavoro di sviluppo e pianifica di modificare le applicazioni che attualmente utilizzano questa funzione.

http://msdn.microsoft.com/en-us/library/ms187373.aspx

Questo articolo si applica a SQL Server 2005, quindi il supporto NOLOCKesiste se si utilizza quella versione. Al fine di rendere il tuo codice a prova di futuro (supponendo che tu abbia deciso di usare letture sporche) puoi usarlo nelle tue procedure memorizzate:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Puoi usarlo quando stai solo leggendo i dati e non ti importa davvero se potresti recuperare o meno dati che non sono ancora stati impegnati.

Può essere più veloce in un'operazione di lettura, ma non posso davvero dire di quanto.

In generale, sconsiglio di utilizzarlo: la lettura di dati non impegnati può essere alquanto confusa.

Un altro caso in cui di solito va bene è in un database di report, in cui i dati sono forse già obsoleti e le scritture semplicemente non accadono. In questo caso, tuttavia, l'opzione deve essere impostata a livello di database o tabella dall'amministratore modificando il livello di isolamento predefinito.

Nel caso generale: si può utilizzare quando si è molto sicuro che è bene leggere i vecchi dati. La cosa importante da ricordare è che è molto facile sbagliare . Ad esempio, anche se va bene nel momento in cui scrivi la query, sei sicuro che qualcosa non cambierà nel database in futuro per rendere questi aggiornamenti più importanti?

Sarò anche secondo l'idea che probabilmente non è una buona idea nell'app bancaria. O app di inventario. O ovunque tu stia pensando alle transazioni.

Risposta semplice: ogni volta che il tuo SQL non modifica i dati e hai una query che potrebbe interferire con altre attività (tramite blocco).

Vale la pena prendere in considerazione qualsiasi query utilizzata per i report, soprattutto se la query richiede più di, diciamo, 1 secondo.

È particolarmente utile se si dispone di report di tipo OLAP in esecuzione su un database OLTP.

La prima domanda da porsi, però, è "perché mi preoccupo di questo?" Nella mia esperienza, la confusione del comportamento di blocco predefinito spesso si verifica quando qualcuno è in modalità "prova qualsiasi cosa" e questo è un caso in cui non sono improbabili conseguenze impreviste. Troppo spesso è un caso di ottimizzazione prematura e può troppo facilmente rimanere incorporato in un'applicazione "per ogni evenienza". È importante capire perché lo stai facendo, quale problema risolve e se hai effettivamente il problema.

Risposta breve:

Utilizzare solo WITH (NOLOCK)nell'istruzione SELECT su tabelle con un indice cluster.

Risposta lunga:

WITH (NOLOCK) viene spesso sfruttato come un modo magico per accelerare le letture del database.

Il set di risultati può contenere righe non ancora impegnate, che spesso vengono successivamente ripristinate.

Se WITH (NOLOCK) viene applicato a una tabella che ha un indice non cluster, gli indici di riga possono essere modificati da altre transazioni mentre i dati di riga vengono trasmessi in streaming nella tabella dei risultati. Ciò significa che nel set di risultati possono mancare righe o visualizzare la stessa riga più volte.

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

I miei 2 centesimi - ha senso usare WITH (NOLOCK) quando è necessario generare report. A questo punto, i dati non cambieranno molto e non vorrai bloccare quei record.

Se gestisci transazioni finanziarie, non vorrai mai più utilizzarle nolock. nolockè meglio usato per selezionare da tabelle di grandi dimensioni che hanno molti aggiornamenti e non ti interessa se il record che ottieni potrebbe non essere aggiornato.

Poiché i record finanziari (e quasi tutti gli altri record nella maggior parte delle applicazioni) nolockcauserebbero il caos poiché potresti potenzialmente rileggere i dati da un record su cui erano stati scritti e non ottenere i dati corretti.

Ho usato per recuperare un "prossimo batch" per le cose da fare. In questo caso non importa quale articolo esatto e ho molti utenti che eseguono la stessa query.

Usa nolock quando stai bene con i dati "sporchi". Ciò significa che nolock può anche leggere i dati che sono in fase di modifica e / o dati non impegnati.

In genere non è una buona idea usarlo in un ambiente con transazioni elevate ed è per questo che non è un'opzione predefinita per le query.

Uso con il suggerimento (nolock) in particolare nei database SQLServer 2000 ad alta attività. Tuttavia, non sono sicuro che sia necessario in SQL Server 2005. Di recente ho aggiunto quel suggerimento in un SQL Server 2000 su richiesta del DBA del client, perché stava notando molti blocchi di record SPID.

Tutto quello che posso dire è che l'uso del suggerimento NON ci ha fatto del male e sembra aver risolto il problema del blocco. Il DBA di quel particolare cliente ha sostanzialmente insistito sul fatto che usiamo il suggerimento.

A proposito, i database di cui mi occupo sono back-end ai sistemi di reclami medici aziendali, quindi stiamo parlando di milioni di record e oltre 20 tabelle in molti join. In genere aggiungo un suggerimento WITH (nolock) per ogni tabella nel join (a meno che non sia una tabella derivata, nel qual caso non è possibile utilizzare quel particolare suggerimento)

La risposta più semplice è una domanda semplice: hai bisogno che i tuoi risultati siano ripetibili? In caso affermativo, NOLOCKS non è appropriato in nessun caso

Se non è necessaria la ripetibilità, allora nolocks può essere utile, soprattutto se non si ha il controllo su tutti i processi di connessione al database di destinazione.