Hierarchische Sperrgranulate

Bisher wurden alle Sperren auf derselben Granularitä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.

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.

Datenbasis-Hierarchie mit Sperren

Datenbasis-Hierarchie mit zwei blockierten Transaktionen

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

• T₁ will die Seite p₁ zum Schreiben sperren und erwirbt zunächst IX-Sperren auf der Datenbasis D und auf Segment a₁.
• T₂ will die Seite p₂ zum Lesen sperren und erwirbt zunächst IS-Sperren auf der Datenbasis D und auf Segment a₁.
• T₃ will das Segment a₂ zum Schreiben sperren und erwirbt zunächst eine IX-Sperre auf der Datenbasis D.

Nun fordern zwei weitere Transaktionen T₄ (Schreiber) und T₅ (Leser) Sperren an:

• T₄ will Satz s₃ exklusiv sperren. Auf dem Weg dorthin erhält T₄ die erforderlichen IX-Sperren für D und a₁, jedoch kann die IX-Sperre für p₂ nicht gewährt werden.
• T₅ will Satz s₅ zum Lesen sperren. Auf dem Weg dorthin erhält T₅ die erforderliche IS-Sperren nur für D, jedoch können die IS-Sperren für a₂ und p₃ zunächst nicht gewährt werden.

Bild 13.7 zeigt die Situation nach dem gerade beschriebenen Zustand. Die noch ausstehenden Sperren sind durch eine Durchstreichung gekennzeichnet. Die Transaktionen T₄ und T₅ sind blockiert, aber nicht verklemmt und müssen auf die Freigabe der Sperren (T₂, S) und T₃, X) warten.