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:
Sperren des Datenbankmanagers verfügen über folgende Basisattribute:
In der folgenden Tabelle werden Modi und ihre Auswirkungen in der
Reihenfolge zunehmender Ressourcenbeschränkung angegeben:
Tabelle 38. Zusammenfassung der Sperrmodi
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. |
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:
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).
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 | ||
| |||||||||||||||
|
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.
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 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:
Die aktuelle dynamische SQL-Anweisung wird eventuell auch aufgezeichnet. In diesem Fall enthalten die aufgezeichneten Informationen die aktuelle SQL-Anweisung vor der Eskalation von Tabellensperren, wenn der Konfigurationsparameter DIAGLEVEL des Datenbankmanagers auf 4 gesetzt ist. Wenn die Sperreneskalation fehlschlägt, enthalten die aufgezeichneten Informationen die Tabelle, für die die Eskalation fehlgeschlagen ist, und die aktuelle SQL-Anweisung (falls sie verfügbar ist und nicht zuvor geschrieben wurde), wenn DIAGLEVEL auf 2 oder höher gesetzt wurde.
Mit Hilfe dieser Informationen können Sie eine geeignete Aktion auf Grundlage der anderen unten erwähnten Punkte ausführen.
Sie müssen den Konfigurationsparameter DIAGLEVEL des Datenbankmanagers auf 3 (Standardwert) oder auf 4 setzen, um diese Art der Informationsaufzeichnung zu starten.
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.
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.
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.
Zur Feststellung der Sperrenattribute kann die Verarbeitung einer der folgenden vier Kategorien zugeordnet werden:
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.
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 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.
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:
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.
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.
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.
Beachten Sie bitte im Hinblick auf Sperren folgende Punkte: