DB2 Universal Database - Systemverwaltung


Sperren

Der Datenbankmanager ermöglicht die Steuerung des gemeinsamen Zugriffs und verhindert den unkontrollierten Zugriff mit Hilfe von Sperren. Eine Sperre ist eine Methode, eine Ressource des Datenbankmanagers einer Anwendung zuzuordnen, um zu steuern, wie andere Anwendungen auf diese Ressource zugreifen können. Eine Anwendung, der eine Ressource zugeordnet ist, aktiviert die Sperre oder ist Eigner der Sperre.

Der Datenbankmanager richtet Sperren ein, um Anwendungen daran zu hindern, auf nicht festgeschriebene Daten zuzugreifen, die von anderen Anwendungen geschrieben wurden (außer bei Verwendung der Isolationsstufe für nicht festgeschriebenes Lesen). Durch dieses Prinzip wird die Datenintegrität geschützt (d. h. die Konsistenz und die Sicherheit von Daten). Sperren können auch die Aktualisierung von Zeilen (zum Beispiel für eine Anwendung mit der Isolationsstufe RR) verhindern.

Zur Gewährleistung der Datenintegrität aktiviert der Datenbankmanager implizit Sperren unter der Steuerung des Datenbankmanagers. Außer für die Isolationsstufe UR (Nicht festgeschriebener Lesevorgang) muß eine Anwendung nie explizit eine Sperre anfordern, um sicherzustellen, daß nicht festgeschriebene Daten für andere Prozesse unsichtbar gemacht werden.

Aufgrund dieses Grundkonzepts der Sperren ist es in den meisten Fällen nicht nötig, zur Steuerung von Sperren explizite Maßnahmen zu ergreifen. Dennoch werden Sperren für Anwendungen auf der Grundlage bestimmter allgemeiner Parameter aktiviert. Die Kenntnis der Verhältnisse in Ihrer lokalen Umgebung kann dazu beitragen, daß Sie die Systemressourcen durch Ändern der Parameter effektiver nutzen können. Die folgenden Themen enthalten eingehendere Informationen zu Sperren:

Attribute von Sperren

Sperren des Datenbankmanagers verfügen über folgende Basisattribute:

Modus
Die Art des Zugriffs, die dem Sperreneigner gewährt wird, sowie die Art des Zugriffs, die Benutzern gewährt wird, die das gesperrte Objekt gleichzeitig verwenden. Dies wird manchmal auch als Status der Sperre bezeichnet.

Objekt
Die Ressource, die gesperrt ist. Die einzigen explizit sperrbaren Objekte sind Tabellen. Der Datenbankmanager implementiert Sperren auch für andere Arten von Ressourcen, wie Zeilen, Tabellen und Tabellenbereiche. Das Objekt, das gesperrt wird, stellt die Granularität der Sperre an.

Dauer
Der Zeitraum, für den eine Sperre aktiv ist. Die Dauer der Sperren wird durch Isolationsstufen beeinflußt, die in Gemeinsamer Zugriff beschrieben werden.

In der folgenden Tabelle werden Modi und ihre Auswirkungen in der Reihenfolge zunehmender Ressourcenbeschränkung angegeben:

