DB2 10.5 for Linux, UNIX and Windows

Isolationsstufen

Die Isolationsstufe (engl. isolation level), die einem Anwendungsprozess zugeordnet wird, bestimmt den Grad, bis zu dem die Daten, auf die von diesem Prozess zugegriffen wird, gesperrt bzw. von anderen gleichzeitig aktiven Prozessen isoliert werden. Die Isolationsstufe ist für die Dauer einer UOW (Unit of Work) wirksam.

Die Isolationsstufe eines Anwendungsprozesses gibt daher folgende Größen an:

Den Grad, bis zu dem Zeilen, die von der Anwendung gelesen oder aktualisiert werden, für andere gleichzeitig ausgeführte Anwendungsprozesse verfügbar sind
Den Grad, bis zu dem die Aktualisierungsaktivitäten anderer gleichzeitig ausgeführter Anwendungsprozesse Auswirkungen auf die Anwendung haben können

Die Isolationsstufe für statische SQL-Anweisungen wird als Attribut eines Pakets angegeben und gilt für die Anwendungsprozesse, die das betreffende Paket verwenden. Die Isolationsstufe wird während des Prozesses der Programmvorbereitung mithilfe der Binde- oder Vorkompilierungsoption ISOLATION angegeben. Für dynamische SQL-Anweisungen ist die Standardisolationsstufe die Isolationsstufe, die für das Paket, das die Anweisung vorbereit, angegeben wurde. Mithilfe der Anweisung SET CURRENT ISOLATION können Sie eine andere Isolationsstufe für dynamische SQL-Anweisungen angeben, die innerhalb derselben Sitzung abgesetzt werden. Weitere Informationen finden Sie in der Beschreibung zum "Sonderregister CURRENT ISOLATION". Sowohl bei statischen als auch bei dynamischen SQL-Anweisungen überschreibt die ISOLATION-Klausel in einer SELECT-Anweisung den Wert des Sonderregisters (falls definiert) und den Wert der Bindeoption. Weitere Informationen finden Sie in der Beschreibung zur "Anweisung SELECT".

Isolationsstufen werden durch Sperren umgesetzt. Der Typ der verwendeten Sperre schränkt den Zugriff auf die Daten durch gleichzeitig aktive Anwendungsprozesse ein oder unterbindet ihn völlig. Deklarierte temporäre Tabellen und ihre Zeilen können nicht gesperrt werden, weil sie nur für die Anwendung zugänglich sind, von der sie deklariert wurden.

Der Datenbankmanager unterstützt drei allgemeine Kategorien von Sperren:

Share (S): Unter einer S-Sperre werden gleichzeitig aktive Anwendungsprozesse auf Operationen mit schreibgeschütztem Zugriff auf die Daten begrenzt.
Update (U): Unter einer U-Sperre werden gleichzeitig aktive Anwendungsprozesse auf schreibgeschützte Operationen an den Daten begrenzt, sofern diese Prozesse nicht deklariert haben, dass sie möglicherweise eine Zeile aktualisieren. Der Datenbankmanager nimmt an, dass der Prozess, der momentan eine Zeile betrachtet, diese Zeile möglicherweise aktualisiert.
Exclusive (X): Unter einer X-Sperre werden gleichzeitig aktive Anwendungsprozesse daran gehindert, irgendeinen Zugriff auf die Daten auszuführen. Dies gilt nicht für Anwendungsprozesse mit der Isolationsstufe UR (Uncommitted Read, nicht festgeschriebener Lesevorgang), die die Daten lesen, jedoch nicht ändern können.

Unabhängig von der Isolationsstufe belegt der Datenbankmanager jede Zeile, die eingefügt, aktualisiert oder gelöscht wird, mit einer exklusiven Sperre. Das heißt, alle Isolationsstufen stellen sicher, dass jede Zeile, die durch einen Anwendungsprozess während einer UOW geändert wird, nicht durch irgendeinen anderen Anwendungsprozess geändert wird, bis die UOW abgeschlossen ist.

