Auswählen von auf Zeilenversionsverwaltung basierenden Isolationsstufen

Einsatzbedingungen für die Read Committed-Isolation mit Zeilenversionsverwaltung

Die Read Committed-Isolation mithilfe der Zeilenversionsverwaltung gewährleistet die Lesekonsistenz auf Anweisungsebene. Beim Ausführen jeder einzelnen Anweisung innerhalb der Transaktion wird ein neuer Datensnapshot erstellt und bleibt für jede Anweisung konsistent, bis die Ausführung der Anweisung abgeschlossen ist. Aktivieren Sie die Read Committed-Isolation mit Zeilenversionsverwaltung in den folgenden Situationen:

• Leser-/Schreiberblockierungen treten so stark auf, dass die Parallelitätsvorteile den zusätzlichen Aufwand aufwiegen, der mit dem Erstellen und Verwalten von Zeilenversionen verbunden ist.

• Eine Anwendung setzt absolute Genauigkeit für lang andauernde Aggregationen oder Abfragen voraus, bei denen die Datenwerte gegenüber dem Zeitpunkt des Abfragestarts konsistent sein müssen.

Einsatzbedingungen für die Snapshotisolation

Die Snapshotisolation gewährleistet die Lesekonsistenz auf Transaktionsebene. Ein Datensnapshot wird beim Start der Snapshottransaktion erstellt und bleibt für die Dauer der Transaktion konsistent. Verwenden Sie die Snapshotisolation in den folgenden Situationen:

• Die Steuerung durch vollständige Parallelität ist erwünscht.

• Die Wahrscheinlichkeit ist gering, dass für eine Transaktion aufgrund eines Aktualisierungskonfliktes ein Rollback ausgeführt werden muss.

• Eine Anwendung muss Berichte generieren, die auf lang andauernden Abfragen mit vielen Anweisungen basieren, bei denen die Konsistenz zu einem bestimmten Zeitpunkt gewährleistet sein muss. Die Snapshotisolation bietet den Vorteil wiederholbarer Lesevorgänge (siehe Parallelitätseffekte), ohne dass dazu freigegebene Sperren verwendet werden. Ein Datenbanksnapshot kann zwar dieselbe Funktionalität bieten, muss jedoch manuell implementiert werden. Die Snapshotisolation stellt automatisch die neuesten Informationen in der Datenbank für jede Transaktion mit Snapshotisolation bereit.

Vorteile der auf Zeilenversionsverwaltung basierenden Isolationsstufen

Die Isolationsstufen, die auf der Zeilenversionsverwaltung basieren, haben die folgenden Vorteile:

• Lesevorgänge rufen einen konsistenten Snapshot der Datenbank ab.

• SELECT-Anweisungen führen nicht zum Sperren von Daten während eines Lesevorgangs (Leser blockieren keine Schreiber, und umgekehrt).

• SELECT-Anweisungen können auf den Wert der Zeile zugreifen, für den zuletzt ein Commit ausgeführt wurde, während andere Transaktionen die Zeile aktualisieren können, ohne dabei blockiert zu werden.

• Die Anzahl von Deadlocks wird verringert.

• Die Anzahl der für eine Transaktion benötigten Sperren wird verringert, was den Systemaufwand zum Verwalten der Sperren senkt.

• Es finden weniger Sperrenausweitungen statt.

Mögliche Nachteile der auf Zeilenversionsverwaltung basierenden Isolationsstufen

Wenn es darum geht, ob die auf Zeilenversionsverwaltung basierende Isolation verwendet werden soll, muss abgewogen werden zwischen dem Parallelitätsvorteil infolge der Minimierung von Sperren und der erhöhten Ressourcenverwendung, die mit dem Verwalten und Lesen von Zeilenversionen verbunden ist. Berücksichtigen Sie die folgenden Nachteile, die möglicherweise mit der Aktivierung der Zeilenversionsverwaltung für die Snapshot- und Read Committed-Isolationsstufen verbunden sind:

• Die Leseleistung kann beeinträchtigt werden, wenn die von Abfragen benötigten Versionen veralten, und lange Versionsketten müssen gelesen werden.

• Die Zeilenversionsverwaltung erhöht die Ressourcenverwendung während der Datenänderung, weil die Zeilenversionen in tempdb gespeichert werden.

