Wann ist es angebracht, NOLOCK zu verwenden?

Question

Ich habe von Zeit zu Zeit Timeout-Probleme und Deadlocks mit einigen lange laufenden Abfragen.

Ich frage mich, wann ist es am besten, NOLOCK zu verwenden und wo?

Verwenden Sie es auf den Updates & Einsätze? oder liest?

Answer 1

Verwenden Sie diese Option, wenn fehlerhafte Lese- und Phantomaufzeichnungen zulässig sind, dh wenn Sie nichtkritische Berichte regelmäßig ausführen, bei denen die Genauigkeit der Informationen kein primärer Treiber ist, sondern eine Übersicht über das Datenaufkommen hat, oder andere B.

Answer 2

Beachten Sie, dass Sie nolock auf einer Tabelle pro Tabelle angeben können.

Normalerweise verwendete ich Nolock in komplexen SELECT-Abfragen, aber nur für die kleinen Nachschlagetabellen, die fast nie geändert wurden, und für reine Anzeigedaten. Sie kennen die Tabellen, die die Preise für das aktuelle halbe Jahr auflisten, oder die Suche nach IDs nach Zeichenfolgen usw. Dinge, die sich nur mit großen Updates ändern, nach denen die Server normalerweise routinemäßig trotzdem neu gestartet werden.

Diese verbesserte Leistung signifikant, reduziert die Wahrscheinlichkeit von Deadlocks in den verkehrsreichsten Zeiten, und noch wichtiger war es in den schlimmsten Fällen für Abfragen, die viele Tabellen berührt (was logisch ist, müssen sie weniger Sperren erhalten) , und diese Beilagen werden oft fast überall verwendet, oft von 7-8 bis 4 Tabellen, die gesperrt werden müssen)

Aber seien Sie sehr vorsichtig hinzufügen, es nicht überstürzen, und tun Sie es nicht routinemäßig. Es wird nicht schaden, wenn es richtig benutzt wird, aber es wird furchtbar weh tun, wenn es unsachgemäß benutzt wird.

Verwenden Sie es nicht für hochkritisches Zeug, Zeug, das usw. berechnet, weil es inkonsistent wird, alles, was früher oder später zu einem Schreiben führt.

Eine andere solche Optimierung ist ROWLOCK, die nur auf Zeilenebene sperrt. Dies ist vor allem beim Aktualisieren (oder Löschen von) von Tabellen hilfreich, in denen die Zeilen nicht miteinander verwandt sind, wie Tabellen, in denen Sie nur Protokollsätze eingeben (und die Reihenfolge, in der sie eingefügt werden, spielt keine Rolle). Wenn Sie ein Schema haben, dass irgendwo am Ende einer Transaktion ein Protokollsatz in eine Tabelle geschrieben wird, kann sich dies ebenfalls erheblich beschleunigen.

Wenn Ihre Datenbank einen relativ niedrigen Prozentsatz an Schreibvorgängen hat, lohnt es sich möglicherweise nicht. Ich hatte ein Lese-Schreib-Verhältnis von unter 2: 1.

Einige URLs ich gespeichert, wenn die Arbeit an diesem:

http://www.developerfusion.com/article/1688/sql-server-locks/4/

Answer 3

Sie sollten nolock verwenden, wenn es in Ordnung ist schmutzig Daten zu lesen. Eine große Transaktion, bei der möglicherweise noch einige Änderungen an der Datenbank vorgenommen werden, wird mit nolock nur die Daten zurückgeben, die sie bisher festgelegt hat. Sollte diese Transaktion dann Rollback der Daten sein, die Sie betrachten, könnte falsch sein. Daher sollten Sie es nur verwenden, wenn es nicht wichtig ist, dass das, was Sie zurückbekommen, falsch ist.

Deadlocks sind ein häufiges Problem, aber 9 von 10 Fällen sind ausschließlich auf ein Entwicklerproblem zurückzuführen. Ich würde mich darauf konzentrieren, die Ursache der Deadlocks zu finden, anstatt Nolock zu verwenden. Es ist mehr als wahrscheinlich, dass nur eine Transaktion die Dinge in einer anderen Reihenfolge ausführt als alle anderen. Wenn Sie nur diesen Fehler beheben, können alle Ihre Probleme verschwinden.

Answer 4

Es gibt vier transaction isolation levels in SQL Server:

1. LESEN UNCOMMITTED
2. READ COMMITTED
3. WIEDERHOLBARE READ
4. SERIALIZABLE

Für die Tabellen es angewendet wird, ist NOLOCK die Äquivalent von "uncommitted lesen". Das bedeutet, dass Sie Zeilen aus Transaktionen sehen können, die in der Zukunft möglicherweise zurückgesetzt werden, und viele andere seltsame Ergebnisse.

Trotzdem arbeitet Nolock in der Praxis sehr gut. Vor allem für schreibgeschützte Abfragen, bei denen das Anzeigen etwas falscher Daten nicht das Ende der Welt darstellt, wie beispielsweise Geschäftsberichte. Ich würde es in der Nähe von Updates oder Beilagen oder generell irgendwo in der Nähe von Entscheidungscodes vermeiden, besonders wenn es um Rechnungen geht.