Der Datenbankmanager unterstützt vier Isolationsstufen:

Anmerkung: Einige Hostdatenbankserver unterstützen die Isolationsstufe No Commit (NC) ('Kein Commit'). Auf anderen Datenbankservern verhält sich diese Isolationsstufe wie die Isolationsstufe UR (Uncommitted Read, nicht festgeschriebener Lesevorgang).

Anmerkung: Der Aspekt des gemeinsamen Zugriffs Verlorene Aktualisierungen (Lost Updates, LU) ist in keiner der vier Isolationsstufen des DB2-Produkts zulässig.

Im Folgenden werden die einzelnen Isolationsstufen detailliert beschrieben. Die Isolationsstufen sind in absteigender Reihenfolge bezüglich der Auswirkungen auf die Leistung, jedoch in aufsteigender Reihenfolge bezüglich der Vorsicht aufgeführt, die beim Zugriff auf Daten und beim Aktualisieren von Daten erforderlich ist.

Wiederholbares Lesen (RR, Repeatable Read)

Die Isolationsstufe Wiederholbares Lesen (RR) sperrt alle Zeilen, auf die eine Anwendung während einer UOW verweist. Wenn eine Anwendung eine Anweisung SELECT zweimal innerhalb derselben UOW absetzt, wird jedes Mal dasselbe Ergebnis zurückgegeben. Unter der Isolationsstufe RR sind Aktualisierungen, die verloren gehen, Zugriffe auf nicht festgeschriebene Daten, nicht wiederholbare Lesevorgänge und Phantomlesevorgänge nicht möglich.

Unter der Isolationsstufe RR kann eine Anwendung Zeilen so oft wie erforderlich abrufen und an diesen Zeilen arbeiten, bis die UOW abgeschlossen ist. Jedoch kann keine andere Anwendung eine Zeile, die die Ergebnismenge beeinflusst, aktualisieren, löschen oder einfügen, bis die UOW abgeschlossen ist. Für Anwendungen, die unter der Isolationsstufe RR ausgeführt werden, sind nicht festgeschriebene Änderungen anderer Anwendungen nicht sichtbar. Diese Isolationsstufe stellt sicher, dass alle zurückgegebenen Daten bis zu dem Zeitpunkt, zu dem die Daten für die Anwendung sichtbar werden, unverändert bleiben, auch wenn temporäre Tabellen oder Zeilenblockung verwendet werden.

Alle Zeilen, auf die verwiesen wird, werden gesperrt, und nicht nur die Zeilen, die abgerufen werden. Wenn Sie zum Beispiel 10.000 Zeilen unter Verwendung von Vergleichselementen durchsuchen, werden alle 10.000 Zeilen gesperrt, auch wenn letzten Endes nur 10 Zeilen den Vergleichselementen entsprechen. Eine andere Anwendung kann keine Zeile einfügen oder aktualisieren, die der Liste von Zeilen, auf die in einer Abfrage verwiesen wird, hinzugefügt würde, wenn diese Abfrage erneut ausgeführt würde. Dadurch wird das Lesen von Phantomzeilen vermieden.

Da unter der Isolationsstufe RR eine beträchtliche Anzahl Sperren aktiviert werden kann, kann diese Anzahl die Grenzen überschreiten, die durch die Datenbankkonfigurationsparameter locklist und maxlocks angegeben werden. Um eine Sperreneskalation zu vermeiden, kann das Optimierungsprogramm eventuell eine einzige Sperre auf Tabellenebene für eine Indexsuche anfordern, wenn das Auftreten einer Sperreneskalation wahrscheinlich ist. Wenn Sie keine Sperren auf Tabellenebene wünschen, verwenden Sie die Isolationsstufe der Lesestabilität (RS).

