Bisher wurden alle Sperren auf derselben
erworben. Mögliche
Sperrgranulate sind:
- Datensatz
Tupel
- Seite
Block im Hintergrundspeicher
- Segment
Zusammenfassung von Seiten
- Datenbasis
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.
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:
- Bevor ein Knoten mit S oder IS gesperrt wird, müssen
alle Vorgänger vom Sperrer im IX- oder IS-Modus
gehalten werden.
- Bevor ein Knoten mit X oder IX gesperrt wird, müssen
alle Vorgänger vom Sperrer im IX-Modus
gehalten werden.
- 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:
will die Seite
zum Schreiben sperren und erwirbt zunächst
IX-Sperren auf der Datenbasis D und auf Segment
.
will die Seite
zum Lesen sperren und erwirbt
zunächst IS-Sperren auf der Datenbasis D und auf
Segment
.
will das Segment
zum Schreiben sperren und erwirbt
zunächst eine IX-Sperre auf der Datenbasis D.
Nun fordern zwei weitere Transaktionen
(Schreiber) und
(Leser)
Sperren an:
will Satz
exklusiv sperren. Auf dem Weg dorthin erhält
die erforderlichen IX-Sperren für
und
,
jedoch kann die IX-Sperre für
nicht gewährt werden.
will Satz
zum Lesen sperren. Auf dem Weg dorthin erhält
die erforderliche IS-Sperren nur für
,
jedoch können die IS-Sperren für
und
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
und
sind blockiert, aber nicht verklemmt
und müssen auf die Freigabe der Sperren
und
warten.