Als Alternative zu nolock sollten Sie "read committed snapshot" lesen, das für Datenbanken mit hoher Lese- und weniger Schreibaktivität gedacht ist. Sie können es einschalten mit:

ALTER DATABASE YourDb SET READ_COMMITTED_SNAPSHOT ON; 

Es ist für SQL Server 2005 und höher verfügbar. Dies ist, wie Oracle standardmäßig funktioniert, und es ist, was Stackoverflow selbst verwendet. Es gibt sogar einen coding horror Blogeintrag darüber.

P.S. Lange laufende Abfragen und Deadlocks können auch anzeigen, dass SQL Server mit falschen Annahmen arbeitet. Überprüfen Sie, ob Ihre Statistiken oder Indizes veraltet sind:

SELECT 
    object_name = Object_Name(ind.object_id), 
    IndexName = ind.name, 
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) 
FROM SYS.INDEXES ind 
order by STATS_DATE(ind.object_id, ind.index_id) desc 

Die Statistiken sollten in einem wöchentlichen Wartungsplan aktualisiert werden.

Answer 5

Für eine transaktionskonsistente Ansicht ohne Lesesperren wird empfohlen, die Snapshot-Isolation in SQL Server zu aktivieren.

Dies ist ein wenig anders als NOLOCK, da beim Lesen von Informationen die Ergebnisse immer eine Version der festgeschriebenen Daten widerspiegeln und nicht die Möglichkeit, nicht übergebene Daten anzuzeigen. Dies bietet die gleiche Nebenläufigkeit wie NOLOCK (keine "Lese" -Sperren) mit klareren Ergebnissen.

Man sollte immer daran denken, dass die Daten, die Sie dann zum Zeitpunkt der Anzeige anzeigen oder verwenden, auch bei Transaktionskonsistenz möglicherweise falsch oder veraltet sein können. Ich habe zu viele Leute davon ausgehen können, dass, wenn sie die Daten schnell genug verwenden oder wenn sie es innerhalb einer Abfrage/Transaktion verwenden, dass es in Ordnung ist. Das ist absurd - ich bin der Meinung, wiederholbare Konsistenzlevel hätten niemals überhaupt umgesetzt werden dürfen, da es nur schlechtes Verhalten fördert. Sie existieren nicht in Oracle.

Persönlich mag ich Sperrung für bestimmte unkritische Daten Ansichten und Berichte, wie es eine geringere Belastung für das System und die kleine proboabliyy Bereitstellung leicht unreiner Ergebnisse ist kein Problem.

Die Nutzung von wiederholbaren Lesekonsistenzlevels und das Begehen von Sünden wie das Offenhalten von Transaktionen für Benutzereingaben mag dem Entwickler in Bezug auf die anfängliche Entwicklung etwas leichter sein, führt aber fast immer zu großen "Blockaden" vernünftige Skalierung Ihrer Anwendung.

Meine Ansicht ist der beste Ansatz ist immer "doppelt überprüfen" Bedingungen, die immer noch wahr sein müssen, um Updates auf Daten anzuwenden.

Bad:

UPDATE myaccount SET balance = 2000 

Besser:

UPDATE myaccount SET balance = balance + 2000 

Besser noch:

UPDATE myaccount SET balance = 2000 WHERE balance = 0 AND accountstatus = 1 

Schließlich muss die Anwendung Zeilenanzahl überprüfen, um die erwartete Anzahl der Zeilen stellen Sie sicher, tatsächlich aktualisiert wurden bevor dem Benutzer Erfolgsrückmeldungen angezeigt werden.

Answer 6

Verwenden Sie Nolock als letztes Mittel. Die meisten Deadlock-Probleme können behoben werden, indem die Abfragen optimiert und/oder die Indizes optimiert werden. Ich glaube, ich habe in den letzten 5 Jahren eine Pattsituation gesehen, die nicht behoben werden konnte, indem man eine der beiden einstellte.

Beachten Sie auch, dass NOLOCK nur bei ausgewählten Anweisungen berücksichtigt wird. Datenänderungen werden immer gesperrt, dieses Verhalten kann nicht geändert werden. Wenn Sie also einen Writer/Writer-Deadlock haben (ganz normal), wird kein Lock überhaupt helfen.

bewusst sein, auch dass nolock, zusätzlich zu dem schmutzigen Daten Rückkehr in doppelten Zeilen führen kann (Zeilen lesen zweimal aus der zugrundeliegenden Tabelle) und fehlenden Zeilen (Zeilen in der zugrunde liegenden Tabelle, die nicht gelesen wurde).

nolock bedeutet im Wesentlichen auf SQL Server ‚ich nichts dagegen, wenn meine Ergebnisse etwas ungenau sind‘

Snapshot-Isolation ist eine Option. Stellen Sie nur sicher, dass Sie zuerst sorgfältig testen, da die erhöhte Auslastung von TempDB ziemlich hoch sein kann, abhängig davon, wie häufig und wie lange Ihre Transaktionen sind. Beachten Sie auch, dass Sie zwar keine Deadlocks in der Snapshot-Isolation sehen, jedoch Aktualisierungskonflikte auftreten können. Testen Sie erneut und stellen Sie sicher, dass Ihre Apps ordnungsgemäß funktionieren und alle Fehler beheben können.