Tabelle 38. Zusammenfassung der Sperrmodi
Sperrmodus Gültige Objektart Beschreibung
IN (Intent None) Tabellenbereiche, Tabellen Der Sperreneigner kann alle Daten in der Tabelle lesen, einschließlich der nicht festgeschriebenen Daten, aber er kann keine Daten aktualisieren. Vom Sperreneigner werden keine Zeilensperren aktiviert. Andere, gleichzeitig ausgeführte Anwendungen können die Tabelle lesen oder aktualisieren.
IS (Intent Share) Tabellenbereiche, Tabellen Der Sperreneigner kann die Daten in der gesperrten Tabelle lesen, aber nicht aktualisieren. Wenn für eine Anwendung der Modus IS der Tabellensperre aktiv ist, aktiviert die Anwendung eine Sperre des Modus S oder NS für jede gelesene Zeile. In beiden Fällen können andere Anwendungen die Tabelle lesen oder aktualisieren.
NS (Next Key Share) Zeilen Der Sperreneigner und jede gleichzeitig ausgeführte Anwendung kann die gesperrten Zeilen lesen, aber nicht aktualisieren. Diese Sperre wird anstatt einer Sperre im Modus S für Zeilen einer Tabelle aktiviert, bei der die Isolationsstufe für gelesene Daten RS oder CS ist.
S (Share) Zeilen, Tabellen Der Sperreneigner und jede gleichzeitig ausgeführte Anwendung kann die gesperrten Daten lesen, aber nicht aktualisieren. Einzelne Zeilen einer Tabelle können mit einer Sperre im Modus S versehen werden. Wenn eine Tabelle mit einer solchen Sperre im Modus S versehen ist, sind keine Zeilensperren notwendig.
IX (Intent Exclusive) Tabellenbereiche, Tabellen Der Sperreneigner und gleichzeitig ausgeführte Anwendungen können Daten in der Tabelle lesen und aktualisieren. Wenn der Sperreneigner Daten liest, wird für jede gelesene Zeile ein Sperre im Modus S, NS, X oder U aktiviert. Daneben wird für alle Zeiten, die der Sperreneigner aktualisiert, eine Sperre im Modus X aktiviert. Andere, gleichzeitig ausgeführte Anwendungen können die Tabelle sowohl lesen als auch aktualisieren.
SIX (Share with Intent Exclusive) Tabellen Der Sperreneigner kann Daten in der Tabelle lesen und aktualisieren. Für den Sperreneigner werden Sperren im Modus X für die Zeilen aktiviert, die er aktualisiert, aber keine Sperren für die Zeilen, die er liest. Andere, gleichzeitig ausgeführte Anwendungen können die Tabelle lesen.
U (Update) Zeilen, Tabellen Der Sperreneigner kann Daten in der gesperrten Zeile oder Tabelle aktualisieren. Für den Sperreneigner werden Sperren im Modus X für die Zeilen aktiviert, bevor diese aktualisiert werden. Andere Arbeitseinheiten können die Daten lesen, aber nicht versuchen, sie zu aktualisieren.
NX (Next Key Exclusive) Zeilen Der Sperreneigner kann die gesperrte Zeile lesen, aber nicht aktualisieren. Dieser Modus entspricht einer Sperre im Modus X, die jedoch mit einer Sperre im Modus NS kompatibel ist.
NW (Next Key Weak Exclusive) Zeilen Diese Sperre wird für die nächste Zeile aktiviert, wenn eine Zeile in den Index einer Nicht-Katalog-Tabelle eingefügt wird.a Der Sperreneigner kann die gesperrte Zeile lesen, aber nicht aktualisieren. Dieser Modus entspricht einer Sperre im Modus X, die jedoch mit den Sperren im Modus W und NS kompatibel ist.
X (Exclusive) Zeilen, Tabellen Der Sperreneigner kann Daten in der gesperrten Zeile oder Tabelle lesen und auch aktualisieren. Mit dem Modus Exclusive können Tabellen gesperrt werden, d. h., für Zeilen in diesen Tabellen werden keine Zeilensperren aktiviert. Nur Anwendungen mit der Isolationsstufe UR (Nicht festgeschriebener Lesevorgang) können auf die gesperrte Tabelle zugreifen.
W (Weak Exclusive) Zeilen Diese Sperre wird für die Zeile aktiviert, wenn eine Zeile in eine Nicht-Katalog-Tabelle eingefügt wird. Der Sperreneigner kann die gesperrte Zeile ändern. Diese Sperre entspricht einer Sperre im Modus X, die jedoch mit der Sperre im Modus NW kompatibel ist. Nur Anwendungen mit der Isolationsstufe UR (Nicht festgeschriebener Lesevorgang) können auf die gesperrte Zeile zugreifen.
Z (Superxclusive) Tabellenbereiche, Tabellen Diese Sperre wird für eine Tabelle unter bestimmten Umständen aktiviert, zum Beispiel, wenn die Tabelle geändert (ALTER) oder gelöscht (DROP) wird, ein Index für die Tabelle erstellt oder gelöscht wird oder eine Tabelle reorganisiert wird. Keine anderen, gleichzeitig ausgeführten Anwendungen können die Tabelle lesen oder aktualisieren.
Anmerkung:Nur für Tabellen und Tabellenbereiche werden die Sperren in den "Intent-Modi" aktiviert. Das heißt, für Zeilen werden "Intent-Sperren" nicht aktiviert.

Sperren und die Leistung von Anwendungen

Anwendungsprogrammierer sollten sich über einige Faktoren hinsichtlich der Verwendung von Sperren und ihrer Auswirkungen auf die Leistung von Anwendungen im klaren sein. Zu diesen Faktoren zählen die folgenden:

Gemeinsamer Zugriff und Granularität

Eine Sperre, die für eine Anwendung aktiv ist, kann den Zugriff durch eine andere Anwendung verhindern. Daher ist zur Erhaltung eines möglichst hohen Grades des gemeinsamen Zugriffs eine Sperre auf Zeilenebene besser als eine auf Tabellenebene. Jedoch werden für Sperren Speicher und Verarbeitungszeit zur Verwaltung benötigt. Daher ist zur Minimierung der benötigten Speicherressourcen und der Verarbeitungszeit eine einzige Sperre auf Tabellenebene besser als eine große Anzahl von Zeilensperren.

Sie können die Größe (Granularität) von Sperren auf Zeilen- oder Tabellenebene mit der Klausel LOCKSIZE der Anweisung ALTER TABLE definieren. Standardmäßig werden Zeilensperren verwendet. Bei permanenten Tabellensperren, wie durch ALTER TABLE definiert, werden nur S- und X-Tabellensperren verwendet. Der Durchsatz wird gesteigert, weil die Anwendung nicht so viele Zeilensperren aktivieren und freigeben muß. In den folgenden Fällen ist eine permanente Tabellensperre durch die Anweisung ALTER TABLE anstelle einer Tabellensperre für eine einzelne Transaktion durch die Anweisung LOCK TABLE vorzuziehen:

Die Verwendung der Anweisung ALTER TABLE verhindert normale Sperreneskalation nicht.

Beachten Sie zudem, daß das Aktivieren von Sperren auf Tabellenebene durch ALTER TABLE eine globale Vorgehensweise ist, die sich auf alle Anwendungen und Benutzer auswirkt, die auf diese Tabelle zugreifen. Alternativ können die einzelnen Anwendungen die Anweisung LOCK TABLE verwenden. Dies ermöglicht Ihnen den Aufruf von Tabellensperren auf Anwendungsebene, nicht auf Datenbankebene (wie im zweiten Punkt oben erwähnt).

Sperrenkompatibilität

