Auswählen von auf Zeilenversionsverwaltung basierenden Isolationsstufen

Auf Zeilenversionsverwaltung basierende Isolationsstufen verbessern die Leistung bei gleichzeitigen Lesevorgängen, indem Sperren für Lesevorgänge vermieden werden. Mit MicrosoftSQL Server werden zwei Transaktionsisolationsstufen eingeführt, die auf der Zeilenversionsverwaltung basieren:

  • Eine neue Implementierung der Read Committed-Isolationsstufe, bei der die Zeilenversionsverwaltung verwendet wird, wenn die READ_COMMITTED_SNAPSHOT-Datenbankoption auf ON gesetzt ist.

  • Eine neue Isolationsstufe: Snapshot. Diese wird aktiviert, wenn die ALLOW_SNAPSHOT_ISOLATION-Datenbankoption auf ON gesetzt ist.

Für die meisten Anwendungen wird empfohlen, die Read Committed-Isolation mithilfe der Zeilenversionsverwaltung zu verwenden und nicht die Snapshotisolation, und zwar aus folgenden Gründen:

  • Sie beansprucht weniger tempdb-Speicherplatz als die Snapshotisolation.

  • Sie kann bei verteilten Transaktionen eingesetzt werden, was bei der Snapshotisolation nicht der Fall ist.

  • Sie kann bei den meisten vorhandenen Anwendungen eingesetzt werden, ohne dass dazu irgendwelche Veränderungen erforderlich sind. Anwendungen, die mithilfe der Standardisolationsstufe Read Committed geschrieben wurden, können dynamisch optimiert werden. Das Verhalten von Read Committed – ob mit oder ohne Verwendung der Zeilenversionsverwaltung – wird durch die Einstellung der Datenbankoption bestimmt, und diese kann ohne Auswirkungen auf die Anwendung geändert werden.

    Hinweis Hinweis

    Anwendungen, die vom Blockierungsverhalten der Read Committed-Isolation abhängen sollen, können durch die Anwender so geändert werden, dass sie mit beiden Modi der Read Committed-Isolation funktionieren. Ansonsten muss unbedingt darauf geachtet werden, dass die READ_COMMITTED_SNAPSHOT-Datenbankoption in der Einstellung OFF bleibt.

  • Die Snapshotisolation ist anfällig für Aktualisierungskonflikte, die bei der Read Committed-Isolation mithilfe der Zeilenversionsverwaltung nicht auftreten. Wenn eine Transaktion, die unter der Snapshotisolationsstufe läuft, Daten liest, die anschließend durch eine andere Transaktion geändert werden, führt die von der Snapshottransaktion veranlasste Aktualisierung dieser Daten zu einem Aktualisierungskonflikt, sodass die Transaktion abgebrochen und ein Rollback für sie ausgeführt wird. Dieses Problem besteht bei der Read Committed-Isolation mit Zeilenversionsverwaltung nicht.

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.

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.

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.

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 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.

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 MicrosoftSQL 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.

Community-Beiträge

HINZUFÜGEN
Anzeigen: