Freigeben über

  • Artikel

Isolationsstufen im Datenbankmodul

Transaktionen geben eine Isolationsstufe an, mit der definiert wird, bis zu welchem Ausmaß eine Transaktion von Ressourcen- oder Datenänderungen isoliert sein muss, die von anderen Transaktionen durchgeführt werden. Die einzelnen Isolationsstufen werden dahingehend beschrieben, welche Parallelitätsnebeneffekte (wie z. B. Dirty Reads oder Phantomlesezugriffe) zulässig sind.

Durch die Transaktionsisolationsstufen wird Folgendes gesteuert:

  • Ob beim Lesen von Daten Sperren aktiviert werden können, und welcher Sperrentyp angefordert wird.

  • Wie lange die Lesesperren aufrechterhalten werden.

  • Ob ein Lesevorgang, der auf Zeilen verweist, die durch eine andere Transaktion geändert wurden:

    • Blockiert wird, bis die exklusive Sperre für die Zeile aufgehoben wird.

    • Die durch einen Commit bestätigte Version der Zeile abruft, die zum Zeitpunkt des Anweisungs- oder Transaktionsstarts vorhanden war.

    • Die Datenänderung liest, für die noch kein Commit ausgeführt wurde.

Das Auswählen einer Transaktionsisolationsstufe hat keine Auswirkungen auf die Sperren, die zum Schutz der Datenänderung eingerichtet werden. Eine Transaktion erhält immer eine exklusive Sperre für alle von ihr geänderten Daten und hält diese Sperre bis zum Abschluss der Transaktion aufrecht, und zwar unabhängig davon, welche Isolationsstufe für diese Transaktion festgelegt wurde. Für Lesevorgänge wird durch die Transaktionsisolationsstufen in erster Linie der Grad des Schutzes vor den Auswirkungen der Änderungen definiert, die durch andere Transaktionen vorgenommen werden.

Eine niedrigere Isolationsstufe erhöht einerseits die Möglichkeit, dass viele Benutzer gleichzeitig auf Daten zugreifen können, führt aber gleichzeitig zum Anstieg der negativen Parallelitätseffekte (Dirty Reads oder verlorene Aktualisierungen), mit denen die Benutzer rechnen müssten. Und umgekehrt schränkt eine höhere Isolationsstufe zwar die Typen der Parallelitätseffekte ein, mit denen Benutzer rechnen müssen, gleichzeitig werden dafür aber mehr Systemressourcen beansprucht, und die Wahrscheinlichkeit steigt, dass sich die Transaktionen untereinander blockieren. So muss bei jeder Auswahl der geeigneten Isolationsstufe eine Abwägung zwischen den Datenintegritätsanforderungen der Anwendungen einerseits und dem mit jeder Isolationsstufe verbundenen Aufwand andererseits erfolgen. Die höchste Isolationsstufe (Serializable) garantiert, dass eine Transaktion jedes Mal, wenn sie einen Lesevorgang wiederholt, genau dieselben Daten liest. Dies wird jedoch durch ein Ausmaß an Sperren erreicht, das in Systemen mit mehreren Benutzern wahrscheinlich zu negativen Auswirkungen für andere Benutzer führt. Mit der niedrigsten Isolationsstufe (Read Uncommitted) können Daten abgerufen werden, die von anderen Transaktionen geändert wurden, für die jedoch noch kein Commit ausgeführt wurde. In der Isolationsstufe Read Uncommitted können sämtliche denkbaren Parallelitätsnebeneffekte auftreten, dagegen werden keine Lesesperren und keine Versionsverwaltung verwendet, wodurch der Aufwand minimiert wird.

Isolationsstufen des Datenbankmoduls

Der ISO-Standard definiert die folgenden Isolationsstufen, die alle von SQL Server Database Engine (Datenbankmodul) unterstützt werden:

  • Read Uncommitted (Commit muss vor Lesevorgang nicht ausgeführt sein. Die unterste Stufe, bei der Transaktionen nur soweit isoliert werden, dass sichergestellt ist, dass keine physisch beschädigten Daten gelesen werden.)

  • Read Committed (Commit muss vor Lesevorgang ausgeführt sein. Die Standardstufe von Database Engine (Datenbankmodul).)

  • Repeatable Read

  • Serializable (Serialisierbar. Die höchste Stufe, auf der Transaktionen vollständig voneinander isoliert werden.)

Wichtiger HinweisWichtig

