Wie ich sicher wissen, bin, nur weil eine Menge für die Verwendung Menschen NOLOCKist es keine gute Idee machen - nach allem, wenn man weit genug zurückgehen, eine Menge Leute dachte , Sklaverei, Pestizide, Asbest, Bleifarbe und Benzin, etc. waren auch alle tolle Ideen.
NOLOCKhat einen Leistungsvorteil, aber nicht, weil keine Sperren erforderlich sind - es liegt einfach daran, dass der Leser Sperren anderer Leser oder Schreiber ignorieren kann. Eine Abfrage mit NOLOCKkann weiterhin blockiert werden, je nachdem, wer was mit den zugrunde liegenden Tabellen tut - zumindest Sch-Ssind noch Sperren erforderlich.
Aber die Nachteile sind zahlreich und werden normalerweise ignoriert, bis sie eintreten - die Leute sind glücklich darüber, dass ihre Anfragen "schnell" sind - selbst wenn sie falsche oder inkonsistente Daten produzieren, insbesondere wenn sie es nicht bemerken. Mit NOLOCK/ READ UNCOMMITTEDkönnen Sie:
- Lesen Sie dieselbe Zeile zweimal (die Zeile, die Sie gelesen haben, bewegt sich vor dem Scan der Zuordnungsreihenfolge)
- Überspringen Sie eine Zeile insgesamt (Zeile, die Sie noch nicht gelesen haben, wird hinter den Scan verschoben)
- Lesen Sie eine nicht festgeschriebene Zeile, die möglicherweise nie vorhanden ist
- Fehler aufgrund zu großer Bewegung während des Scans erhalten
- Lesen Sie verschiedene Spalten in einer Zeile in verschiedenen Zuständen
Was ist zu tun
Sie können diese Risiken vermeiden. Die Standardisolationsstufe ( READ COMMITTED) ist sicherlich auch nicht ohne Datenkonsistenzrisiken, sondern NOLOCKfügt nur viele hinzu.
Ich sehe, dass "Schnappschuss" ziemlich oft geworfen wird - obwohl sie ähnlich klingen mögen, unterscheidet sich die isolierte Lese-Schnappschuss-Isolation erheblich von der Schnappschuss-Isolation . Kendra Kleine hat eine gründliche Post hier , die es wert ist zu lesen.
Jemand sagte: "Niemand wurde jemals wegen der Verwendung von Snapshot Isolation entlassen." Ich kann mir tatsächlich Szenarien vorstellen, in denen genau das möglich ist. Die Snapshot-Isolation weist eine erheblich unterschiedliche Semantik auf und erfordert die ordnungsgemäße Implementierung von Codeänderungen. Mehr Veränderung = mehr Risiko.
Read Committed Snapshot Isolation kann mit wenig bis gar keiner Codeänderung implementiert werden und ist normalerweise diejenige, die die Leute meinen, wenn sie vorschlagen, dass Sie von NOLOCK/ wechseln READ UNCOMMITTED. Es ist jedoch auch möglich, Verhaltensänderungen einzuführen, indem RCSI einfach auf Datenbankebene aktiviert wird ( ein Beispiel finden Sie in Punkt 3 in Kendras Beitrag ).
Obwohl ich persönlich denke, dass RCSI viel besser ist als NOLOCK, müssen Sie bedenken, dass die Leistung nicht garantiert besser ist. RCSI erstellt Versionen von Zeilen in Tempdb, sodass jede Sitzung bei Bedarf eine eigene Kopie der Zeile hat. Wenn Tempdb ein Engpass auf Ihrem System ist, funktioniert dies möglicherweise nicht so gut. Wenn Sie den aktivierten Lese-Snapshot auf Datenbankebene aktivieren, werden bei allen zukünftigen Datenänderungen 14 Byte pro Zeile hinzugefügt.
Dies bedeutet, dass Sie, um zu zeigen, dass sich der Switch lohnt, tempdb angemessen ausrüsten sollten, um zusätzliches Laden zu unterstützen, wenn es derzeit nicht optimal ist, und dass Sie darauf vorbereitet sein müssen, dass Ihre vorhandenen Tabellen mehr Speicherplatz auf der Festplatte benötigen und letztendlich in Erinnerung. Wenn tempdb bereits gesättigt ist oder Sie sich bereits in der Nähe Ihrer Festplattenkapazität befinden oder der Speicher bereits erschöpft ist, hilft RCSI möglicherweise nicht weiter.
(Es gibt natürlich auch andere Möglichkeiten, die Leistung im Allgemeinen zu verbessern, wenn NOLOCKsich das Risiko nicht lohnt und Sie keinen Overhead für RCSI haben. Die Komprimierung kann beispielsweise eine gute Wahl sein, um die E / A zu reduzieren , wenn Sie dies tun Columnstore-Indizes können für bestimmte Workloads nützlich sein. Und natürlich können granulare Index- und Abfrageoptimierungen von Vorteil sein.)
Für die vorliegende Frage:
Ich würde vorschlagen, dass Sie sich darauf konzentrieren, sicherzustellen, dass Ihre Abfragen korrekte Ergebnisse liefern, ohne dass die Leistung spürbar beeinträchtigt wird - im Vergleich zur Standardisolationsstufe. Ein Vergleich mit NOLOCKist nicht wirklich fair, es sei denn, Sie sind mit allen oben genannten Risiken absolut vertraut. In Kendras Beitrag werden einige Details zur Messung der Auswirkungen behandelt. Grundsätzlich möchten Sie jedoch Vorher-Nachher-Messungen derselben Arbeitslast mit demselben externen Druck und derselben Parallelität durchführen:
- Abfragezeiten für diese Abfragen, die
NOLOCKheute ( sys.dm_exec_query_stats)
- Allgemeine Leistungsmetriken - Wartezeiten, E / A-Latenz, Tempdb-Nutzung, Speichernutzung und sogar Seitenlebensdauer
Und Sie würden dies mit der Methode tun, mit der Sie derzeit die Leistung messen. Wenn Sie keine Methode haben, kann ich vorschlagen, dass sich ein Überwachungstool lohnt, auch wenn es sich nur um einen Test handelt. (Haftungsausschluss: Ich habe früher für einen gearbeitet .)
Es gibt keine magische "Sagen Sie mir, ob meine Arbeitsbelastung mit RCSI besser ist als ohne" - dies hängt davon ab, welche Aspekte der Leistung für Sie wichtig sind, die bereits kurz vor Engpässen stehen und welche sich in Ihrem speziellen Fall zeigen - ein Gesamtgewinn oder -verlust (wiederum unter der Annahme, dass alles andere gleich bleibt).
Und es kann sein, dass Sie sie mit qualitativen Argumenten überzeugen können, anstatt (oder zusätzlich zu) nur "Metriken".
Weiterführende Literatur (einige Links von oben wiederholt):
NOLOCK.