Bei der Auswertung referenzieller Integritätsbedingungen kann der DB2-Server gelegentlich die für Suchen in der Fremdtabelle verwendete Isolationsstufe unabhängig von der zuvor vom Benutzer festgelegten Isolationsstufe auf RR heraufsetzen. Dadurch werden zusätzliche Sperren bis zur COMMIT-Operation aktiviert, sodass die Wahrscheinlichkeit eines Deadlocks oder einer Sperrzeitlimitüberschreitung zunimmt. Zur Vermeidung solcher Probleme können Sie einen Index erstellen, der nur Fremdschlüsselspalten enthält und der vom Suchlauf zur Überprüfung auf referenzielle Integrität alternativ verwendet werden kann.

Lesestabilität (RS, Read Stability)

Die Isolationsstufe Lesestabilität (RS) sperrt nur die Zeilen, die von einer Anwendung während einer UOW abgerufen werden. Sie stellt sicher, dass jede den Vergleichselementen entsprechende gelesene Zeile während einer UOW nicht von Prozessen anderer Anwendungen geändert werden kann, bis die UOW abgeschlossen ist, und dass keine von einem anderen Anwendungsprozess vorgenommene Änderung an einer Zeile gelesen werden kann, bis die Änderung von diesem Prozess festgeschrieben wurde. Unter der Isolationsstufe RS sind Zugriffe auf nicht festgeschriebene Daten und nicht wiederholbare Lesevorgänge nicht möglich. Lesevorgänge mit Phantomzeilen sind jedoch möglich. Phantomleseoperationen können auch durch die gleichzeitige Aktualisierung von Zeilen verursacht werden, bei denen die Suchbedingung der ursprünglichen Anwendung nicht durch den alten Wert erfüllt wurde, nun aber durch den neuen aktualisierten Wert erfüllt wird.

Eine Phantomzeile kann z. B. in folgenden Situationen auftreten:

Anwendungsprozess P1 liest die Zeilen (n), die eine bestimmte Suchbedingung erfüllen.
Anwendungsprozess P2 fügt eine oder mehrere Zeilen ein, die die Suchbedingung erfüllen, und schreibt die neuen Einfügungen durch Commit fest.
P1 liest die Zeilen nochmals mit derselben Suchbedingung und ruft sowohl die ursprünglichen Zeilen als auch die durch P2 eingefügten Zeilen ab.

In einer DB2 pureScale-Umgebung weist eine Anweisung, die mit dieser Isolationsstufe ausgeführt wird, möglicherweise einen zuvor festgeschriebenen Zeilenwert zurück, wenn die Zeile gleichzeitig auf einem anderen Member aktualisiert wird. Um dieses Verhalten außer Kraft zu setzen, geben Sie die Option WAIT_FOR_OUTCOME an.

Diese Isolationsstufe stellt sicher, dass alle zurückgegebenen Daten bis zu dem Zeitpunkt, zu dem die Daten für die Anwendung sichtbar werden, unverändert bleiben, auch wenn temporäre Tabellen oder Zeilenblockung verwendet werden.

Die Isolationsstufe RS stellt einen hohen Grad an gemeinsamem Zugriff und eine stabile Sicht der Daten zur Verfügung. Zu diesem Zweck stellt Optimierungsprogramm sicher, dass Sperren auf Tabellenebene erst aktiviert werden, wenn eine Sperreneskalation auftritt.

Die Isolationsstufe RS eignet sich für eine Anwendung mit folgenden Merkmalen:

Sie arbeitet in einer Umgebung mit gemeinsamem Zugriff.
Sie erfordert, dass Zeilen, die den Vergleichselementen entsprechen, die für die Dauer der UOW stabil bleiben müssen.
Die setzt dieselbe Abfrage nicht mehr als einmal während einer UOW ab oder benötigt keine identischen Ergebnismengen, wenn eine Abfrage mehrmals während einer UOW abgesetzt wird.

Cursorstabilität (CS, Cursor Stability)