Tabelle 39 zeigt, ob eine Sperrenanforderung erfüllt wird, wenn ein anderer Prozeß für dieselbe Ressource bereits eine Sperre aktiviert hat oder anfordert. Ein Nein bedeutet, daß der Anforderer warten muß, bis alle inkompatiblen Sperren von anderen Prozessen inaktiviert werden. Beachten Sie, daß es zu einer Zeitlimitüberschreitung beim Warten auf eine Sperre kommen kann. Ein Ja bedeutet, daß die Sperre aktiviert wird (es sei denn, ein anderer Benutzer wartet auf die Ressource).

Tabelle 39. Kompatibilität der Sperrmodi

Status der aktiven Sperre
Angeforderter Status NONE IN IS NS S IX SIX U NX X Z NW W
NONE Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja
IN Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
IS Ja Ja Ja Ja Ja Ja Ja Ja Nein Nein Nein Nein Nein
NS Ja Ja Ja Ja Ja Nein Nein Ja Ja Nein Nein Ja Nein
S Ja Ja Ja Ja Ja Nein Nein Ja Nein Nein Nein Nein Nein
IX Ja Ja Ja Nein Nein Ja Nein Nein Nein Nein Nein Nein Nein
SIX Ja Ja Ja Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
U Ja Ja Ja Ja Ja Nein Nein Nein Nein Nein Nein Nein Nein
NX Ja Ja Nein Ja Nein Nein Nein Nein Nein Nein Nein Nein Nein
X Ja Ja Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
Z Ja Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
NW Ja Ja Nein Ja Nein Nein Nein Nein Nein Nein Nein Nein Ja
W Ja Ja Nein Nein Nein Nein Nein Nein Nein Nein Nein Ja Nein
Abkürzungen:
I
Intent
N
None
NS
Next Key Share
S
Share
NX
Next Key Exclusive
X
Exclusive
U
Update
Z
Super Exclusive
NW
Next Key Weak Exclusive
W
Weak Exclusive

Einzelheiten zu diesen Sperrenarten finden Sie in der Beschreibung der Attribute von Sperren.

Legende:
  • Ja - angeforderte Sperre sofort erteilen
  • Nein - warten, bis aktive Sperre freigegeben oder Zeitlimit überschritten wird

Nehmen Sie an, daß für die Anwendung A eine Sperre für eine Tabelle aktiv ist, auf die die Anwendung B ebenfalls zugreifen möchte. Der Datenbankmanager fordert für die Anwendung B eine Sperre eines bestimmten Modus an. Wenn der Modus der für A aktiven Sperre die für B angeforderte Sperre zuläßt, werden diese beiden Sperren (bzw. Modi) als kompatibel bezeichnet.

Wenn der für Anwendung B angeforderte Sperrmodus nicht mit der für Anwendung A aktiven Sperre kompatibel ist, kann Anwendung B nicht fortgesetzt werden. Statt dessen muß Anwendung B warten, bis Anwendung A die Sperre freigegeben hat und bis alle weiteren bestehenden inkompatiblen Sperren freigegeben wurden.

Sperrenumwandlung

Die Sperrenumwandlung erfolgt, wenn ein Prozeß auf ein Datenobjekt zugreift, für das er bereits eine Sperre aktiviert hat, und der Zugriffsmodus eine noch stärker begrenzende Sperre erfordert. Für einen Prozeß kann immer nur eine Sperre für ein Datenobjekt aktiv sein, obwohl er mehrfach eine Sperre für dasselbe Datenobjekt (indirekt durch eine Abfrage) anfordern kann. Das Ändern des Modus einer bereits bestehenden Sperre wird als Umwandlung bezeichnet.

Die Sperrenumwandlung im Fall von Zeilensperren ist einfach: Eine Umwandlung findet beispielsweise nur statt, wenn eine Sperre des Modus X benötigt wird und eine Sperre des Modus S oder U bereits aktiv ist.

Für Tabellen und Zeilen gibt es verschiedene Sperrmodi. Sperren der Modi IX (Intent Exclusive) und S (Shared) stellen jedoch in bezug auf Sperrenumwandlung einen Sonderfall dar. Weder der Modus S noch der Modus IX wird als stärker einschränkend angesehen als der jeweils andere Modus, d. h. wenn einer dieser Modi aktiv ist und der andere benötigt wird, erfolgt die Sperrenumwandlung in den Modus SIX (Share with Intent Exclusive). Alle anderen Umwandlungen werden so ausgeführt, daß der angeforderte Sperrmodus zum Modus der aktiven Sperre wird, wenn der angeforderte Modus einen niedrigeren Grad der Einschränkung bewirkt.

Eine Abfrage zur Aktualisierung einer Zeile kann auch zu einer doppelten Umwandlung führen. Nehmen Sie an, die Zeile wurde mit Hilfe eines Indexzugriffs gelesen und im Modus S gesperrt. Die Tabelle mit der Zeile besäße eine Intent-Tabellensperre. Nehmen Sie an, daß dies eine Sperre im Modus IS und nicht im Modus IX ist. Wenn in diesem Fall die Zeile geändert wird, wird die Tabellensperre in den Modus IX und die Zeilensperre in den Modus X umgewandelt.

Beachten Sie, daß die Aktivierung von Sperren in der Regel implizit während der Ausführung einer Abfrage stattfindet. Das Verständnis der verschiedenen Arten von Sperren für verschiedene Abfragen sowie Tabellen- und Indexkombinationen kann beim Entwurf und bei der Optimierung von Anwendungen sehr hilfreich sein. Weitere Informationen zu diesem Thema finden Sie in Faktoren mit Auswirkung auf Sperren.

Sperreneskalation