DDL-Vorgänge und -Transaktionen in replizierten Tabellen schlagen möglicherweise fehl, wenn die serialisierbare Isolationsstufe angefordert wird. Das liegt daran, dass Replikationsabfragen Hinweise verwenden, die möglicherweise mit der serialisierbaren Isolationsstufe nicht kompatibel sind.

SQL Server unterstützt außerdem zwei Transaktionsisolationsstufen, bei denen die Zeilenversionsverwaltung unterstützt wird. Eine davon ist eine neue Implementierung der Read Committed-Isolation, die andere – Snapshot – ist eine völlig neue Transaktionsisolationsstufe.

  • Wenn die READ_COMMITTED_SNAPSHOT-Datenbankoption auf ON festgelegt ist, verwendet die READ COMMITTED-Isolation die Zeilenversionsverwaltung, um eine Lesekonsistenz auf der Anweisungsebene zu gewährleisten. Lesevorgänge erfordern dabei lediglich SCH-S-Sperren auf der Tabellenebene und keine Seiten- oder Zeilensperren. Wenn die READ_COMMITTED_SNAPSHOT-Datenbankoption auf OFF festgelegt ist, was der Standardeinstellung entspricht, verhält sich die READ COMMITTED-Isolation wie in früheren Versionen von SQL Server. Beide Implementierungen entsprechen der ANSI-Definition der Read Committed-Isolation.

  • Die Snapshotisolationsstufe verwendet die Zeilenversionsverwaltung, um die Lesekonsistenz auf der Transaktionsebene zu gewährleisten. Dabei werden durch Lesevorgänge keine Seiten- oder Zeilensperren eingerichtet, sondern lediglich SCH-S-Tabellensperren. Beim Lesen von Zeilen, die durch einen andere Transaktion geändert wurden, wird die Version der Zeile abgerufen, die zum Startzeitpunkt der Transaktion vorhanden war. Sie können nur die Snapshotisolation für eine Datenbank verwenden, wenn die ALLOW_SNAPSHOT_ISOLATION-Datenbankoption auf ON festgelegt wurde. Standardmäßig ist diese Option für Benutzerdatenbanken auf OFF gesetzt.

HinweisHinweis

SQL Server unterstützt keine Versionsverwaltung von Metadaten. Aus diesem Grund gibt es bezüglich der DDL-Vorgänge, die in einer unter Snapshotisolation ausgeführten expliziten Transaktion ausgeführt werden, Einschränkungen. Die folgenden DDL-Anweisungen sind nach einer BEGIN TRANSACTION-Anweisung unter Snapshotisolation nicht zulässig: ALTER TABLE, CREATE INDEX, CREATE XML INDEX, ALTER INDEX, DROP INDEX, DBCC REINDEX, ALTER PARTITION FUNCTION, ALTER PARTITION SCHEME sowie alle CLR (Common Language Runtime)-DDL-Anweisungen. Diese Anweisungen sind zulässig, wenn die Snapshotisolation in impliziten Transaktionen verwendet wird. Eine implizite Transaktion ist definitionsgemäß eine einzelne Anweisung, mit der die Semantik der Snapshotisolation auch in DDL-Anweisungen erzwungen werden kann. Durch eine Verletzung dieses Prinzips kann Fehler 3961 verursacht werden: "Fehler bei der Snapshotisolationstransaktion in der '%.*ls'-Datenbank, weil das von der Anweisung zugegriffene Objekt durch eine DDL-Anweisung in einer anderen gleichzeitigen Transaktion seit dem Beginn dieser Transaktion geändert wurde. Dies ist nicht zulässig, weil die Metadaten nicht versionsspezifisch sind. Die gleichzeitige Aktualisierung von Metadaten kann in Kombination mit der Snapshotisolation zu Inkonsistenzen führen."

Die folgende Tabelle veranschaulicht, welche Parallelitätsnebeneffekte in den einzelnen Isolationsstufen möglich sind.

Isolationsstufe

Dirty Read

Nicht wiederholbarer Lesevorgang

Phantom

Read Uncommitted

Ja

Ja

Ja

Read Committed

Nein

Ja

Ja

Repeatable Read

Nein

Nein

Ja

Snapshot

Nein

Nein

Nein

Serializable

Nein

Nein

Nein

Weitere Informationen zu den speziellen Sperrentypen sowie über die Unterstützung der Zeilenversionsverwaltung durch die einzelnen Transaktionsisolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).