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 SQL-99-Standard definiert die folgenden Isolationsstufen, die alle von Microsoft SQL Server-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 physikalisch beschädigten Daten gelesen werden.)
- Read Committed (Commit muss vor Lesevorgang ausgeführt sein. Die Standardstufe von Datenbankmodul.)
- Repeatable Read
- Serializable (Serialisierbar. Die höchste Stufe, auf der Transaktionen vollständig voneinander isoliert werden.)
SQL Server 2005 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. Die Snapshotisolation ist aktiviert, wenn die ALLOW_SNAPSHOT_ISOLATION-Datenbankoption auf ON gesetzt ist. Standardmäßig ist diese Option für Benutzerdatenbanken auf OFF gesetzt.
Die folgende Tabelle veranschaulicht, welche Parallelitätsnebeneffekte in den einzelnen Isolationsstufen zulässig 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).
Siehe auch
Konzepte
Parallelitätseffekte
Parallelitätskontrolltypen