Was bedeutet "with (nolock)" in SQL Server?

Question

Kann jemand erklären, welche Auswirkungen die Verwendung von with (nolock) bei Abfragen, wann sollte man sie verwenden und wann nicht?

Wenn Sie z. B. eine Bankanwendung mit hohen Transaktionsraten und vielen Daten in bestimmten Tabellen haben, für welche Arten von Abfragen wäre nolock dann in Ordnung? Gibt es Fälle, in denen man es immer/keinesfalls verwenden sollte?

Answer 1

WITH (NOLOCK) ist das Äquivalent zur Verwendung von READ UNCOMMITED als Transaktionsisolationsebene. Es besteht also die Gefahr, dass Sie eine nicht bestätigte Zeile lesen, die anschließend zurückgesetzt wird, d. h. Daten, die nie in die Datenbank gelangt sind. Dies kann zwar verhindern, dass Lesevorgänge durch andere Operationen blockiert werden, birgt aber auch ein Risiko. In einer Bankanwendung mit hohen Transaktionsraten ist dies wahrscheinlich nicht die richtige Lösung für das Problem, das Sie damit lösen wollen.

Answer 2

Die Frage ist, was schlimmer ist:

• eine Pattsituation, oder
• einen falschen Wert?

Für Finanzdatenbanken sind Deadlocks viel schlimmer als falsche Werte. Ich weiß, das klingt rückwärtsgewandt, aber lassen Sie mich ausreden. Das traditionelle Beispiel für DB-Transaktionen besteht darin, dass Sie zwei Zeilen aktualisieren, indem Sie von einer Zeile subtrahieren und zur anderen addieren. Das ist falsch.

In einer Finanzdatenbank verwenden Sie Geschäftsvorfälle. Das bedeutet, dass zu jedem Konto eine Zeile hinzugefügt wird. Es ist von größter Bedeutung, dass diese Transaktionen abgeschlossen und die Zeilen erfolgreich geschrieben werden.

Wenn der Kontostand vorübergehend falsch ist, ist das nicht weiter schlimm, denn dafür ist der Abgleich am Ende des Tages gedacht. Und eine Überziehung eines Kontos ist weitaus wahrscheinlicher, weil zwei Geldautomaten gleichzeitig benutzt werden, als dass es zu einem unbestimmten Lesevorgang aus einer Datenbank kommt.

Allerdings wurden mit SQL Server 2005 die meisten Fehler behoben, die die NOLOCK notwendig. Wenn Sie also nicht mit SQL Server 2000 oder früher arbeiten, sollten Sie es nicht brauchen.

Weitere Lektüre
Versionierung auf Zeilenebene

Answer 3

Leider geht es dabei nicht nur um das Lesen von unbestätigten Daten. Im Hintergrund kann es vorkommen, dass Sie Seiten doppelt lesen (im Falle einer Seitenteilung) oder dass Sie die Seiten ganz übersehen. Ihre Ergebnisse können also stark verzerrt sein.

Überprüfen Sie Der Artikel von Itzik Ben-Gan . Hier ist ein Auszug:

" Mit dem NOLOCK-Hinweis (oder der Einstellung der Isolationsebene der Sitzung auf READ UNCOMMITTED) sagen Sie SQL Server, dass Sie keine Konsistenz erwarten, also gibt es keine Garantien gibt. Beachten Sie jedoch dass "inkonsistente Daten" nicht nur nicht nur bedeutet, dass Sie möglicherweise unbestätigte Änderungen, die später zurückgenommen wurden, oder Datenänderungen in einem Zwischen Zustand der Transaktion. Außerdem bedeutet, dass in einer einfachen Abfrage, die alle Tabellen-/Indexdaten durchsucht, SQL Server die Suchposition verlieren kann, oder Sie am Ende die gleiche Zeile erhalten zweimal . "

Answer 4

Das Paradebeispiel für die rechtmäßige Verwendung des nolock-Hinweises ist die Berichtsabfrage gegen eine OLTP-Datenbank mit hohem Aktualisierungsgrad.

Um ein aktuelles Beispiel zu nennen. Wenn eine große US-amerikanische Großbank einen stündlichen Bericht erstellen wollte, um nach den ersten Anzeichen eines Überfalls auf die Bank auf Stadtebene zu suchen, könnte eine Nolock-Abfrage die Transaktionstabellen scannen und die Bareinzahlungen und Barabhebungen pro Stadt summieren. Bei einem solchen Bericht würde der winzige Prozentsatz an Fehlern, der durch zurückgenommene Aktualisierungstransaktionen verursacht wird, den Wert des Berichts nicht mindern.

Answer 5

Ich bin mir nicht sicher, warum Sie Finanztransaktionen nicht in Datenbanktransaktionen verpacken (wenn Sie Geld von einem Konto auf ein anderes überweisen, geben Sie nicht jeweils nur eine Seite der Transaktion frei - deshalb gibt es ja explizite Transaktionen). Selbst wenn Ihr Code keine Ahnung von Geschäftstransaktionen hat, wie es sich anhört, haben alle transaktionalen Datenbanken die Möglichkeit, im Falle von Fehlern oder Ausfällen implizite Rollbacks durchzuführen. Ich glaube, diese Diskussion geht weit über Ihren Horizont hinaus.

Wenn Sie Probleme mit dem Sperren haben, sollten Sie eine Versionsverwaltung einführen und Ihren Code bereinigen.

Keine Sperre liefert nicht nur falsche Werte, sondern auch Phantomsätze und Duplikate.

Es ist ein weit verbreiteter Irrglaube, dass Abfragen dadurch immer schneller laufen. Wenn es keine Schreibsperren auf einer Tabelle gibt, macht es keinen Unterschied. Wenn es Sperren auf der Tabelle gibt, kann es die Abfrage schneller machen, aber es gibt einen Grund, warum Sperren überhaupt erst erfunden wurden.

Der Fairness halber seien hier zwei spezielle Szenarien genannt, in denen ein nolock-Hinweis von Nutzen sein kann

1) Sql-Server-Datenbank aus der Zeit vor 2005, die eine lange Abfrage gegen eine Live-OLTP-Datenbank ausführen muss - dies ist möglicherweise die einzige Möglichkeit

2) Schlecht geschriebene Anwendung, die Datensätze sperrt und die Kontrolle an die Benutzeroberfläche zurückgibt, und Leser werden auf unbestimmte Zeit blockiert. Nolock kann hier hilfreich sein, wenn die Anwendung nicht repariert werden kann (Drittanbieter usw.) und die Datenbank entweder vor 2005 ist oder die Versionierung nicht aktiviert werden kann.