Hierarchische Sperrgranulate

Bisher wurden alle Sperren auf derselben $Granularit\uml {a}t$ erworben. Mögliche Sperrgranulate sind:

• Datensatz $\widehat{=}$ Tupel
• Seite $\widehat{=}$ Block im Hintergrundspeicher
• Segment $\widehat{=}$ Zusammenfassung von Seiten
• Datenbasis $\widehat{=}$ gesamter Datenbestand

Abbildung 13.5 zeigt die hierarchische Anordnung der möglichen Sperrgranulate.

Abbildung 13.5: Hierarchie der Sperrgranulate

Eine Vermischung von Sperrgranulaten hätte folgende Auswirkung. Bei Anforderung einer Sperre für eine Speichereinheit, z.B. ein Segment, müssen alle darunterliegenden Seiten und Sätze auf eventuelle Sperren überprüft werden. Dies bedeutet einen immensen Suchaufwand. Auf der anderen Seite hätte die Beschränkung auf nur eine Sperrgranularität folgende Nachteile:

• Bei zu kleiner Granularität werden Transaktionen mit hohem Datenzugriff stark belastet.
• Bei zu großer Granularität wird der Parallelitätsgrad unnötig eingeschränkt.

Die Lösung des Problems besteht im multiple granularity locking (MGL). Hierbei werden zusätzliche Intentionssperren verwendet, welche die Absicht einer weiter unten in der Hierarchie gesetzten Sperre anzeigen. Tabelle 13.13 zeigt die Kompatibilitätsmatrix. Die Sperrmodi sind:

• NL: keine Sperrung (no lock);
• S: Sperrung durch Leser,
• X: Sperrung durch Schreiber,
• IS: Lesesperre (S) weiter unten beabsichtigt,
• IX: Schreibsperre (X) weiter unten beabsichtigt.

	$NL$	$S$	$X$	$IS$	$IX$
$S$	$\surd$	$\surd$	-	$\surd$	-
$X$	$\surd$	-	-	-	-
$IS$	$\surd$	$\surd$	-	$\surd$	$\surd$
$IX$	$\surd$	-	-	$\surd$	$\surd$

Tabelle 13.13: Kompatibilitätsmatrix beim Multiple-Granularity-Locking

Die Sperrung eines Datenobjekts muß so durchgeführt werden, daß erst geeignete Sperren in allen übergeordneten Knoten in der Hierarchie erworben werden:

1. Bevor ein Knoten mit S oder IS gesperrt wird, müssen alle Vorgänger vom Sperrer im IX- oder IS-Modus gehalten werden.
2. Bevor ein Knoten mit X oder IX gesperrt wird, müssen alle Vorgänger vom Sperrer im IX-Modus gehalten werden.
3. Die Sperren werden von unten nach oben freigegeben.

Abbildung 13.6: Datenbasis-Hierarchie mit Sperren

Abbildung 13.7: Datenbasis-Hierarchie mit zwei blockierten Transaktionen

Abbildung 13.6 zeigt eine Datenbasis-Hierarchie, in der drei Transaktionen erfolgreich Sperren erworben haben:

• $T_1$ will die Seite $p_1$ zum Schreiben sperren und erwirbt zunächst IX-Sperren auf der Datenbasis D und auf Segment $a_1$.
• $T_2$ will die Seite $p_2$ zum Lesen sperren und erwirbt zunächst IS-Sperren auf der Datenbasis D und auf Segment $a_1$.
• $T_3$ will das Segment $a_2$ zum Schreiben sperren und erwirbt zunächst eine IX-Sperre auf der Datenbasis D.

Nun fordern zwei weitere Transaktionen $T_4$ (Schreiber) und $T_5$ (Leser) Sperren an:

• $T_4$ will Satz $s_3$ exklusiv sperren. Auf dem Weg dorthin erhält $T_4$ die erforderlichen IX-Sperren für $D$ und $a_1$, jedoch kann die IX-Sperre für $p_2$ nicht gewährt werden.
• $T_5$ will Satz $s_5$ zum Lesen sperren. Auf dem Weg dorthin erhält $T_5$ die erforderliche IS-Sperren nur für $D$, jedoch können die IS-Sperren für $a_2$ und $p_3$ zunächst nicht gewährt werden.

Abbildung 13.7 zeigt die Situation nach dem gerade beschriebenen Zustand. Die noch ausstehenden Sperren sind durch eine Durchstreichung gekennzeichnet. Die Transaktionen $T_4$ und $T_5$ sind blockiert, aber nicht verklemmt und müssen auf die Freigabe der Sperren $(T_2,S)$ und $T_3,X)$ warten.