Laut MSDN:
http://msdn.microsoft.com/en-us/library/ms191242.aspx
Wenn entweder die Datenbankoption READ COMMITTED SNAPSHOT oder ALLOW SNAPSHOT ISOLATION aktiviert ist, werden logische Kopien (Versionen) für alle in der Datenbank durchgeführten Datenänderungen beibehalten. Jedes Mal, wenn eine Zeile durch eine bestimmte Transaktion geändert wird, speichert die Instanz von Datenbankmodul eine Version des zuvor festgeschriebenen Abbilds der Zeile in tempdb. Jede Version ist mit der Transaktionssequenznummer der Transaktion gekennzeichnet, die die Änderung vorgenommen hat. Die Versionen der modifizierten Zeilen werden unter Verwendung einer Linkliste verkettet. Der neueste Zeilenwert wird immer in der aktuellen Datenbank gespeichert und mit den in tempdb gespeicherten versionierten Zeilen verkettet.
Bei Transaktionen mit kurzer Laufzeit kann die Aversion einer geänderten Zeile im Pufferpool zwischengespeichert werden, ohne dass sie in die Datenträgerdateien der tempdb-Datenbank geschrieben wird. Wenn die versionierte Zeile nur von kurzer Dauer benötigt wird, wird sie einfach aus dem Pufferpool gelöscht und verursacht nicht unbedingt E/A-Overhead.
Es scheint eine leichte Leistungseinbuße für den zusätzlichen Overhead zu geben, aber es kann vernachlässigbar sein. Wir sollten testen, um sicherzugehen.
Versuchen Sie, diese Option einzustellen und alle NOLOCKs aus Codeabfragen zu entfernen, es sei denn, es ist wirklich notwendig. NOLOCKs oder die Verwendung globaler Methoden im Datenbank-Kontexthandler zur Bekämpfung von Isolationsstufen für Datenbanktransaktionen sind Pflaster für das Problem. NOLOCKS verschleiert grundlegende Probleme mit unserer Datenschicht und führt möglicherweise zur Auswahl unzuverlässiger Daten, wobei die automatische Auswahl/Aktualisierung der Zeilenversionierung die Lösung zu sein scheint.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON
