DB2 Universal Database - Systemverwaltung


Gemeinsamer Zugriff

Die Integrität der Daten in einer relationalen Datenbank muß gewährleistet werden, auch wenn mehrere Benutzer auf die Daten zugreifen und sie ändern. Der Begriff gemeinsamer Zugriff bezeichnet die Möglichkeit, daß mehrere interaktive Benutzer oder Anwendungsprogramme die Ressourcen zur gleichen Zeit verwenden können. Der Datenbankmanager steuert diesen Zugriff, um unerwünschte Folgen zu vermeiden. Solche Folgen sind zum Beispiel:

Eine Isolationsstufe legt fest, wie Daten gesperrt oder von anderen Prozessen während des Zugriffs auf die Daten isoliert werden. Die Isolationsstufe ist während der Dauer der Arbeitseinheit in Kraft. Anwendungen, die einen Cursor verwenden, der mit der Klausel WITH HOLD deklariert wurde, behalten die gewählte Isolationsstufe für die Dauer der Arbeitseinheit bei, in der die Anweisung OPEN CURSOR durchgeführt wurde. (Weitere Informationen finden Sie im Handbuch SQL Reference.) Lesen Sie die Informationen zur Angabe der Isolationsstufe im Abschnitt Angeben der Isolationsstufe.

DB2 unterstützt die folgenden Isolationsstufen:

(Beachten Sie, daß einige DRDA-Datenbank-Server die Isolationsstufe Kein Festschreiben (No Commit) unterstützen. In anderen Datenbanken verhält sich diese Stufe wie die Isolationsstufe Nicht festgeschriebener Lesevorgang (Uncommited Read). Informationen zu dieser Isolationsstufe finden Sie in SQL Reference.)

Siehe auch:

Sie arbeiten eventuell in einem System mit zusammengeschlossenen Datenbanken, das das Übergeben von SQL-Anweisungen durch Anwendungen und Benutzer unterstützt, in denen auf mehrere Datenbankverwaltungssysteme oder Datenbanken in einer einzelnen Anweisung verwiesen wird. In einem DB2-System mit zusammengeschlossenen Datenbanken besteht für Datenbankobjekte Positionstransparenz. Wenn zum Beispiel Informationen zu Tabellen und Sichten versetzt werden, können Verweise auf diese Informationen (sogenannte Kurznamen) ohne Änderungen an den Anwendungen, die die Informationen anfordern, aktualisiert werden. Wenn eine Anwendung auf Kurznamen zugreift, verläßt sich DB2 auf die Protokolle zur Steuerung des gemeinsamen Zugriffs von Datenbankmanagern der Datenquellen, um Isolationsstufen sicherzustellen. (Eine Datenquelle besteht aus einem Datenbankverwaltungssystem und Daten.) DB2 versucht, die angeforderte Isolationsstufe an der Datenquelle mit einem logischen Äquivalent abzugleichen. Die Ergebnisse sind abhängig vom Leistungsspektrum der Datenquelle jedoch eventuell unterschiedlich. Im Handbuch Application Development Guide finden Sie Informationen zum Schreiben von Anwendungen, die auf Kurznamen zugreifen.

Im folgenden sind detaillierte Erläuterungen zu den Isolationsstufen aufgeführt. Diese sind in absteigender Reihenfolge bezüglich der Auswirkungen auf die Leistung, aber in aufsteigender Reihenfolge bezüglich der Vorsicht geordnet, die beim Zugriff auf und Aktualisieren von Daten erforderlich ist.

Wiederholtes Lesen (RR)

Die Isolationsstufe Wiederholtes Lesen (RR - Repeatable Read) sperrt alle Zeilen innerhalb einer Arbeitseinheit, auf die eine Anwendung verweist. Bei Verwendung der Isolationsstufe RR liefert eine Anweisung SELECT, die von einer Anwendung zweimal innerhalb derselben Arbeitseinheit, in der der Cursor geöffnet wurde, ausgegeben wird, jedesmal dasselbe Ergebnis. Bei der Isolationsstufe RR können verlorene Aktualisierungen, Zugriffe auf nicht festgeschriebene Daten und Phantomzeilen nicht auftreten.

Eine Anwendung mit der Isolationsstufe RR kann, bis die Arbeitseinheit beendet wird, so oft wie erforderlich Zeilen abrufen und Aktionen an ihnen vornehmen. Andere Anwendungen können jedoch keine Zeile aktualisieren, löschen oder einfügen, die sich auf die Ergebnistabelle auswirken würde, bis die Arbeitseinheit beendet ist. Für Anwendungen mit der Isolationsstufe RR sind nicht festgeschriebene Änderungen anderer Anwendungen nicht sichtbar.

Durch die Isolationsstufe RR werden alle Zeilen, auf die verwiesen wird, und nicht nur die Zeilen, die abgerufen werden, gesperrt. Die Sperrung wird so ausgeführt, daß eine andere Anwendung keine Zeile einfügen oder aktualisieren kann, die der Liste von Zeilen, auf die in der Abfrage verwiesen wird, hinzugefügt würde, wenn die Abfrage erneut ausgeführt würde. Dadurch wird das Auftreten von Phantomzeilen verhindert. Das bedeutet, wenn Sie zum Beispiel 10000 Zeilen unter Verwendung von Vergleichselementen durchsuchen, werden alle 10000 Zeilen gesperrt, auch wenn letzten Endes nur 10 Zeilen den Vergleichselementen entsprechen.
Anmerkung:Durch die Isolationsstufe RR wird sichergestellt, daß alle zurückgelieferten 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.

Da die Isolationsstufe RR eine beträchtliche Anzahl an Sperren erfordern kann, können diese Sperren die Anzahl von Sperren, die durch die Konfigurationsparameter locklist und maxlocks festgelegt wird, überschreiten. (Siehe Maximale Anzahl Sperren pro Anwendung (maxlocks) und Maximaler Speicher für Sperrenliste (locklist).) Um eine Sperreneskalation zu vermeiden, kann das Optimierungsprogramm eventuell von vornherein eine einzige Sperre auf Tabellenebene für eine Indexsuche anfordern, wenn das Auftreten einer Sperreneskalation wahrscheinlich ist. (Informationen zur Sperreneskalation finden Sie in Sperreneskalation.) Dies funktioniert so, als würde der Datenbankmanager für Sie eine Anweisung LOCK TABLE ausgeben. Wenn Sie keine Sperre auf Tabellenebene aktivieren lassen möchten, stellen Sie sicher, daß für die Transaktion ausreichend Sperren verfügbar sind, oder verwenden Sie die Isolationsstufe "Lesestabilität (RS)".

Lesestabilität (RS)

Die Isolationsstufe Lesestabilität (RS - Read Stability) sperrt nur die Zeilen, die von einer Anwendung innerhalb einer Arbeitseinheit abgerufen werden. Sie stellt sicher, daß jede den Vergleichselementen entsprechende gelesene Zeile während einer Arbeitseinheit nicht von Prozessen anderer Anwendungen geändert wird und daß keine, von einem Prozeß einer anderen Anwendung geänderte Zeile gelesen wird, bis die Änderung von dem Prozeß festgeschrieben wurde. Das heißt, "nichtwiederholbare Lesevorgänge" sind nicht möglich.

Anders als bei der Isolationsstufe RR ("Wiederholtes Lesen") können bei der Isolationsstufe RS, wenn die Anwendung dieselbe Abfrage mehr als einmal absetzt, zusätzliche Phantomzeilen auftreten (Phänomen der Phantomzeilen). In dem bereits angeführten Beispiel der Suche über 10000 Zeilen werden durch die Isolationsstufe RS nur die den Vergleichselementen entsprechenden Zeilen gesperrt. Da durch die Abfrage nur 10 Zeilen abgerufen werden, werden unter der Isolationsstufe RS nur für diese 10 Zeilen Sperren aktiviert. Unter der Isolationsstufe RR ("Wiederholtes Lesen") werden in diesem Beispiel hingegen sämtliche 10000 Zeilen gesperrt. Bei den aktivierten Sperren kann es sich um Sperren der Modi Share, Next Share, Update oder Exclusive handeln. (Weitere Informationen zu den Sperrenattributen finden Sie in Attribute von Sperren.)
Anmerkung:Durch die Isolationsstufe RS wird sichergestellt, daß alle zurückgelieferten 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.

Ein Zweck der Isolationsstufe RS besteht darin, sowohl einen hohen Grad des gemeinsamen Zugriffs als auch eine stabile Sicht der Daten zur Verfügung zu stellen. Um diesen Zweck zu erfüllen, stellt das Optimierungsprogramm sicher, daß Sperren auf Tabellenebene erst aktiviert werden, wenn eine Sperreneskalation auftritt. (Weitere Informationen zur Sperreneskalation finden Sie in Sperreneskalation.)

Die Isolationsstufe RS eignet sich am besten für Anwendungen, die alle folgenden Merkmale aufweisen:

Cursorstabilität (CS)

Die Isolationsstufe Cursorstabilität (CS - Cursor Stability) sperrt jede Zeile, auf die von einer Transaktion einer Anwendung zugegriffen wird, während sich der Cursor auf der Zeile befindet. Diese Sperre bleibt aktiv, bis die nächste Zeile abgerufen oder die Transaktion beendet wird. Wenn jedoch Daten in einer Zeile geändert werden, muß die Sperre aktiv bleiben, bis die Änderung in der Datenbank festgeschrieben wurde.

Keine anderen Anwendungen können eine Zeile aktualisieren oder löschen, die von einer Anwendung mit der Isolationsstufe CS abgerufen wurde, während sich ein Aktualisierungscursor auf der Zeile befindet. Für Anwendungen mit der Isolationsstufe CS sind nicht festgeschriebene Änderungen anderer Anwendungen nicht sichtbar.

In dem bereits angeführten Beispiel einer Suche über 10000 Zeilen heißt dies, daß unter der Isolationsstufe CS lediglich eine Sperre für die Zeile, die unter der aktuellen Cursorposition liegt, aktiv ist. Die Sperre wird entfernt, wenn der Cursor von der Zeile fortbewegt wird (sofern die Zeile nicht aktualisiert wurde).

Bei der Isolationsstufe CS können sowohl unterschiedliche Abfrageergebnisse innerhalb derselben Arbeitseinheit (d. h. nicht wiederholbare Abfragevorgänge) als auch Phantomzeilen auftreten. Die Isolationsstufe CS ist die Standardisolationsstufe, die verwendet werden sollte, wenn es auf den höchstmöglichen Grad des gemeinsamen Zugriffs ankommt und nur festgeschriebene Zeilen anderer Anwendungen sichtbar sein sollen.

Nicht festgeschriebener Lesevorgang (UR)

Die Isolationsstufe Nicht festgeschriebener Lesevorgang (UR - Uncommitted Read) erlaubt einer Anwendung den Zugriff auf nicht festgeschriebene Änderungen anderer Transaktionen. Die Anwendung sperrt die Zeile, die sie liest, auch für keine andere Anwendung, sofern die andere Anwendung nicht versucht, die Tabelle zu löschen oder zu ändern. Die Isolationsstufe UR (Uncommitted Read) wirkt sich auf Aktualisierungscursor und Lesecursor unterschiedlich aus.

Cursor mit Lesezugriff 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 jedoch nicht verfügbar. Alle anderen Änderungen durch andere Transaktionen können gelesen werden, bevor sie festgeschrieben oder rückgängig gemacht wurden.
Anmerkung:Aktualisierungscursor, die unter der Isolationsstufe UR arbeiten, verhalten sich genauso wie unter der Isolationsstufe CS (Cursorstabilität).

Im genannten Beispiel einer Suche über 10000 Zeilen sind bei der Isolationsstufe UR keine Zeilensperren erforderlich.

Bei der Isolationsstufe UR können sowohl unterschiedliche Abfrageergebnisse innerhalb derselben Arbeitseinheit (d. h. nicht wiederholbare Abfragevorgänge) als auch Phantomzeilen auftreten.

Die Isolationsstufe UR wird in der Regel für Abfragen auf Tabellen verwendet, die sich im Lesezugriff befinden, oder wenn Anweisungen SELECT ausgeführt werden und es dabei keine Rolle spielt, ob nicht festgeschriebene Daten anderer Anwendungen angezeigt werden.

Wählen der Isolationsstufe

