Ist Nolock immer schlecht?

Question

Ich bin ein Berichtsentwickler, der meine Fragen so effizient wie möglich machen möchte. Ich habe früher mit einem DBA gearbeitet, der es mir sagte - ich glaube, weil ich mich immer mit Berichten über einen Produktionsserver zu beschäftigen habe - um sie zu verwenden NOLOCK In jeder einzelnen Abfrage.

Jetzt arbeite ich mit einem DBA zusammen, der verboten ist NOLOCK Unter keinen Umständen - selbst wenn ein Bericht über meinen (aufgrund eines beträchtlichen Mangels an Indizes für ein paar Tabellen) die Replikation und die Systemaktualisierungen stoppt. Meiner Meinung nach in diesem Fall a NOLOCK Wäre eine gute Sache.

Da der größte Teil meines SQL -Trainings verschiedene DBAs mit sehr unterschiedlichen Meinungen gekommen ist, wollte ich dies zu einer Vielzahl von DBAs fragen.

Answer 1

Wenn Ihre Berichtsblöcke aktualisieren, dass Ihr DBA richtig ist: Sie sollten absolut nicht verwenden NOLOCK. Die Tatsache, dass dort sind Konflikte sind ein klarer Hinweis darauf, dass wenn Sie möchten Verwenden Sie schmutzige Lesevorgänge, Sie würden falsche Berichte erhalten.

Meiner Meinung nach gibt es immer bessere Alternativen als NOLOCK:

• Lesen Ihre Produktionstabellen nur in Kraft und werden nie geändert? Markieren Sie nur die Datenbank, die nur gelesen wird!
• Tischscans verursachen Sperrkonflikte? Zeugen Sie die Tabellen angemessen, die Vorteile sind vielfältig.
• Sie können nicht ändern/nicht wissen, wie man angemessen indexiert? Verwenden Snapshot -Isolation.
• Sie können die App nicht ändern, um Snapshot zu verwenden? Einschalten Lesen Sie engagierte Snapshot!
• Sie haben die Auswirkungen der Reihenversionierung gemessen und haben Beweise dafür, dass sie die Leistung beeinflusst? Sie können die Daten nicht indexieren? Und du bist mit in Ordnung mit falsche Berichte? Dann tun Sie sich zumindest einen Gefallen und verwenden Sie es SET TRANSACTION ISOLATION LEVEL, kein Abfrage -Hinweis. Es ist einfacher, die Isolationsstufe später zu beheben, anstatt jede Abfrage zu ändern.

Answer 2

Es ist nicht stets Schlecht.

Natürlich können Sie nicht übereinstimmende Werte lesen (die möglicherweise zurückgerollt werden und daher nie logisch existiert) sowie Phänomene wie das Lesen von Werten mehrmals oder gar nicht zuzulassen.

Die einzigen Isolationsstufen, die garantieren, dass Sie keine solchen Anomalien begegnen, sind serialisierbar/schnappshot. Unter wiederholbaren Lesewerten können Werte übersehen werden, wenn eine Zeile verschoben wird (aufgrund eines Schlüsselaktualisierung), bevor der Scan diese Zeile erreicht, können unter read festgelegten Werten zweimal gelesen werden, wenn ein Schlüsselaktualisierung dazu führt, dass eine zuvor gelesene Zeile voranschreitet.

Diese Probleme treten eher unter auf nolock Aber weil es standardmäßig auf dieser Isolationsebene verwendet wird Eine zuordnungsgeordnete Scan, wenn es schätzt, dass mehr als 64 Seiten gelesen werden müssen. Neben der Kategorie von Problemen, die auftreten, wenn sich Zeilen zwischen den Seiten wechseln, aufgrund von Indexschlüssel -Aktualisierungen Diese geordneten Scans sind auch anfällig für Probleme mit Seitenaufspaltungen (wobei Zeilen übersehen werden können, wenn die neu zugewiesene Seite früher in der Datei ist als der Punkt Bereits gescannt oder zweimal gelesen, wenn eine bereits gescannte Seite auf eine spätere Seite in der Datei aufgeteilt ist).

Zumindest für einfache (einzelne Tabellen) Abfragen ist es möglich, die Verwendung dieser Scans zu entmutigen und einen wichtigen SCAN AN zu erhalten nolock durch einfaches Hinzufügen einer ORDER BY index_key an die Abfrage, damit die Ordered Eigentum des IndexScan ist true.

Wenn Ihre Berichterstattungsanwendung jedoch keine absolut genauen Zahlen benötigt und die größere Wahrscheinlichkeit solcher Inkonsistenzen tolerieren kann, kann dies akzeptabel sein.

Aber sicherlich sollten Sie es nicht auf alle Abfragen in der Hoffnung werfen, dass dies ein magischer "Turbo" -Button ist. Neben der größeren Wahrscheinlichkeit, anomale Ergebnisse in diesem Isolationsebene oder gar keine Ergebnisse zu begegnen ("konnte mit NOLOCK aufgrund von Datenbewegungen nicht fortgesetzt werden", gibt es sogar Fälle, in denen die Leistung mit nolock Kann viel schlimmer sein.

Answer 3

Tolerieren Ihre Kunden inkonsistente Ergebnisse in Berichten? Wenn die Antwort Nein lautet, sollten Sie Nolock nicht verwenden - Sie können falsche Ergebnisse unter Parallelität erzielen. Ich habe ein paar Beispiele geschrieben hier, hier, und hier. Diese Beispiele zeigen eine inkonsistente Ausgabe unter read engagierter und wiederholbares Lesen, aber Sie können sie optimieren und auch mit Nolock falsche Ergebnisse erzielen.

Answer 4

Die meisten Berichte, die ich erstelle, werden nicht auf aktuellen Daten ausgeführt. Die meisten Kunden führen Berichte aus, die die gestrigen Daten sind. Würde sich Ihre Antwort ändern, wenn dies der Fall wäre?

Wenn dies der Fall ist, haben Sie eine weitere mögliche Option:
Anstatt Ihre Abfragen in der Produktionsdatenbank auszuführen und mit Schlössern herumzuspielen und NOLOCK, Sie können Ihre Berichte aus einer Kopie der Produktionsdatenbank ausführen.

Sie können es so einrichten Es wird automatisch von einem Backup pro Nacht wiederhergestellt.
Anscheinend werden Ihre Berichte auf Servern auf den Websites des Kunden ausgeführt, daher weiß ich nicht, ob das Einrichten eine praktikable Lösung für Sie ist.
(Aber andererseits sollten sie sowieso Backups haben. Alles, was Sie brauchen, ist ein Serverraum, um sie wiederherzustellen)

Ich bin ein interner Entwickler, also ist das für mich einfacher, da ich die volle Kontrolle über die Server und Datenbanken habe.

Sie können dies zumindest für die Berichte tun, die nur Daten von gestern und älter benötigen. Vielleicht müssen einige Berichte in der Produktionsdatenbank bleiben, aber zumindest verschieben Sie einen Teil der Last in eine andere Datenbank (oder noch besser, einen anderen Server).

Ich habe auch die gleiche Situation bei der Arbeit:
Wir verwenden eine Produktionsdatenbankkopie wie diese für fast alle Berichterstattung, aber es gibt einige Abfragen, die die heutigen Daten erfordern.