Die Isolationsstufe Cursorstabilität (CS) sperrt jede Zeile, auf die während einer Transaktion zugegriffen wird, während sich der Cursor auf dieser Zeile befindet. Diese Sperre bleibt in Kraft, bis die nächste Zeile abgerufen oder die Transaktion beendet wird. Wenn jedoch Daten in der Zeile geändert wurden, wird die Sperre beibehalten, bis die Änderung durch ein Commit festgeschrieben wird.

Unter dieser Isolationsstufe kann keine andere Anwendung eine Zeile aktualisieren oder löschen, während ein Aktualisierungscursor auf dieser Zeile positioniert ist. Unter der Isolationsstufe CS ist kein Zugriff auf nicht festgeschriebene Daten anderer Anwendungen möglich. Nicht wiederholbare Lesevorgänge und Lesevorgänge mit Phantomzeilen sind jedoch möglich.

Cursorstabilität ist die Standardisolationsstufe. Sie ist geeignet, wenn Sie einen maximalen gemeinsamen Zugriff wünschen und nur festgeschriebene Daten lesen wollen. Auf dieser Isolationsstufe durchgeführte Suchvorgänge verhalten Sie entsprechend des Konfigurationsparameters cur_commit (Currently Committed - Aktuell festgeschrieben).

In einer DB2 pureScale-Umgebung weist eine Anweisung, die mit dieser Isolationsstufe ausgeführt wird, möglicherweise einen zuvor festgeschriebenen Zeilenwert zurück, wenn die Zeile gleichzeitig auf einem anderen Member aktualisiert wird. Die Option WAIT FOR OUTCOME der Einstellung zur Behandlung gleichzeitiger Zugriffe kann verwendet werden, um dieses Verhalten außer Kraft zu setzen.

Anmerkung: Unter der Semantik zur Verarbeitung zurzeit festgeschriebener Daten ('cur_commit'), die in Version 9.7 eingeführt wurde, werden nur festgeschriebene Daten zurückgegeben, wie dies auch zuvor der Fall war. Jetzt warten jedoch lesende Anwendungen nicht mehr auf die Freigabe von Zeilensperren durch aktualisierende Anwendungen. Stattdessen geben lesende Anwendungen Daten auf der Basis der zurzeit festgeschriebenen Version zurück. Das heißt, Daten, wie sie vor dem Start der Schreiboperation vorlagen.

Nicht festgeschriebener Lesevorgang (UR, Uncommitted Read)

Die Isolationsstufe Nicht festgeschriebener Lesevorgang (UR) erlaubt einer Anwendung den Zugriff auf nicht festgeschriebene Änderungen anderer Transaktionen. Darüber hinaus verhindert die Isolationsstufe UR nicht, dass eine andere Anwendung auf eine Zeile zugreift, die gerade gelesen wird, sofern diese nicht versucht, die Tabelle zu ändern oder zu löschen.

Unter der Isolationsstufe UR sind Zugriffe auf nicht festgeschriebene Daten, nicht wiederholbare Lesevorgänge und Phantomlesevorgänge möglich. Diese Isolationsstufe ist geeignet, wenn Sie Abfragen auf schreibgeschützte Tabelle ausführen oder wenn Sie nur SELECT-Anweisungen ausführen und die Anzeige von Daten, die von anderen Anwendungen nicht festgeschrieben wurden, kein Problem ist.

Die Isolationsstufe UR funktioniert für Nur-Lese-Cursor und für Aktualisierungscursor unterschiedlich:

Nur-Lese-Cursor können auf die meisten nicht festgeschriebenen Änderungen anderer Transaktionen zugreifen.
Tabellen, Sichten und Indizes, die momentan von anderen Transaktionen erstellt oder gelöscht werden, sind während der Verarbeitung der Transaktion nicht verfügbar. Alle anderen Änderungen durch andere Transaktionen können gelesen werden, bevor sie mit COMMIT festgeschrieben oder mit ROLLBACK rückgängig gemacht wurden. Aktualisierungscursor, die unter der Isolationsstufe UR arbeiten, verhalten sich wie unter der Isolationsstufe CS.

Wenn eine Anwendung unter der Isolationsstufe UR mehrdeutige Cursor verwendet, verwendet sie bei der Ausführung möglicherweise die Isolationsstufe CS. Die mehrdeutigen Cursor können auf die Isolationsstufe CS eskaliert werden, wenn der Wert UNAMBIG (Standardwert) für die Option BLOCKING im Befehl PREP oder BIND angegeben wird. Zur Vermeidung dieser Eskalation haben Sie folgende Möglichkeiten:

Ändern Sie die Cursor im Anwendungsprogramm in eindeutige Cursor (UNAMBIGUOUS). Ändern Sie die SELECT-Anweisungen, um die Klausel FOR READ ONLY hinzuzufügen.
Belassen Sie die Cursor im Anwendungsprogramm mehrdeutig. Kompilieren Sie jedoch das Programm mit den Optionen BLOCKING ALL und STATICREADONLY YES vor oder binden Sie es mit diesen Optionen, damit die mehrdeutigen Cursor als Nur-Lese-Cursor behandelt werden, wenn das Programm ausgeführt wird.

Vergleich der Isolationsstufen

In Tabelle 1 werden die unterstützten Isolationsstufen zusammengefasst.

Tabelle 1. Vergleich der Isolationsstufen
	UR	CS	RS	RR
Sind für eine Anwendung nicht festgeschriebene Änderungen anderer Anwendungsprozesse sichtbar?	Ja	Nein	Nein	Nein
Kann eine Anwendung nicht festgeschriebene Änderungen anderer Anwendungsprozesse aktualisieren?	Nein	Nein	Nein	Nein
Kann die erneute Ausführung einer Anweisung von anderen Anwendungsprozessen beeinflusst werden? ¹	Ja	Ja	Ja	Nein²
Können aktualisierte Zeilen von anderen Anwendungsprozessen aktualisiert werden? ³	Nein	Nein	Nein	Nein
Können aktualisierte Zeilen von anderen Anwendungsprozessen gelesen werden, die unter einer anderen Isolationsstufe als UR ausgeführt werden?	Nein	Nein	Nein	Nein
Können aktualisierte Zeilen von anderen Anwendungsprozessen gelesen werden, die unter der Isolationsstufe UR ausgeführt werden?	Ja	Ja	Ja	Ja
Können Zeilen, auf die zugegriffen wurde, von anderen Anwendungsprozessen aktualisiert werden? ⁴	Ja	Ja	Nein	Nein
Können Zeilen, auf die zugegriffen wurde, von anderen Anwendungsprozessen gelesen werden?	Ja	Ja	Ja	Ja
Kann die aktuelle Zeile von anderen Anwendungsprozessen aktualisiert oder gelöscht werden? ⁵	Ja/Nein ⁶	Ja/Nein ⁶	Nein	Nein
Anmerkung: Ein Beispiel für das Phänomen von gelesenen Phantomzeilen ist folgendes: Eine UOW mit dem Namen UW1 liest die Gruppe von `n` Zeilen, die eine Suchbedingung erfüllen. Eine UOW mit dem Namen UW2 fügt eine oder mehrere Zeilen ein, die dieselbe Suchbedingung erfüllen und schreibt die Änderung durch Commit fest. Wenn UW1 nachfolgend den Lesevorgang mit derselben Suchbedingung wiederholt, wird eine andere Ergebnismenge zurückgegeben: Die Zeilen, die ursprünglich gelesen wurden, und dazu die Zeilen, die von UW2 eingefügt wurden. Wenn Ihre Berechtigungsnachweise für die kennsatzbasierte Zugriffssteuerung (LBAC) zwischen den Lesevorgängen geändert werden, können die Ergebnisse für den zweiten Lesevorgang abweichen, weil Sie Zugriff auf andere Zeilen haben. Die Isolationsstufe bietet keinen Schutz für die Anwendung, wenn die Anwendung aus einer Tabelle liest und in sie schreibt. Eine Anwendung öffnet zum Beispiel einen Cursor auf einer Tabelle und führt eine Einfüge-, Aktualisierungs- oder Löschoperation an derselben Tabelle aus. Der Anwendung werden möglicherweise inkonsistente Daten zurückgegeben, wenn mehr Zeilen aus dem geöffneten Cursor abgerufen werden. Ein Beispiel für das Phänomen nicht wiederholbarer Lesevorgänge ist folgendes: Eine UOW mit dem Namen UW1 liest eine Zeile. Eine UOW mit dem Namen UW2 ändert diese Zeile und schreibt sie mit Commit fest. Wenn UW1 anschließend diese Zeile erneut liest, wird ihr ein anderer Wert zurückgegeben. Ein Beispiel für das Phänomen des Lesens geänderter Daten ist folgendes: Eine UOW mit dem Namen UW1 ändert eine Zeile. Eine UOW mit dem Namen UW2 liest diese Zeile, bevor UW1 eine Commitoperation ausführt. Falls UW1 nachfolgend die Änderungen durch Rollback rückgängig macht, hat UW2 Daten gelesen, die nicht mehr vorhanden sind. Unter der Isolationsstufe UR oder CS kann die aktuelle Zeile, wenn der Cursor kein Aktualisierungscursor ist, in einigen Fällen von anderen Anwendungsprozessen aktualisiert oder gelöscht werden. Zum Beispiel kann sich aufgrund der Pufferung die aktuelle Zeile auf dem Client von der aktuellen Zeile auf dem Server unterscheiden. Darüber hinaus kann bei Verwendung der Semantik für zurzeit festgeschriebene Daten unter der Isolationsstufe CS eine Zeile, die gerade gelesen wird, anstehende nicht festgeschriebene Aktualisierungen haben. In diesem Fall wird immer die zurzeit festgeschriebene Version an die Anwendung zurückgegeben.

