Sperrkonzept in SESAM/SQL-Transaktionen

Das Sperrkonzept gewährleistet die Konsistenz der bearbeiteten Daten.

CALL-DML:	In einer Transaktion werden alle Sätze exklusiv gelesen, falls die zugehörige logische Datei mit Open-Modus „X“ eröffnet wurde und der Zusatz „readnolock“ nicht gegeben wurde. Ein shared Lesen erfolgt nur, falls die zugehörige logische Datei mit Open Modus „R“ eröffnet wurde.
SQL:	Leseoperationen erfolgen im Shared-Modus, Änderungsoperationen im Exklusiv-Modus.

Auf diese Weise sind Datenverfälschungen ausgeschlossen.

Modifikationen bei CALL-DML

Bei der Datenwiedergewinnung der CALL-DML erlaubt SESAM/SQL folgende Modifikationen des Sperrkonzepts (siehe Handbuch „ CALL-DML Anwendungen“):

• Lesen ohne zu sperren (kann zu „non-repeatable read“ führen)

• Ignorieren der exklusiven Sperre (kann zu „dirty read“ führen).

Modifikationen bei SQL

Das Sperrkonzept sowie seine Modifikationen sind bei SQL auf Isolationslevel abgebildet. Der SQL-Anwender legt für jede Transaktion explizit oder implizit einen Isolationslevel fest:

• implizit zum Übersetzungszeitpunkt bzw. durch die Konfigurationsdatei

• explizit durch die SET TRANSACTION-Anweisung oder das Pragma ISOLATION LEVEL.

Dadurch wird gleichzeitig der Grad der Transaktionsparallelität bestimmt (siehe Abschnitt „SQL-Transaktion“).

Wartezustände bei Transaktionen

Versucht eine Transaktion auf einen Satz zuzugreifen, der von einer anderen Transaktion gesperrt ist, so kann sie die Anweisung zunächst nicht ausführen: Die Transaktion wird in einen Wartezustand versetzt. Gleichzeitig wird in der Tabelle der offenen Transaktionen vermerkt, welche Transaktion die Sperre des Satzes ausgelöst hat.

Tabelle der offenen Transaktionen
Transaktion	gesperrt durch Transaktion
A
B	A
C	B
D	A

Tabelle 45: Transaktionen im Wartezustand

Die wartende Transaktion kann erst dann mit der Bearbeitung fortfahren, wenn die sperrende Transaktion abgeschlossen oder zurückgesetzt ist. Zu diesem Zweck überwacht der SESAM/SQL-DBH die wartenden Transaktionen und reaktiviert sie, wenn die sperrenden Transaktionen beendet sind.

Mit der untergeordneten DBH-Option TRANSACTION-SECURITY kann das Verhalten des DBH gegenüber sperrenden Transaktionen und das Eskalieren von Transaktionssperren beeinflusst werden. Während des laufenden Betriebs können diese Parameter mit der Administrationsanweisung MODIFY-TRANSACTION-SECURITY geändert werden (siehe Handbuch „ Datenbankbetrieb“).

Es können sich zwei Situationen ergeben, in denen eine automatische Reaktivierung nicht möglich ist bzw. unnötig lange verzögert wird: Deadlock- und Longlock-Situationen.

Deadlock-Situationen

Ein Deadlock liegt immer dann vor, wenn sich zwei oder mehrere Transaktionen gegenseitig sperren. In diesem Fall kann keine der Transaktionen abgeschlossen werden.

Mit der Administrationsanweisung SET-SESSION-DIAGNOSIS können Sie sich bei Auftreten eines Deadlock zusätzliche Informationen über die Benutzer und die betroffenen Objekte auf SYSLST ausgeben lassen, siehe Handbuch „ Datenbankbetrieb“.

Die folgende Tabelle zeigt den Deadlock von 3 Transaktionen. Dabei besteht zwischen der Art des Zugriffs und der Anzahl der E/A-Vorgänge folgender Zusammenhang: Ein Lesezugriff auf einen Datenblock entspricht einem E/A-Vorgang, ein Schreibzugriff entspricht zwei E/A-Vorgängen.

Tabelle der offenen Transaktionen
Transaktion	gesperrt durch Transaktion	E/A-Vorgänge
A	C	100
B	A	20
C	B	60
D		5

Tabelle 46: Deadlock von 3 Transaktionen

Der SESAM/SQL-DBH löst Deadlock-Situationen automatisch auf.

Jedesmal, wenn eine Transaktion gesperrt wird, prüft der SESAM/SQL-DBH, ob diese Sperre einen Deadlock auslöst.

Ist dies der Fall, setzt der SESAM/SQL-DBH die Transaktion zurück, die am Deadlock beteiligt ist und bis zu diesem Zeitpunkt die wenigsten E/A-Vorgänge hatte (in Tabelle 46 ist dies Transaktion B). Die entsperrten Transaktionen können darauf die Verarbeitung fortsetzen. In Tabelle 47 ist dies Transaktion C.

Nach Auflösen der Deadlock-Situation ergibt sich folgender aktueller Stand:

Tabelle der offenen Transaktionen
Transaktion	gesperrt durch Transaktion	E/A-Vorgänge
A	C	100
C		60
D		5

Tabelle 47: Transaktionstabelle nach Auflösen der Deadlock-Situation

Aufgrund des Rücksetzkriteriums „wenigste E/A-Vorgänge“ wird stets die Transaktion mit dem geringsten Rücksetzaufwand zurückgesetzt.

Longlock-Situationen

Der SESAM/SQL-DBH ermittelt Transaktionen, die für lange Zeit die Verarbeitung unterbrechen und Betriebsmittel für andere Transaktionen sperren. Solche Transaktionen setzt der SESAM/SQL-DBH automatisch zurück. Durch ein Rücksetzkriterium legt der Systemverwalter fest, wie lange inaktive Transaktionen andere Transaktionen sperren dürfen (LOCK-TIME-Parameter der DBH-Option TRANSACTION-SECURITY bzw. der Administrationsanweisung MODIFY-TRANSACTION-SECURITY, siehe Handbuch „ Datenbankbetrieb“).