Tabelle 36 faßt die verschiedenen Isolationsstufen im Hinblick auf die im Handbuch Application Development Guide beschriebenen, unerwünschten Nebeneffekte zusammen.

Tabelle 36. Zusammenfassung der Isolationsstufen
Isolationsstufe Zugriff auf nicht festgeschriebene Daten Nichtwiederholbare Lesevorgänge Phänomen der Phantomzeilen
Wiederholtes Lesen (RR) Nicht möglich Nicht möglich Nicht möglich
Lesestabilität (RS) Nicht möglich Nicht möglich Möglich
Cursorstabilität (CS) Nicht möglich Möglich Möglich
Nicht festgeschriebener Lesevorgang (UR) Möglich Möglich Möglich

Tabelle 37 gibt einfache Anhaltspunkte, die Ihnen bei der Wahl der ersten Isolationsstufe für Ihre Anwendungen helfen können. Betrachten Sie die Angaben dieser Tabelle als Ausgangspunkt, und lesen Sie die Beschreibung der verschiedenen Isolationsstufen in den vorigen Abschnitten, um Hinweise zu erhalten, die vielleicht einen geeigneteren Wert für Ihre Anforderungen empfehlen.

Tabelle 37. Hinweise zur Wahl einer Isolationsstufe
Anwendungsart Hohe Datenstabilität erforderlich Hohe Datenstabilität nicht erforderlich
Schreib-/Lese-Transaktionen RS CS
Transaktionen mit Lesezugriff RR oder RS UR

Die Wahl der geeigneten Isolationsstufe für eine Anwendung ist zur Vermeidung von Erscheinungen, die für die Anwendung nicht tolerierbar sind, äußerst wichtig. Von der Isolationsstufe sind nicht nur die verschiedenen Grade der Isolation zwischen Anwendungen, sondern auch die Leistungsmerkmale einer einzelnen Anwendung betroffen, da die CPU- und Speicherressourcen, die zur Aktivierung und Freigabe von Sperren erforderlich sind, mit der Isolationsstufe variieren. Die Möglichkeit, daß gegenseitige Sperren auftreten, ist ebenfalls je nach Isolationsstufe unterschiedlich.

Angeben der Isolationsstufe

Die Isolationsstufe wird beim Vorkompilieren oder beim Binden einer Anwendung an die Datenbank angegeben. Für eine Anwendung, die in einer unterstützten kompilierten Sprache geschrieben ist, wird die Option ISOLATION der Befehle PREP oder BIND des Befehlszeilenprozessors verwendet. Die Isolationsstufe kann außerdem mit den Anwendungsprogrammierschnittstellen PREP oder BIND angegeben werden. Wenn keine Isolationsstufe angegeben wird, wird die Standardisolationsstufe CS (Cursorstabilität) verwendet.

Wenn eine Bindedatei beim Vorkompilieren erstellt wird, wird die Isolationsstufe in der Bindedatei gespeichert. Wenn beim Binden keine Isolationsstufe angegeben wird, wird beim Vorkompilieren die Standardisolationsstufe verwendet.

Die Isolationsstufe eines Pakets kann mit Hilfe der folgenden Abfrage festgestellt werden:

     SELECT ISOLATION FROM SYSCAT.PACKAGES
       WHERE PKGNAME = 'XXXXXXXX'
       AND PKGSCHEMA = 'YYYYYYYY'

Hier steht XXXXXXXX für den Namen des Pakets und YYYYYYYY für den Schemennamen des Pakets. Beide Namen müssen vollständig in Großbuchstaben angegeben werden.

Wenn eine Datenbank erstellt wird, werden mehrere Bindedateien, die zur Unterstützung der verschiedenen Isolationsstufen für SQL in REXX dienen, an die Datenbank (auf den Servern, die REXX unterstützen) gebunden. Andere Befehlszeilenprozessorpakete werden auch an die Datenbank gebunden, wenn die Datenbank erstellt wird. Weitere Informationen zu Bindedateien finden Sie im Handbuch Application Development Guide.