Sperreneskalation ist ein interner Mechanismus zur Verringerung der Anzahl der aktivierten Sperren. Eskaliert wird von vielen Zeilensperren (in einer einzigen Tabelle) auf eine einzige Tabellensperre.

Eine Sperreneskalation tritt auf, wenn zu viele Sperren (unabhängig von der Art der Sperren) zu einem Zeitpunkt aktiv sind.

Eine Sperreneskalation kann für einen bestimmten Datenbankagenten auftreten, wenn der Agent die Zuordnung der Sperrenliste überschreitet (siehe Maximale Anzahl Sperren pro Anwendung (maxlocks)).

Eine Sperreneskalation wird intern durchgeführt. Das einzige, extern bemerkbare Ergebnis könnte sein, daß der gemeinsame Zugriff auf eine oder mehrere Tabellen eingeschränkt wird. In einer zweckmäßig konfigurierten Datenbank tritt die Sperreneskalation in der Regel recht selten auf.

Eine Sperreneskalation kann beispielsweise auftreten, wenn ein Anwendungsprogrammierer einen Index für eine sehr umfangreiche Tabelle verwendet, um die Leistung und den gemeinsamen Zugriff zu verbessern, aber die Anwendung auf einen großen Prozentsatz der Datensätze in der Tabelle zugreift. Der Datenbankmanager kann (in diesem Fall) nicht vorausberechnen, daß die Tabelle in einem solchen Ausmaß gesperrt wird, und sperrt daher jeden Datensatz einzeln, anstatt die Tabelle mit dem Modus S oder X zu sperren. Als Lösung für diesen Fall kann der Datenbankentwickler nach Absprache mit dem Anwendungsprogrammierer empfehlen, für diese Transaktion eine Anweisung LOCK TABLE zu verwenden.

Es kann vorkommen, daß der Prozeß, der die Eskalationsanforderung erhält (intern), wenig oder gar keine Datensätze in irgendeiner Tabelle gesperrt hat. Der Grund für diese Eskalation ist, daß ein Prozeß (oder Prozesse) mehrere Sperren aktiviert haben kann (obwohl diese Anzahl unter dem Wert des Konfigurationsparameters für Sperren pro Prozeß der Datenbank liegt), aber die Anzahl nicht ausreicht, um die Eskalationsanforderung auszulösen. Der Prozeß fordert eventuell keine weitere Sperre an oder greift auf die Datenbank nur zu, um die Transaktion zu beenden. Wenn in diesem Fall ein anderer Prozeß eine Sperre oder Sperren anfordert, können diese Sperren die Eskalationsanforderung auslösen.

Wenn die Sperreneskalation den gemeinsamen Zugriff auf ein nicht akzeptables Maß reduziert, können Sie folgendes ausführen:

Warten auf Sperren und Zeitlimits

Ohne Überwachung eines Zeitlimits für Sperren muß eine Anwendung in abnormalen Situationen möglicherweise unbegrenzt darauf warten, daß eine Sperre wieder freigegeben wird. Dies kann zum Beispiel geschehen, wenn eine Transaktion auf eine Sperre wartet, die für die Anwendung eines anderen Benutzers aktiviert wurde, und dieser andere Benutzer seinen Arbeitsplatz verlassen hat, ohne seine Anwendung durch weitere Eingaben die durchgeführten Transaktionen festschreiben und dadurch die Sperre freigeben zu lassen. Dies führt natürlich zu einer Beeinträchtigung der Anwendung. Um diese Blockierung des Programms in einem solchen Fall zu vermeiden, kann der Konfigurationsparameter locktimeout zur Einstellung der maximalen Zeitdauer, die eine Anwendung auf eine Sperre wartet, verwendet werden. (Siehe Zeitlimit für Sperren (locktimeout).)

Mit Hilfe dieses Parameters können globale gegenseitige Sperren besser vermieden werden, besonders in Anwendungen mit verteilten Arbeitseinheiten (DUOW). Wenn das Zeitlimit für die Sperre überschritten wird, das heißt, wenn die Zeit, die die Sperrenanforderung bereits ansteht, größer ist als der Wert des Parameters locktimeout, empfängt die Anwendung einen Fehler und die Transaktion wird rückgängig gemacht. Wenn zum Beispiel Programm 1 versucht, eine Sperre zu erhalten, die bereits für Programm 2 aktiv ist, liefert Programm 1 den SQLCODE -911 (SQLSTATE 40001) mit dem Ursachencode 68 zurück, wenn das Zeitlimit abgelaufen ist.

Wenn der Konfigurationsparameter des Datenbankmanagers diaglevel auf vier gesetzt ist und das Zeitlimit für eine Sperrenanforderung überschritten wird, sind in der Datei "db2diag.log" weitere Informationen enthalten. Die Informationen darin umfassen das Objekt, den Sperrmodus und die Anwendung, die die Sperre für das Objekt aktiviert. Der Name der aktuellen dynamischen SQL-Anweisung oder des statischen Pakets kann auch darin enthalten sein.

Gegenseitige Sperren

Im Datenbankmanager können Konkurrenzsituationen bei der Anforderung von Sperren für Prozesse, die die Datenbank verwenden, zu gegenseitigen Sperren führen. Zum Beispiel sperrt der Prozeß 1 die Tabelle A im Modus X (Exclusive), und Prozeß 2 sperrt die Tabelle B im Modus X. Wenn nun der Prozeß 1 versucht, die Tabelle B im Modus X zu sperren, und Prozeß 2 versucht, die Tabelle A im Modus X zu sperren, sperren sich die Prozesse gegenseitig. Bei einer gegenseitigen Sperre sind beide Prozesse so lange blockiert, bis die jeweils zweite Sperrenanforderung erfüllt wird, und keine der beiden Anforderungen wird ausgeführt, sofern nicht einer der Prozesse eine COMMIT- oder ROLLBACK-Operation ausführt. Dieser Zustand dauert an, bis ein externer Agent einen der Prozesse aktiviert und dazu zwingt, eine ROLLBACK-Operation auszuführen.

Gegenseitige Sperren im Sperrensystem werden im Datenbankmanager von einem asynchronen Hintergrundprozeß des Systems, dem Detektor für gegenseitiges Sperren, behandelt. Der Detektor für gegenseitiges Sperren wird regelmäßig in den vom Konfigurationsparameter dlchktime bestimmten Abständen aktiv (siehe Intervall für Prüfung gegenseitiger Sperren (dlchktime)). Wenn der Detektor für gegenseitiges Sperren aktiv wird, wird das Sperrensystem auf gegenseitige Sperren hin untersucht. Wenn die Datenbank partitioniert ist, sendet jede Partition Sperrendiagramme an die Datenbankpartition, die über die Systemkatalogsichten verfügt und in der die globale Erkennung gegenseitiger Sperren stattfindet.

Wenn eine gegenseitige Sperre erkannt wird, wählt der Detektor für gegenseitiges Sperren einen durch diese Sperre blockierten Prozeß aus, um ihn rückgängig machen zu lassen. Der ausgewählte Prozeß wird wieder aktiviert und kehrt zur aufrufenden Anwendung mit dem SQLCODE -911 (SQLSTATE 40001) und dem Ursachencode 2 zurück. Der Datenbankmanager setzt den ausgewählten Prozeß automatisch zurück. Wenn die ROLLBACK-Operation beendet ist, werden die Sperren, die zu dem ausgewählten Prozeß gehörten, freigegeben, und die anderen Prozesse, die ebenfalls in der gegenseitigen Sperre blockiert waren, können die Verarbeitung fortsetzen.

Die Auswahl eines geeigneten Intervalls für den Detektor für gegenseitiges Sperren ist wesentlich, um eine gute Leistung zu gewährleisten. Ein zu kurzes Intervall würde einen unnötigen Systemaufwand verursachen, ein zu langes Intervall würde die Verzögerung eines Prozesses durch eine gegenseitige Sperre auf ein nicht tolerierbares Maß erhöhen. Zum Beispiel könnte ein Aktivierungsintervall von 30 Minuten zulassen, daß eine gegenseitige Sperre über annähernd 30 Minuten bestehen kann. Der Anwendungsentwickler muß den geeigneten Mittelweg zwischen den möglichen Verzögerungen bei der Auflösung gegenseitiger Sperren und dem Systemaufwand für die Erkennung dieser Sperren finden.

In einer partitionierten Datenbank sollte das Intervall für alle Partitionen gleich sein (der Konfigurationsparameter dlchktime muß auf allen Partitionen auf den gleichen Wert aktualisiert werden). Ist der Wert auf dem Katalogknoten kleiner als in anderen Partitionen, werden möglicherweise scheinbare gegenseitige Sperren festgestellt. Ist der Wert auf dem Katalogknoten größer als auf anderen Partitionen, können scheinbar mehr als zwei Intervalle vergehen, bis eine gegenseitige Sperre festgestellt wird. Werden in einer partitionierten Datenbank zahlreiche gegenseitige Sperren festgestellt, sollten Sie den Wert des Parameters dlchktime erhöhen, um Wartezeiten für Sperren und für die Übertragung zu berücksichtigen.

Ein anderes Problem kann auftreten, wenn eine Anwendung mit mehr als einem unabhängigen Prozeß, der auf die Datenbank zugreift, so strukturiert ist, daß die Entstehung gegenseitiger Sperren wahrscheinlich ist. Ein Beispiel wäre eine Anwendung, in der mehrere Prozesse auf dieselbe Tabelle zuerst zu Leseoperationen und anschließend zu Schreiboperationen zugreifen. Wenn die Prozesse zuerst SQL-Abfragen im Lesezugriff durchführen und anschließend SQL-Aktualisierungsanweisungen für dieselbe Tabelle verarbeiten, steigt die Wahrscheinlichkeit gegenseitiger Sperren, weil es zwischen den Prozessen zu Konkurrenzsituationen beim Zugriff auf dieselben Daten kommen kann. Wenn zum Beispiel zwei Prozesse die Tabelle lesen und anschließend aktualisieren, können sie in eine Situation geraten, in der Prozeß A versucht, eine Sperre des Modus X für eine Zeile zu erhalten, für die Prozeß B eine Sperre des Modus S hat, und umgekehrt. Daraus kann sich eine gegenseitige Sperre ergeben. Zur Vermeidung dieser gegenseitigen Sperren, sollten Anwendungen, die auf Daten zugreifen, um diese zu ändern, beim Auswählen die Klausel FOR UPDATE OF verwenden. Durch diese Klausel wird sichergestellt, daß eine Sperre des Modus U aktiviert wird, wenn der Prozeß A versucht, die Daten zu lesen.
Anmerkung:Erwägen Sie das Definieren einer Überwachung, die das Auftreten gegenseitiger Sperren aufzeichnet. Erstellen Sie die Überwachung mit der im Handbuch SQL Reference beschriebenen Anweisung CREATE EVENT.

In einer Systemumgebung mit zusammengeschlossenen Datenbanken kann es beim Zugriff einer Anwendung auf Kurznamen sein, daß die von der Anwendung angeforderten Daten nicht verfügbar sind, weil es an einer Datenquelle zu gegenseitigen Sperren gekommen ist. In diesem Fall ist DB2 davon abhängig, daß die Einrichtungen zur Behandlung gegenseitiger Sperren an der Datenquelle die gegenseitige Sperrung auflösen. Fall es an mehreren Datenquellen zu gegenseitigen Sperren gekommen ist, ist DB2 für das Aufheben der gegenseitigen Sperren auf die Zeitlimitmechanismen der Datenquellen angewiesen.

Wenn der Konfigurationsparameter des Datenbankmanagers diaglevel auf vier gesetzt ist und eine Sperrenanforderung wegen einer gegenseitigen Sperre fehlschlägt, sind in der Datei "db2diag.log" weitere Informationen enthalten. Die Informationen darin umfassen das Objekt, den Sperrmodus und die Anwendung, die die Sperre für das Objekt aktiviert. Der Name der aktuellen dynamischen SQL-Anweisung oder des statischen Pakets kann auch darin enthalten sein.

Faktoren mit Auswirkung auf Sperren

Der Modus und die Unterteilung (Granularität) der Sperren des Datenbankmanagers werden durch eine Kombination von Faktoren bestimmt: die Art der Verarbeitung, die eine Anwendung durchführt, die Art des Zugriffs auf Daten und verschiedene Parameter, die Sie angeben.

Anwendungsverarbeitung

Zur Feststellung der Sperrenattribute kann die Verarbeitung einer der folgenden vier Kategorien zugeordnet werden:

Lesezugriff
Dieser Typ beinhaltet alle SELECT-Anweisungen, die an sich nur Lesezugriff haben (Informationen zu Cursorn finden Sie in SQL Reference), über eine explizite Klausel FOR READ ONLY verfügen, oder mehrdeutig sind, die vom SQL-Compiler jedoch aufgrund der im Befehl PREP oder BIND angegebenen Option BLOCKING für Anweisungen mit Lesezugriff gehalten werden. Für diesen Typ sind nur Sperren des Modus Share (S bzw. IS) erforderlich.

Änderungsabsicht
Dieser Typ umfaßt alle Anweisungen SELECT mit der Klausel FOR UPDATE oder Anweisungen SELECT, bei denen der SQL-Compiler als Ergebnis der Interpretation der mehrdeutigen Anweisung annimmt, daß sie zum Zweck der Änderung von Daten ausgeführt werden. Für diesen Typ werden Sperren der Modi Share und Update (S, U und X für Zeilen sowie IX, U und X für Tabellen) verwendet.

Änderung
Dieser Typ umfaßt Anweisungen UPDATE, INSERT und DELETE, aber keine Anweisungen UPDATE WHERE CURRENT OF oder DELETE WHERE CURRENT OF. Für diesen Typ sind Sperren des Modus Exclusive (X oder IX) erforderlich.

Cursorgesteuert
Dieser Typ umfaßt die Anweisungen UPDATE WHERE CURRENT OF und DELETE WHERE CURRENT OF. Für diesen Typ sind ebenfalls Sperren des Modus Exclusive (X oder IX) erforderlich.

Eine Anweisung, die an einer Zieltabelle Einfüge-, Aktualisierungs- oder Löschoperationen (INSERT, UPDATE oder DELETE) auf der Grundlage des Ergebnisses einer Unterauswahl vornimmt, führt zwei Typen der Verarbeitung aus. Die Sperren für die Tabellen, die durch die Unterauswahl geliefert werden, werden durch die Regeln für den Typ Lesezugriff bestimmt, die Sperren für die Zieltabelle durch die Regeln für den Typ Änderung.

Zugriffspfade

Ein Zugriffspfad ist die Methode, die das Optimierungsprogramm auswählt, um Daten aufgrund eines bestimmten Tabellenverweises abzurufen. (Siehe Datenzugriffskonzepte und Optimierung.) Der vom Optimierungsprogramm gewählte Zugriffspfad kann bedeutende Auswirkungen auf die Sperrmodi haben. Wenn zum Beispiel eine Indexsuche zum Auffinden einer bestimmten Zeile verwendet wird, wählt das Optimierungsprogramm sehr wahrscheinlich Sperren auf Zeilenebene (IS) für die Tabelle aus. Mit dieser Zugriffsart können mit einer Anweisung wie der folgenden Informationen für einen bestimmten Mitarbeiter aus der Tabelle EMPLOYEE ausgewählt werden, die einen Index für die Personalnummer (EMPNO) hat:

     SELECT *
       FROM EMPLOYEE
       WHERE EMPNO = '000310';

Wenn kein Index verwendet wird, muß die gesamte Tabelle der Reihe nach durchsucht werden, um die ausgewählten Zeilen zu finden. Dafür ist möglicherweise eine einzige Sperre auf Tabellenebene (S) erforderlich. Mit dieser Zugriffsart könnten zum Beispiel mit einer Anweisung wie der folgenden alle männlichen Mitarbeiter ausgewählt werden, wobei es für die Spalte SEX keinen Index gibt:

     SELECT *
       FROM EMPLOYEE
       WHERE SEX = 'M';

