9. Synchronisation in DBS: Grundlagen Sperrverfahren Grundlagen

9. Synchronisation in DBS:
Grundlagen Sperrverfahren
Grundlagen,
„ Anomalien
im Mehrbenutzerbetrieb
Mehrben t erbetrieb
„ Serialisierbarkeit
„ Zweiphasen-Sperrprotokolle
„ Konsistenzstufen von Transaktionen
„ Hierarchische Sperrverfahren
„ Deadlock-Behandlung
dl k h dl
– Timeout
– Wait/Die,
Wait/Die Wound/Wait,
Wound/Wait WDL
– Erkennung
„ Implementierung
SS09, © Prof. Dr. E. Rahm
der Datenstrukturen (Sperrtabelle)
9-1
IDBS 2
Mehrbenutzerbetrieb
„
Viele gleichzeitige Nutzer auf derselben DB
– Mehrbenutzerbetrieb mit paralleler Ausführung unabhängiger Transaktionen
„
Serielle (sequentielle) Ausführung von Transaktionen
inakzeptabel
– lange Wartezeiten für neue Transaktionen/DB-Anfragen bis laufende Transaktion
und andere bereits wartende Transaktionen beendet sind
– sehr schlechte CPU
CPU-Nutzung
Nutzung aufgrund zahlreicher Transaktionsunterbrechungen:
E/A, Kommunikationsvorgänge
„
Anomalien im Mehrbenutzerbetrieb ohne Synchronisation
1. Verlorengegangene Änderungen
Ä
(lost updates)
2. Abhängigkeiten von nicht freigegebenen Änderungen (dirty read, dirty
overwrite)
3. Inkonsistente
k i
Analyse
l
(non-repeatable
(
bl read)
d)
4. Phantom-Problem
Æ nur durch Änderungstransaktionen verursacht
SS09, © Prof. Dr. E. Rahm
9-2
IDBS 2
Verloren gegangene Änderung (Lost Update)
DB-Inhalt
Gehaltsänderung T1
SELECT GEHALT INTO :gehalt
FROM PERS
WHERE PNR = 2345
gehalt := gehalt + 2000;
(PNR GEHALT)
(PNR,
Gehaltsänderung T2
2345
29.000
SELECT GEHALT INTO :gehalt
FROM PERS
WHERE PNR = 2345
gehalt := gehalt + 1000;
UPDATE PERS
SET GEHALT = :gehalt
WHERE PNR = 2345
2345
UPDATE PERS
SET GEHALT = :gehalt
WHERE PNR = 2345
2345
Zeit
SS09, © Prof. Dr. E. Rahm
IDBS 2
9-3
Schmutziges Lesen (Dirty Read)
DB-Inhalt
Gehaltsänderung T 1
UPDATE PERS
SET GEHALT = GEHALT + 1000
3 5
WHERE PNR = 2345
(PNR, GEHALT)
2345 29.000
Gehaltsänderung T 2
2345
SELECT GEHALT INTO :gehalt
FROM PERS
WHERE PNR = 2345
•••
gehalt := gehalt * 1.05;
ROLLBACK WORK
UPDATE PERS
SET GEHALT = :gehalt
WHERE PNR = 3456
3456
2345
COMMIT WORK
Zeit
SS09, © Prof. Dr. E. Rahm
9-4
IDBS 2
Inkonsistente Analyse (Non-repeatable Read)
Lesetransaktion
(Gehaltssumme berechnen)
SELECT GEHALT INTO :gehalt
FROM PERS
WHERE PNR = 2345
summe = summe + gehalt
DB-Inhalt
Änderungstransaktion
g
(PNR, GEHALT)
2345
3456
29.000
38.000
UPDATE PERS
SET GEHALT = GEHALT + 1000
WHERE PNR = 2345
2345
40.000
UPDATE PERS
SET GEHALT = GEHALT + 2000
WHERE PNR = 3456
3456
50.000
COMMIT WORK
SELECT GEHALT INTO :gehalt
FROM PERS
WHERE PNR = 3456
summe = summe + gehalt
COMMIT WORK
SS09, © Prof. Dr. E. Rahm
Zeit
9-5
IDBS 2
Phantom-Problem
Lesetransaktion
Änderungstransaktion
(Gehaltssumme überprüfen)
(Einfügen eines neuen Angestellten)
SELECT SUM (GEHALT) INTO :summe
FROM PERS
WHERE ANR = 17
INSERT INTO PERS (PNR, ANR, GEHALT)
VALUES (4567, 17, 55.000)
COMMIT WORK
SELECT SUM (GEHALT) INTO :summe2
FROM PERS
WHERE ANR = 17
IF summe <> summe2 THEN
<Fehlerbehandlung>
Zeit
SS09, © Prof. Dr. E. Rahm
9-6
IDBS 2
Synchronisation von Transaktionen:
Modellannahmen
„
Transaktion: Programm T mit DB-Anweisungen
„ Annahme: Wenn T allein auf einer konsistenten DB ausgeführt
g
wird,, dann
terminiert T (irgendwann) und hinterlässt DB in einem konsistenten Zustand.
– keine Konsistenzgarantien während der Transaktionsverarbeitung
„
Wenn mehrere Transaktionen seriell ausgeführt werden, dann bleibt die
Konsistenz der DB erhalten
„
DB-Anweisungen lassen sich nachbilden durch READ- und WRITEOperationen
„ Transaktion besteht aus
– BOT (Begin Of Transaction)
– Folge von READ- und WRITE-Anweisungen auf Objekte
– EOT (End of Transaction): Commit oder Rollback (Abort)
SS09, © Prof. Dr. E. Rahm
9-7
IDBS 2
Modellannahmen (2)
„
Die Ablauffolge
Di
Abl ff l von Transaktionen
T
ki
mit
i ihren
ih
Operationen
O
i
kann
k
durch einen Schedule beschrieben werden:
– BOT ist implizit
– ri(x) bzw. wi(x): Read- bzw. Write-Operation durch Transaktion i auf Objekt x
– EOT wird durch ci (Commit) oder ai (Abort / Rollback) dargestellt
„
Beispiel:
„
Beispiel eines seriellen Schedules:
r1(x), r2(x), r3(y), w1(x), w3(y), r1(y), c1, r3(x), w2(x), a2, w3(x), c3, ...
r1(x),
(x) w1(x),
(x) r1(y),
(y) c1, r3(y),
(y) w3(y),
(y) r3(x),
(x) c3, r2(x),
(x) w2(x),
(x) c2,...
SS09, © Prof. Dr. E. Rahm
9-8
IDBS 2
Korrektheitskriterium der Synchronisation:
Serialisierbarkeit
„
„
Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h.
g aller Mehrbenutzeranomalien
Vermeidung
Gleichbedeutend mit formalem Korrektheitskriterium der
Serialisierbarkeit:
Die parallele Ausführung einer Menge von n
Transaktionen ist serialisierbar, wenn es eine
f
g der selben Transaktionen
serielle Ausführung
gibt, die für einen Ausgangszustand der DB
den gleichen Endzustand der DB wie
f
g erzielt.
die pparallele Transaktionsausführung
T1
T2
T3
„
Hintergrund:
– serielle Ablaufpläne sind korrekt
– jeder Ablaufplan, der denselben
Effekt wie ein serieller erzielt, ist akzeptierbar
SS09, © Prof. Dr. E. Rahm
9-9
quasi-parallele
serieller
Ablaufplan
A sführ ng
Ausführung
IDBS 2
Abhängigkeiten
„
„
Nachweis
N
h i der
d Serialisierbarkeit
S i li i b k i kann
k
über
üb Betrachtung
B
h
von
Abhängigkeiten zwischen Transaktionen geführt werden
Abhä i k it (Konflikt)
Abhängigkeit
(K flikt) T1->
> T2 besteht,
b t ht wenn Transaktion
T
kti T1
zeitlich vor Transaktion T2 auf das selbe Objekt zugreift und die
Zugriffe mit nicht reihenfolgeunabhängigen Operationen erfolgten
– zwei Lesezugriffe sind reihenfolgeunabhängig
– Schreibzugriffe auf dem selben Objekt verletzten Reihenfolgeunabhängigkeit (unterschiedliche
g
für Zugriffe
g
vor vs. nach dem Schreibzugriff)
g )
Ergebnisse
„
Konfliktarten:
– Schreib-/Lese (WR)-Konflikt
– Lese-/Schreib(RW)-Konflikt
– Schreib-/Schreib(WW)-Konflikt
„
Beispiel:
SS09, © Prof. Dr. E. Rahm
r1(x), w2(x), w3(y), w1(y), r3(x)
9 - 10
IDBS 2
Nachweis der Serialisierbarkeit
„
„
Führen von zeitlichen
Füh
i li h Abhängigkeiten
Abhä i k i zwischen
i h Transaktionen
T
ki
in
i
einem Abhängigkeitsgraphen (Konfliktgraphen)
S i li i b k it liegt
Serialisierbarkeit
li t vor, wenn der
d Abhängigkeitsgraph
Abhä i k it
h keine
k i
Zyklen enthält
=> Abhängigkeitsgraph beschreibt partielle Ordnung zwischen Transaktionen, die sich
zu einer vollständigen erweitern lässt (Serialisierungsreihenfolge)
w (y)
r (x)
T1
r (y)
T2
T3
w (x)
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 11
Anomalien im Schreib/Lese-Modell
Lost Update
r(x)
T1
T2
Dirty Read
w(x)
w(x)
w(x)
T1
r(x)
T2
Non-repeatable Read
r(x)
T1
T2
SS09, © Prof. Dr. E. Rahm
w(x)
9 - 12
r(x)
w(x)
IDBS 2
Konsistenzerhaltende Ablaufpläne
„
b inT
bei
Transaktionen
ki
bestehen
b
h n!! mögliche
ö li h serielle
i ll Schedules
S h d l
– Z.B. für drei Transaktionen T1, T2, T3 muß so synchronisiert werden, dass der resultierende
gleich dem ist,, der bei der seriellen Ausführungg in einer der folgenden
g
DB-Zustand g
Sequenzen zustande gekommen wäre.
„
T1 < T2 < T3
T2 < T1 < T3
T3 < T1 < T2
T1 < T3 < T2
T2 < T3 < T1
T3 < T2 < T1
Sinnvolle Einschränkungen:
– Reihenfolgeerhaltende
eihenfolgee haltende Se
Serialisierbarkeit:
ialisie ba keit: jede Transaktion
a sa t o sollte
so te wenigstens
we gste s alle
a e Änderungen
de u ge
sehen, die bei ihrem Start (BOT) bereits beendet waren
– Chronologieerhaltende Serialisierbarkeit: jede Transaktion sollte stets die aktuellste
j
sehen
Objektversion
„
Beispiel
T1
w (x)
T3
T2
SS09, © Prof. Dr. E. Rahm
w (x)
r (x)
IDBS 2
9 - 13
Historische Entwicklung von
Synchronisationsverfahren
Exklusive Objektsperren
RX-Sperrverfahren
hierarchische Sperren
optimistische
Verfahren
(BOCC, FOCC, ...)
SS09, © Prof. Dr. E. Rahm
Zeitmarkenverfahren
Varianten von Mehrversionen- Spezialverfahren
Sperrverfahren
Verfahren
(B*-Bäume,
(RAX, RAC, ...)
9 - 14
Hot-Spot-Synchronisation) ...)
IDBS 2
Zweiphasen-Sperrprotokolle (2 Phase Locking, 2PL)
„
Ei h l
Einhaltung
folgender
f l d Regeln
R l gewährleistet
äh l i
Serialisierbarkeit:
S i li i b k i
1. vor jedem Objektzugriff muss Sperre mit ausreichendem Modus angefordert werden
2 gesetzte Sperren anderer Transaktionen sind zu beachten
2.
3. eine Transaktion darf nicht mehrere Sperren für ein Objekt anfordern
4. Zweiphasigkeit:
- Anfordern
A f d
von Sperren
S
erfolgt
f l iin einer
i
W ht
Wachstumsphase
h
- Freigabe der Sperren in Schrumpfungsphase
- Sperrfreigabe kann erst beginnen, wenn alle Sperren gehalten werden
5. Spätestens bei EOT sind alle Sperren freizugeben
#Sperren
(2PL)
itli h
zeitlicher
Transaktionsverlauf
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 15
Striktes Zwei-Phasen-Sperren
„
2PL garantiert Serialisierbarkeit lediglich in fehlerfreier Umgebung
„ Fehler während Schrumpfungsphase können zu "Dirty Read" etc. führen
„
Lösungsalternativen
– Lesen schmutziger Daten und Abhängigkeiten bei Commit überprüfen (Problem:
kaskadierende Rollbacks)
– Besser: strikte Zwei-Phasen-Sperrverfahren mit Sperrfreigabe nach Commit (in CommitPhase 2 eines Zwei-Phasen-Commits)
#Sperren
Lock(x)
Unlock(x)
T1
Lock(x) Unlock(x)
BOT
T2
EOT
strikt zweiphasiges Sperren
Lock(x)
T3
Preclaiming
SS09, © Prof. Dr. E. Rahm
9 - 16
BOT
EOT
IDBS 2
RX-Sperrverfahren
„
Sperranforderung
S
f d
einer
i
T
Transaktion:
ki
R (Read)
(R d) oder
d X (eXclusive
( X l i bzw.
b
Write)
Wi )
„ Gewährter Sperrmodus des Objektes: NL, R, X
„ Kompatibilitätsmatrix:
aktueller Modus
NL
R
X
+ verträglich (kompatibel)
R
angeforderter
M d
Modus
- unverträglich
X
(NL (no lock) wird meist weggelassen)
„
unverträgliche Sperranforderung (Sperrkonflikt) führt zur Blockierung
– anfordernde Transaktion muss warten bis Sperre verfügbar wird
SS09, © Prof. Dr. E. Rahm
9 - 17
IDBS 2
Problem von Sperrkonversionen
T1
T2
R (y)
X (y)
R (y)
X (y)
„
Sperrkonversionen führen oft zu Deadlocks
„ Erweitertes
E
i
Sperrverfahren
S
f h
– Ziel: Verhinderung von Konversions-Deadlocks
– U-Sperre (Update) für Lesen mit Änderungsabsicht
– bei
b i Änderung
Ä d
Konversion
K
i U → X,
X andernfalls
d f ll U → R (Downgrading)
(D
di )
angeforderter
Modus
R
aktueller Modus
R
U
X
+
-
U
+
-
-
X
-
-
-
– u.a. in DB2 eingesetzt (SELECT FOR UPDATE)
– das
d Verfahren
h
ist
i unsymmetrisch
i h - was würde
d eine
i Symmetrie
i bei
b i U bewirken?
b ik
SS09, © Prof. Dr. E. Rahm
9 - 18
IDBS 2
Konsistenzstufen von Transaktionen
U
Ursprüngliche
ü li h Definition
D fi i i von Gray
G
et al.
l (1976)
„
Konsistenzstufe 0:
–T
Transaktionen
kti
halten
h lt kurze
k
Schreibsperren
S h ib
auff den
d Objekten,
Obj kt die
di sie
i
ändern
„
Konsistenzstufe 1:
– Transaktionen halten lange Schreibsperren auf den Objekten, die sie
ändern
„
Konsistenzstufe 2:
– Transaktionen halten lange
g Schreibsperren
p
auf den Objekten,
j
, die sie
ändern, sowie kurze Lesesperren auf Objekten, die sie lesen
„
Konsistenzstufe
f 3:
– Transaktionen halten lange Schreibsperren auf den Objekten, die sie
ändern sowie lange Lesesperren auf Objekten,
ändern,
Objekten die sie lesen.
lesen
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 19
Cursor Stability
„
Kurze L
K
Lesesperren iinnerhalb
h lb von Änderungstransaktionen
Ä d
ki
(Konsistenzstufe
(K i
f 2)
können zu Lost Updates führen
„
Cursor Stability: (kurze) Lesesperre bleibt gesetzt bis Cursor auf nächsten Satz
wechselt
– Verlust cursorbasierter Änderungen
g wird umgangen
g g
– Mitverantwortung des Programmierers zur Korrektheit der Synchronisation
exec sql SELECT GEHALT INTO :gehalt
FROM PERS WHERE PNR=:pnr;
gehalt = gehalt + 1000;
exec sql
UPDATE PERS
SET GEHALT = :gehalt
h l
WHERE PNR=:pnr;
SS09, © Prof. Dr. E. Rahm
exec sql
exec sql
DECLARE CURSOR C FOR
SELECT GEHALT
FROM PERS WHERE PNR=:pnr;
OPEN C;
exec sqll
FETCH C INTO :gehalt;
h l
gehalt = gehalt + 1000;
exec sql
UPDATE PERS
SET GEHALT = :gehalt
WHERE CURRENT OF CURSOR;
exec sql CLOSE C;
9 - 20
IDBS 2
Konsistenzebenen in SQL92
„
SQL92 vier
SQL92:
i K
Konsistenzebenen
i
b
(I
(Isolation
l i L
Level)
l) bbzgl.
l S
Synchronisation
h i i
– Konsistenzebenen sind durch die Anomalien bestimmt, die jeweils in Kauf genommen
werden
– Lost-Update muß generell vermieden werden
– Default ist Serialisierbarkeit (serializable)
Konsistenzebene
Read Uncommitted
„
Anomalie
Non-Repeatable
Dirty Read
Read
+
+
Phantome
+
Read Committed
-
+
+
p
Read
Repeatable
-
-
+
Serializable
-
-
-
SQL-Anweisung
SQL
Anweisung zum Setzen der Konsistenzebene:
SET
TRANSACTION <tx mode>, ISOLATION LEVEL <level>
– tx mode: READ WRITE (Default) bzw. READ ONLY
Beispiel: SET TRANSACTON READ ONLY
„
READ UNCOMMITTED für Änderungstransaktionen unzulässig
SS09, © Prof. Dr. E. Rahm
9 - 21
IDBS 2
Hierarchische Sperrverfahren
„
S
Sperrgranulat
l bestimmt
b i
Parallelität/Aufwand
P ll li ä /A f
d
– feines Granulat reduziert Sperrkonflikte
p
anzufordern und zu verwalten
– jjedoch sind viele Sperren
„
Hierarchische Verfahren erlauben Flexibilität bei Wahl des
Granulates (’multigranularity locking’)
– z.B. lange Transaktionen (Anfragen) auf Relationenebene und kurze Transaktionen auf
Satzebene synchronisieren
– kommerzielle DBS unterstützen zumeist mindestens 2-stufige Objekthierarchie, z.B.
Segment-Seite bzw. Satztyp (Relation) - Satz (Tupel)
Datenbank
Dateien (Segmente)
DB
S1
S2
Satztypen (Relationen)
Sätze (Tupel)
SS09, © Prof. Dr. E. Rahm
R21
S3
R22
T 2 11
9 - 22
IDBS 2
Hierarchische Sperrverfahren:
Anwartschaftssperren
p
„
mit R- und X-Sperre werden alle Nachfolgerknoten implizit mitgesperrt
=> Einsparungen möglich
„ alle Vorgängerknoten sind ebenfalls zu sperren, um Unverträglichkeiten zu
vermeiden => Verwendung von Anwartschaftssperren ('intention locks')
„ einfachste Lösung: Nutzung eines Sperrtyps (I-Sperre)
„
I
R
X
DB
I
+
-
-
Si
R
-
+
-
X
-
-
-
I
R
Rij
X
Unverträglichkeit von II und R
R-Sperren
Sperren zu restriktiv => zwei Arten von
Anwartschaftssperren (IR und IX)
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 23
Anwartschaftssperren (2)
„
A
Anwartschaftssperren
h f
fü
für L
Leser und
dS
Schreiber
h ib
IR
IX
R
X
IR
+
+
+
-
IX
+
+
-
-
Si
R
+
-
+
-
X
-
-
Rij
DB
IR
-
IX
R
X
„
IR- Sperre (intent read), falls auf untergeordneten Objekten nur lesend
zugegriffen wird,
wird sonst IX-Sperre
IX Sperre
„ Weitere Verfeinerung sinnvoll, um den Fall zu unterstützen, wo alle Tupel eines
Satztyps gelesen und nur einige davon geändert werden sollen
– X-Sperre auf Satztyp sehr restriktiv
– IX-auf Satztyp verlangt Sperren jedes Tupels
=>
> neuer Typ von Anwartschaftssperre: RIX = R + IX
– nur für zu ändernde Sätze muß (X-)Sperre auf Tupelebene angefordert werden
SS09, © Prof. Dr. E. Rahm
9 - 24
IDBS 2
Anwartschaftssperren (3)
„
V ll ä di
Vollständiges
Protokoll
P
k ll der
d Anwartschaftssperren
A
h f
– RIX gibt ein Leserecht auf den Knoten und seine Nachfolger. Weiterhin ist damit das Recht verbunden,
auf Nachfolger-Knoten IX, U und X-Sperren anzufordern.
– U gewährt
äh t Leserecht
L
ht auff den
d Knoten
K t undd seine
i Nachfolger
N hf l
- repräsentiert
ä ti t die
di Absicht,
Ab i ht den
d Knoten
K t in
i der
d
Zukunft zu verändern. Bei Änderung Konversion U → X, sonst U → R.
IR
IX
R
RIX
U
X
IR
+
+
+
+
-
-
IX
+
+
-
-
-
-
R
+
-
+
-
-
-
RIX
+
-
-
-
-
-
U
-
-
+
-
-
-
X
-
-
-
-
-
-
–
–
–
–
–
RIX
U
IR
R
X
IX
Sperranforderungen von der Wurzel zu den Blättern
Bei R- oder IR-Anforderung müssen für alle Vorgänger IX- oder IR-Sperren erworben werden
Bei X-, U-, RIX- o. IX-Anforderung müssen alle Vorgänger in RIX oder IX gehalten werden
Sperrfreigaben von den Blättern zu der Wurzel
Bei EOT sind alle Sperren freizugeben
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 25
Hierarchische Sperren: Beispiel
DATABASE
T1: IX T2: IR T3: R
TABLE-2
TABLE-1
T1:IX
TABLE-3
T1: IX T2: IR
T1: IX
T2: R
T2: R
T2
T2:
T2:S
T1:X R
REC
-A
REC-A
REC
-B
REC-B
T1: X
–
–
–
–
REC
-C
REC-C
T1: R
T2: R
T3 wartet
T2 hat Lesesperre auf der gesamten Tabelle 3
Lesesperren auf Satzebene in Tabelle 2
T1 hat Satzsperren in Tabelle 1 und 2
SS09, © Prof. Dr. E. Rahm
9 - 26
IDBS 2
Hierarchische Sperren: (De-) Escalation
„ Lock
Escalation
– Falls Transaktion sehr viele Sperren benötigt -> dynamisches Umschalten auf
gröberes
öb
Granulat
G
l
– Bsp.: nach 1000 Satzsperren auf einer Tabelle -> 1 Tabellensperre erwerben
– Schranke ist typischer Tuning-Parameter
„ Manchmal
kann Lock De-Escalation sinnvoll sein
– Erwerbe grob-granulare Sperre (z.B. für Tabelle)
– vermerke referenzierte Objekte auf fein-granularer Ebene (z.B. Sätze)
– bei Konflikt(en):
( ) Umschalten auf feine Sperren
p
SS09, © Prof. Dr. E. Rahm
9 - 27
IDBS 2
Deadlock-Behandlung
„ 5 Voraussetzungen für
f Deadlock
dl k
–
–
–
–
–
„
paralleler Objektzugriff
exklusive Zugriffsanforderungen
anfordernde Transaktion besitzt bereits Objekte/Sperren
keine vorzeitige Freigabe von Objekten/Sperren (non-preemption)
zyklische Wartebeziehung zwischen zwei oder mehr Transaktionen
Beispiel
T1
w(x)
w(y)
w(y)
w (x)
T2
„
Datenbanksysteme:
D
b k
D
Deadlock-Behandlung
dl k B h dl
erfordert
f d R
Rücksetzung
k
(R
(Rollback)
llb k)
von Transaktionen
SS09, © Prof. Dr. E. Rahm
9 - 28
IDBS 2
Lösungsmöglichkeiten zur Deadlock-Behandlung
1. Timeout-Verfahren
–
–
–
–
Transaktion wird nach festgelegter Wartezeit auf Sperre zurückgesetzt
problematische Bestimmung des Timeout-Wertes
viele unnötige Rücksetzungen bei kleinem Timeout-Wert
lange Blockaden bei großem Timeout-Wert
2. Deadlock-Verhütung
(Prevention)
– keine Laufzeitunterstützung zur Deadlock-Behandlung erforderlich
– Bsp.: Preclaiming (in DBS i.a. nicht praktikabel)
3 Deadlock-Vermeidung
3.
D dl k V
id
(Avoidance)
(A id
)
– potentielle Deadlocks werden durch entsprechende Maßnahmen vermieden
– Laufzeitunterstützung
La f eit nterstüt ng nötig
4. Deadlock-Erkennung (Detection)
– Zyklensuche innerhalb eines Wartegraphen
– gestattet minimale Anzahl von Rücksetzungen
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 29
Deadlock-Vermeidung
„
„
Zuweisung einer eindeutigen Transaktionszeitmarke bei BOT
im Konfliktfall darf nur ältere (bzw. jüngere) Transaktion warten
=> kein Zyklus möglich
– in Verteilten DBS : Behandlung globaler Deadlocks ohne Kommunikation
„
WAIT/DIE-Verfahren
– anfordernde Transaktion wird zurückgesetzt, falls sie jünger als Sperrbesitzer ist
– ältere
äl
T
Transaktionen
ki
warten auff jüngere
jü
Tj fordert Sperre, Konflikt mit Ti
T1
(ts=10)
ält als
l Tj }
if ts
t (T
(T)
t (T
(T)
i) < ts
j) { Ti älter
then WAIT (Ti)
else ROLLBACK (Ti) { "Die" }
T1
T2
SS09, © Prof. Dr. E. Rahm
w(x)
w(y)
Wait
T2
(ts=15)
Wait
Wait ?
T3
(ts=25)
w(y)
w (x)
9 - 30
IDBS 2
Deadlock-Vermeidung (2)
„
WOUND / WAIT-Verfahren:
WAIT V f h
– Sperrbesitzer wird zurückgesetzt, wenn er jünger als anfordernde
Transaktion ist: jüngere Transaktionen warten auf ältere
– preemptiver Ansatz
Ti fordert Sperre
Sperre, Konflikt mit T:
Tj :
if ts (Ti ) < ts (Tj ) { Ti älter als Tj }
then ROLLBACK (Tj ){ "Wound" }
else WAIT (Ti )
„
w(x)
T1
w(y)
w(y)
T2
w(x)
Verbesserung für Wait/Die und Wound/Wait:
– statt BOT-Zeitmarke
BOT Zeitmarke Zuweisung der Transaktionszeitmarke erst bei erstem Sperrkonflikt
("dynamische Zeitmarken")
– erster Sperrkonflikt kann stets ohne Rücksetzung behandelt werden
IDBS 2
SS09, © Prof. Dr. E. Rahm
9 - 31
Deadlock-Vermeidung: Wait Depth Limited
„
"Wartetiefe" (Wait Depth):
– eine nicht-blockierte Transaktion hat Wartetiefe 0
– blockierte Transaktion T hat Wartetiefe i+1,falls
i+1 falls i die maximale Wartetiefe derjenigen
Transaktionen ist, die T blockieren
„
Wait Depth
p Limited ((WDL):
) Begrenzung
g
g der maximalen Wartetiefe d
– d=0: kein Warten (Immediate Restart) -> keine Deadlocks möglich
– d=1: Warten erfolgt nur auf nicht-blockierte (laufende) Transaktionen -> keine Deadlocks
möglich
„
Problemfälle mit drohender Wartetiefe > 1
F ll 1:
Fall
1
Ti1
Ti2
...
Tik
SS09, © Prof. Dr. E. Rahm
Fall 2:
Tj1
Ti
Tj2
...
Ti1
Tj
Ti2
...
Tjk
Tik
9 - 32
Tj1
Ti
Tj2
...
Tj
Tjk
IDBS 2
Wait-Depth Limited (2)
„
WDL1 V i
WDL1-Variante
"R
"Running
i P
Priority"
i i "
Ti fordert Sperre
Sperre, Konflikt mit Tj :
if (Tj blockiert)
then KILL (Tj ) {Bevorzung der laufenden Transaktion}
else if (Tk wartet auf Ti ) {es existiert ein T k , die auf Ti wartet }
then ROLLBACK(Ti )
else WAIT (Ti )
Ti
„
Tj
Tk
T
Ti
Tj
Ti
Tj
bei hohen Konfliktraten zeigte WDL in Simulationen besseres
Leistungsverhalten als 2PL
SS09, © Prof. Dr. E. Rahm
IDBS 2
9 - 33
Deadlock-Erkennung
„
Explizites
E
li i Führen
Füh
eines
i
W
Wartegraphen
h (wait-for
( i f graph)
h) und
dZ
Zyklensuche
kl
h zur
Erkennung von Verklemmungen
– T1 -> T2: T1 wartet auf T2 wegen unverträglicher Sperranforderung
– Wartegraphen enthält nur laufende Transaktionen (im Gegensatz zu Abhängigkeitsgraphen)
T3
T5
O1
O2
O1
T2
O3
T4
O4
T1
„
Deadlock-Auflösung
Deadlock
Auflösung durch Zurücksetzen einer oder mehrerer am Zyklus
beteiligter Transaktion (z.B. Verursacher oder ’billigste’ Transaktion)
„ Zyklensuche entweder
– bei jedem Sperrkonflikt bzw.
– verzögert (z.B. über Timeout gesteuert)
SS09, © Prof. Dr. E. Rahm
9 - 34
IDBS 2
Implementierungsaspekte: Datenstrukturen
„
H h T b ll zur Realisierung
Hash-Tabelle
R li i
der
d Sperrtabelle
S
b ll
– schneller Zugriff auf
Objekt/Ressourcenkontrollblöcke für
Lock-Aufrufe
„
Transaktionstabelle
Matrixorganisation
Objekt /Transaktions
Objekt-/Transaktionstabelle
– schnelle Bestimmung
freizugebender Sperren bei
Commit
„
Kurzzeitsperren
( Latch“)) für
(„Latch
Zugriffe auf
Sperrtabelle
– Semaphor pro HashKlasse reduziert
Konflikt-Gefahr
SS09, © Prof. Dr. E. Rahm
S
Sperrtabelle
t b ll
(Ressourcentabelle)
9 - 35
IDBS 2
Sperrverfahren in Datenbanksystemen
„
Sperrverfahren: Vermeidung von Anomalien, in dem
– zu ändernde Objekte dem Zugriff aller anderen Transaktionen entzogen werden,
– zu lesende Objekte vor Änderungen geschützt werden
„
Standardverfahren: Hierarchisches Zweiphasen-Sperrprotokoll
– mehrere Sperrgranulate
p g
– Verringerung der Anzahl der Sperranforderungen
„
Probleme bei der Implementierung von Sperren
– Zweiphasigkeit der Sperren führt häufig zu langen Wartezeiten (starke Serialisierung)
– häufig benutzte Indexstrukturen können zu Engpässen werden
– Eigenschaften des Schemas können "hot spots" erzeugen
„
Optimierungen:
–
–
–
–
Begnügung mit reduzierter Konsistenzstufe
V kü
Verkürzung
dder S
Sperrdauer,
d
iinsbesondere
b
d für
fü Änderungen
Ä d
Nutzung mehrerer Objektversionen
spezialisierte Sperren (Nutzung der Semantik von Änderungsoperationen)
SS09, © Prof. Dr. E. Rahm
9 - 36
IDBS 2