REXX und der Befehlszeilenprozessor stellen die Verbindung zu einer Datenbank mit der Standardisolationsstufe CS (Cursorstabilität) her. Durch die Änderung in eine andere Isolationsstufe wird der Status der Verbindung nicht geändert. Dies muß im Status CONNECTABLE AND UNCONNECTED oder IMPLICITLY CONNECTABLE ausgeführt werden. (Genauere Informationen zu den Verbindungsstatus finden Sie im Abschnitt zur Anweisung CONNECT TO im Handbuch SQL Reference.) Sie dürfen nicht mit einer Datenbank verbunden sein, wenn Sie diesen Befehl absetzen.

Die momentan verwendete Isolationsstufe kann von einer REXX-Anwendung mit Hilfe des Werts der REXX-Variablen SQLISL überprüft werden. Dieser Wert wird jedesmal aktualisiert, wenn der Befehl CHANGE SQLISL ausgeführt wird.

Mit der Variablen für DB2_RR_TO_RS aus der Profilregistrierdatenbank können Sie den Zugriff auf Benutzertabellen auf der Isolationsstufe RR ("Wiederholtes Lesen") verhindern. Dieser Registrierungswert kann mit db2set in Umgebungen, in denen die Isolationssemantik RR nicht erforderlich ist, auf "YES" gesetzt werden. Damit er wirksam wird, müssen Sie die Datenbank stoppen und starten. Nach db2start wirkt sich diese Änderung auf das gesamte Exemplar aus. Wenn dann eine Anforderung zum Zugriff auf eine Benutzertabelle unter Verwendung der Isolationsstufe RR empfangen wird, wird sie intern in die Verwendung der Isolationsstufe RS ("Lesestabilität") geändert. In diesem Fall wird keine Warnung ausgegeben.

Wenn Sie den Befehlszeilenprozessor verwenden, können Sie die Isolationsstufe mit Hilfe des Befehls CHANGE ISOLATION LEVEL ändern. Im Handbuch Command Reference finden Sie weitere Informationen.

Für DB2 Call Level Interface (CLI) können Sie die Isolationsstufe bei der Konfiguration von CLI ändern. In CLI verwenden Sie bei der Laufzeit die Funktion "SQLSetConnectAttr" mit dem Attribut SQL_ATTR_TXN_ISOLATION. Dadurch wird die Isolationsstufe der Transaktion für die aktuelle Verbindung festgelegt, auf die durch ConnectionHandle verwiesen wird. In der Datei "db2cli.ini" können Sie auch das Schlüsselwort TXNISOLATION verwenden.
Anmerkung:JDBC und SQLJ sind in DB2 mit CLI implementiert. Dies bedeutet, daß die Einstellungen der Datei "db2cli.ini" Einfluß auf die Projekte haben, die unter Verwendung von JDBC und SQLJ geschrieben und ausgeführt werden. Im Handbuch CLI Guide and Reference finden Sie weitere Informationen hierzu.

Wenn Sie zur Laufzeit mit JDBC oder SQLJ arbeiten, können Sie die Methode "setTransactionIsolation" in der java.sql-Schnittstellenverbindung verwenden, um die Isolationsstufe einzurichten. Weitere Informationen hierzu finden Sie im Kapitel über die Java-Programmierung im Handbuch Application Development Guide.

Während der Arbeit mit SQLJ wird beim Ausführen des SQLJ-Optimierungsprogramms "db2profc" ein Paket erstellt. Die letzten Optionen für dieses Paket können die zu verwendende Isolationsstufe enthalten. Weitere Informationen hierzu finden Sie im Kapitel über die Java-Programmierung im Handbuch Application Development Guide.

Außerdem bieten zahlreiche gewerblich geschriebene Anwendungen eine Möglichkeit an, die Isolationsstufe zu wählen. Im Handbuch CLI Guide and Reference finden Sie weitere Informationen.

Deklarierte temporäre Tabellen und gemeinsamer Zugriff

Bei deklarierten temporären Tabellen gibt es keine Probleme bezüglich des gemeinsamen Zugriffs, da sie nur für die Anwendung verfügbar sind, die sie deklariert hat. Diese Art von Tabelle besteht nur vom Zeitpunkt ihrer Deklaration durch die Anwendung bis zu deren Beendigung bzw. bis zum Unterbrechen der Verbindung durch diese.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]