• Wenn entweder die Datenbankoption READ_COMMITTED_SNAPSHOT oder die Datenbankoption ALLOW_SNAPSHOT_ISOLATION auf ON gesetzt ist, müssen Aktualisierungs- und Löschtransaktionen für eine bestimmte Datenbank die Zeilenversionen selbst dann verwalten, wenn es keine Transaktionen gibt, die eine auf der Zeilenversionsverwaltung basierende Isolationsstufe verwenden. Das Erstellen eines konsistenten Datensnapshots mithilfe von Zeilenversionen bindet Systemressourcen (CPU und Arbeitsspeicher) und verursacht potenziell E/A-Aktivität. Weil die Versionsdatensätze in tempdb gespeichert werden, ist die Leistung besser und die Anzahl der erzeugten E/As geringer, wenn mehr tempdb-Seiten für die Zeilenversionsverwaltung im Arbeitsspeicher gespeichert werden können.

  Hinweis

  Das Einfügen einer Zeile führt im Allgemeinen nicht zum Generieren einer Zeilenversion. Unter bestimmten Bedingungen wird durch den INSERT-Befehl jedoch eine Zeilenversion generiert. Wenn Sie z. B. eine Zeile in eine Tabelle mit einem eindeutigen Index einfügen, und eine zuvor gelöschte Zeilenversion (inaktiver Datensatz) wurde noch nicht abgeschnitten, führt der INSERT-Befehl zum Generieren einer Zeilenversion.

• tempdb muss über ausreichend Datenträgerspeicherplatz verfügen, um die Versionen speichern zu können. Wenn es sehr lang andauernde Transaktionen gibt, müssen sämtliche Versionen, die während dieser Zeit durch Aktualisierungstransaktionen generiert werden, in tempdb gespeichert werden. Wenn tempdb nicht mehr genügend Speicherplatz zur Verfügung steht, erzeugen zwar die Aktualisierungsvorgänge keinen Fehler, Lesevorgänge mithilfe der Zeilenversionsverwaltung können dadurch jedoch zu einem Fehler führen.

• Für die Informationen zur Zeilenversionsverwaltung müssen jeder betroffenen Datenbankzeile 14 Byte hinzugefügt werden.

• Die Aktualisierungsleistung kann durch den mit der Verwaltung der Zeilenversionen verbundenen Aufwand eingeschränkt werden. Bei typischen OLTP-Arbeitslasten ändert jede Aktualisierung nur wenige Zeilen in einer Datenbank. Bei solchen Systemen kann die Aktualisierungsleistung in einer Datenbank mit der Optionseinstellung ON nur um wenige Prozentpunkte unter der Aktualisierungsleistung in Datenbanken liegen, bei denen beide Optionen auf OFF gesetzt sind. Die Leistungseinbußen von versionsbasierten Aktualisierungen können größer sein, wenn bei Aktualisierungsvorgängen größere Mengen an Daten geändert werden.

• Datenlesevorgänge werden durch das Durchlaufen der Versionsverknüpfungsliste beeinträchtigt. Je älter der Snapshot ist, desto länger dauert es, in einer Transaktion mit Snapshotisolation auf diesen Snapshot zuzugreifen.

• Für einige Aktualisierungstransaktionen mit Snapshotisolation muss evtl. ein Rollback ausgeführt werden, weil die Konflikterkennung bei Aktualisierungsvorgängen obligatorisch ist. Bei Transaktionen, die mit Read Committed-Isolation mithilfe der Zeilenversionsverwaltung ausgeführt werden, werden keine Aktualisierungskonflikte generiert.

Transaktionen mit Zeilenversionsverwaltung weisen jedoch andere Einschränkungen auf. Weitere Informationen finden Sie unter Verwenden von auf Zeilenversionsverwaltung basierenden Isolationsstufen.

Systeme, die von auf Zeilenversionsverwaltung basierenden Isolationsstufen profitieren

Die folgenden Szenarien profitieren von auf Zeilenversionsverwaltung basierenden Isolationsstufen:

• Systeme, in denen schreibgeschützte Berichte und Ad-hoc-Abfragen parallel zu einer Anwendung ausgeführt werden, welche die Daten aktualisiert.

• Anwendungsmigrationen zu Microsoft SQL Server Database Engine (Datenbankmodul) aus anderen relationalen Datenbanksystemen, die gleiche Isolationsstufen unterstützen.

• Systeme, bei denen das Erstellen konsistenter Aggregate (wie z. B. AVG, COUNT und SUM) oder das Erstellen von Indexschnittmengen und Indexverknüpfungen eine strikte Isolationsstufe (wie Repeatable Read oder Serializable) erfordert.

• Systeme, bei denen infolge von Lese-/Schreibkonflikten eine hohe Anzahl von Deadlocks auftritt.

Siehe auch

Verweis

Konzepte