Die folgenden Tabellen enthalten eine Übersicht, welche Sperren für welche Art des Zugriffs aktiviert werden. Definitionen der Spaltenüberschriften finden Sie in Anwendungsverarbeitung. Definitionen der Zugriffsmethode finden Sie auch in Datenzugriffskonzepte und Optimierung. Beachten Sie, daß der Verarbeitungstyp Cursorgesteuert den Sperrmodus des zugrundeliegenden Cursors verwendet, bis die Anwendung eine Zeile findet, die zu aktualisieren oder zu löschen ist. Für diesen Typ der Verarbeitung wird unabhängig vom Sperrmodus eines Cursors immer eine Sperre des Modus Exclusive aktiviert, um die Aktualisierung oder Löschung durchzuführen.

Für die nachfolgenden Tabellen gelten folgende Konventionen: Wenn nur ein Sperrmodus aufgeführt ist, ist dies ein Sperrmodus auf Tabellenebene. Wenn zwei Sperrmodi aufgeführt sind, ist der erste der Sperrmodus auf Tabellenebene und der zweite der Sperrmodus auf Zeilenebene.

Tabelle 40. Sperrmodi für Tabellensuchen
Isolationsstufe Lesezugriff Änderungsabsicht Änderung
Zugriffsmethode: Tabellensuche ohne Vergleichselemente
RR S U X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X 
Zugriffsmethode: Tabellensuche mit Vergleichselementen
RR S U U
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

Tabelle 41. Sperrmodi für Indexsuchen
Isolationsstufe Lesezugriff Änderungsabsicht Änderung
Zugriffsmethode: Indexsuche ohne Vergleichselemente
RR S IX / U X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X 
Zugriffsmethode: Indexsuche nach einer zu findenden Zeile
RR IS / S IX / U IX / X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X 
Zugriffsmethode: Indexsuche nur mit Start- und Stoppvergleichselementen
RR IS / S IX / S IX / X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X 
Zugriffsmethode: Indexsuche mit Vergleichselementen
RR IS / S IX / S IX / U
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

Tabelle 42 zeigt die Sperrmodi für Fälle, in denen der Lesezugriff auf die Datenseiten verzögert erfolgt, um in der Zeilenliste folgendes zu ermöglichen:

Beim verzögerten Zugriff auf die Datenseiten erfolgt der Zugriff auf die Zeile in zwei Schritten, wodurch komplexere Sperrsituationen auftreten. Es gibt zwei Hauptkategorien, die von der Isolationsstufe abhängen. Da bei der Isolationsstufe RR (Wiederholtes Lesen) alle Sperren bis zum Ende der Transaktion aktiviert bleiben, bleiben die im ersten Schritt aktivierten Sperren weiterhin gültig, und im zweiten Schritt müssen keine weiteren Sperren aktiviert werden. Für die Isolationsstufen Lese- und Cursorstabilität müssen Sperren im zweiten Schritt aktiviert werden. Um den gemeinsamen Zugriff zu maximieren, werden im ersten Schritt keine Sperren aktiviert und alle Vergleichselemente erneut angewandt, so daß nur den Auswahlkriterien entsprechende Zeilen zurückgegeben werden.

Tabelle 42. Sperrmodi für Indexsuchen bei verzögertem Zugriff auf Datenseiten
Isolationsstufe Lesezugriff Änderungsabsicht Änderung
Zugriffsmethode: Indexsuche ohne Vergleichselemente
RR IS / S IX / S X
RS IN IN IN
CS IN IN IN
UR IN IN IN
Zugriffsmethode: Verzögerter Zugriff auf Datenseiten nach Indexsuche ohne Vergleichselemente
RR IN IX / S X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X 
Zugriffsmethode: Indexsuche mit Vergleichselementen
RR IS / S IX / S IX / S
RS IN IN IN
CS IN IN IN
UR IN IN IN
Zugriffsmethode: Indexsuche nur mit Start- und Stoppvergleichselementen
RR IS / S IX / S IX / X
RS IN IN IN
CS IN IN IN
UR IN IN IN
Zugriffsmethode: Verzögerter Zugriff auf Datenseiten nach Indexsuche mit Vergleichselementen
RR IN IX / S IX / S
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

Der Zugriffspfad unterliegt nicht der Steuerung durch den Benutzer, sondern wird vom Optimierungsprogramm gewählt.

Der verwendete Zugriffspfad kann sich auf den Modus und die Granularität einer Sperre auswirken. Zum Beispiel in einer Anwendung mit der Isolationsstufe RR (Wiederholtes Lesen) würde für eine Abfrage mit UPDATE-Operationen, die über eine Tabellensuche ohne Vergleichselemente auf die Zeilen zugreift, eine Sperre des Modus X für die Tabelle verwendet. Wenn die Zeilen über einen Index lokalisiert würden, sperrt der Datenbankmanager möglicherweise eher einzelne Zeilen der Tabelle.

Deklarierte temporäre Tabellen und Sperren

Deklarierte temporäre Tabellen werden nicht gesperrt, 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.

Anweisung LOCK TABLE

Sie können die Regeln zum Anfordern anfänglicher Sperrmodi durch Verwenden der Anweisung LOCK TABLE in einer Anwendung außer Kraft setzen.

Diese Anweisung sperrt eine ganze Tabelle. Es wird nur die in der Anweisung LOCK TABLE angegebene Tabelle gesperrt. Übergeordnete und abhängige Tabellen der angegebenen Tabelle werden nicht gesperrt. Sie müssen selbst entscheiden, ob das Sperren anderer Tabellen, auf die möglicherweise zugegriffen wird, erforderlich ist, um das gewünschte Ergebnis hinsichtlich des gemeinsamen Zugriffs und der Leistung zu erzielen. Die Sperre wird erst freigegeben, wenn die Arbeitseinheit festgeschrieben oder rückgängig gemacht wurde.

Wenn eine Tabelle normalerweise von mehreren Benutzern gemeinsam benutzt wird, könnten Sie sie z. B. aus folgenden Gründen sperren:

LOCK TABLE IN SHARE MODE
Sie wollen auf Daten zugreifen, die zeitlich konsistent sind, d. h. Daten, die für eine Tabelle zu einem bestimmten Zeitpunkt aktuell sind. Wenn auf die Tabelle häufig zugegriffen wird, liegt die einzige Möglichkeit, die Tabelle in einem stabilen Zustand zu erhalten, darin, die Tabelle zu sperren. Die Anwendung soll zum Beispiel eine Momentaufnahme der Tabelle machen. Aber während der Zeit, die die Anwendung zur Verarbeitung einiger Zeilen der Tabelle benötigt, aktualisieren andere Anwendungen Zeilen, die die Anwendung noch nicht verarbeitet hat. Dies ist unter der Isolationsstufe RR (Wiederholtes Lesen) zulässig, jedoch nicht beabsichtigt.

Als alternative Methode kann Ihre Anwendung die Anweisung LOCK TABLE IN SHARE MODE absetzen: Es können keine Zeilen geändert werden, egal ob sie von Ihnen abgerufen wurden oder nicht. Anschließend kann die Anwendung die benötigte Anzahl von Zeilen abrufen und gleichzeitig davon ausgehen, daß die abgerufenen Zeilen nicht kurz vor dem Abrufen geändert wurden.

Nach Ausführung der Anweisung LOCK TABLE IN SHARE MODE können andere Benutzer Daten aus der Tabelle abrufen, aber sie können keine Zeilen in der Tabelle aktualisieren, löschen oder einfügen.

LOCK TABLE IN EXCLUSIVE MODE
Sie beabsichtigen, einen großen Teil der Tabelle zu aktualisieren. Es ist weniger aufwendig und daher effektiver, alle anderen Benutzer vom Zugriff auf die Tabelle auszuschließen, als jede Zeile zur Aktualisierung zu sperren und anschließend die Sperren wieder freizugeben, wenn alle Änderungen festgeschrieben sind.

Durch LOCK TABLE IN EXCLUSIVE MODE werden alle anderen Benutzer ausgeschlossen, d. h. keine anderen Anwendungen können auf die Tabelle zugreifen, außer wenn es sich um Anwendungen mit der Isolationsstufe UR (für nicht festgeschriebener Lesevorgang) handelt.

Weitere Einzelheiten zur Anweisung LOCK TABLE finden Sie im Handbuch SQL Reference.

Eine Alternative zur Verwendung der Anweisung LOCK TABLE ist die Anweisung ALTER TABLE mit dem Parameter LOCKSIZE. Der Parameter LOCKSIZE ermöglicht die Auswahl von Zeilensperren oder Tabellensperren. Die vorgenommene Auswahl wird zur Granularität (Unterteilung) der gewählten Sperren beim nächsten Zugriff auf die Tabelle. Die Auswahl von Zeilensperren entspricht der Auswahl der Standardsperrenunterteilung bei der Erstellung einer Tabelle. Die Auswahl von Tabellensperren verbessert eventuell die Leistung von Abfragen durch Begrenzung der Anzahl benötigter Sperren. Der gemeinsame Zugriff wird jedoch eventuell verringert, da alle Sperren in der gesamten Tabelle aktiv sind. Die vorgenommene Auswahl verhindert jedoch nicht, daß eine normale Sperreneskalation auftreten kann. Weitere Einzelheiten zur Anweisung ALTER TABLE finden Sie im Handbuch SQL Reference.

Anweisung CLOSE CURSOR WITH RELEASE

Wenn Sie einen Cursor mit der Anweisung CLOSE CURSOR schließen, die die Klausel WITH RELEASE enthält, versucht der Datenbankmanager alle ggf. vorhandenen Lesesperren freizugeben, die für diesen Cursor aktiviert waren. Lesesperren sind Tabellensperren im Modus IS, S und U sowie Zeilensperren im Modus S, NS und U. Weitere Informationen zu den Sperrmodi finden Sie in Attribute von Sperren.

Die Klausel WITH RELEASE hat keine Auswirkung auf Cursor, die unter den Isolationsstufen CS oder UR verwendet werden. Wenn die Klausel WITH RELEASE für Cursor angegeben wird, die unter der Isolationsstufe RS oder RR verwendet werden, hebt sie einige Merkmale dieser Isolationsstufen auf. Das heißt im einzelnen, daß beim einem RS-Cursor nichtwiederholbare Lesevorgänge und bei einem RR-Cursor nichtwiederholbare Lesevorgänge oder Phantomzeilen auftreten können.

Wird ein Cursor, der ursprünglich ein RR- oder RS-Cursor ist, nachdem er mit der Klausel WITH RELEASE geschlossen wurde, erneut geöffnet, werden neue Lesesperren aktiviert.

Einen Vergleich zur anderen primären Klausel der Anweisung CLOSE CURSOR finden Sie im Abschnitt Anweisung DECLARE CURSOR WITH HOLD.

Durch die Verwendung des DB2-CLI-Verbindungsattributs SQL_ATTR_CLOSE_BEHAVIOR in CLI-Anwendungen können Sie die gleichen Ergebnisse erzielen. Weitere Informationen hierzu finden Sie im Abschnitt SQLSetConnectAttr() des Handbuchs CLI Guide and Reference.

Zusammenfassung der Überlegungen zu Sperren

Beachten Sie bitte im Hinblick auf Sperren folgende Punkte:


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