Zusammenfassung der Isolationsstufen

In Tabelle 2 werden die Aspekte des gemeinsamen Zugriffs in Verbindung mit verschiedenen Isolationsstufen aufgeführt.

Tabelle 2. Zusammenfassung der Isolationsstufen
Isolationsstufe	Zugriff auf nicht festgeschriebene Daten	Nicht wiederholbare Lesevorgänge	Lesevorgänge mit Phantomzeilen
Wiederholbares Lesen (RR, Repeatable Read)	Nicht möglich	Nicht möglich	Nicht möglich
Lesestabilität (RS, Read Stability)	Nicht möglich	Nicht möglich	Möglich
Cursorstabilität (CS, Cursor Stability)	Nicht möglich	Möglich	Möglich
Nicht festgeschriebener Lesevorgang (UR, Uncommitted Read)	Möglich	Möglich	Möglich

Von der Isolationsstufe sind nicht nur die verschiedenen Grade der Isolation zwischen Anwendungen, sondern auch die Leistungsmerkmale einer einzelnen Anwendung betroffen, weil die Verarbeitungs- und Speicherressourcen, die zur Aktivierung und Freigabe von Sperren erforderlich sind, mit der Isolationsstufe variieren. Die Möglichkeit, dass Deadlocks auftreten, ist ebenfalls je nach Isolationsstufe unterschiedlich. In Tabelle 3 finden Sie einfache heuristische Anhaltpunkte, die Ihnen bei der Wahl der ersten Isolationsstufe für Ihre Anwendungen helfen können.

Tabelle 3. Richtlinien zur Wahl einer Isolationsstufe
Anwendungstyp	Hohe Datenstabilität erforderlich	Hohe Datenstabilität nicht erforderlich
Transaktionen mit Schreib-/Lesezugriff	RS	CS
Transaktionen mit Lesezugriff	RR oder RS	UR