4 Transaktionen und Recovery

Vorlesung Datenbanken
4
Wintersemester 2013/14
Transaktionen und Recovery
Zur Unterstützung des Mehrbenutzerbetriebs und der Datensicherheit,
speziell für länger andauernde Transaktionen:
1. In einem Reisebüro könnte ein Kunde eine Kette von Flügen (mit
Zwischenstops) buchen wollen, wobei er bereits reservierte Flüge
solange blockiert, bis er sich für eine komplette Reise entschieden hat.
Gleichzeitig wollen viele andere Kunden und Reisebüros auf dieselbe
Datenbank zugreifen.
2. In einer CAD–Datenbank werden komplexe Objekte verwaltet,
die oft über einen längeren Zeitraum von verschiedenen Benutzern
gleichzeitig – aber an unterschiedlichen Stellen – bearbeitet werden.
In beiden Fällen soll jede Transaktion nur einen möglichst kleinen Teil der
Datenbank blockieren.
Prof. Dr. Dietmar Seipel
440
Vorlesung Datenbanken
Wintersemester 2013/14
4.1 Transaktionsverwaltung
Eine Transaktion ist ein Programm, welches auf den Inhalt der Datenbank
zugreift oder diesen verändert.
Wir wollen die verschränkte Ausführung von Transaktionen und die dabei
auftretenden Probleme untersuchen.
Dabei sind vor allem die von einer Transaktion Ti ausgeführten Lese– und
Schreiboperationen auf der Datenbank von Interesse.
• ri (X) liest das Datenobjekt X in die Programmvariable X.
• wi (X) schreibt den Wert der Programmvariablen X auf das
Datenobjekt X.
Prof. Dr. Dietmar Seipel
441
Vorlesung Datenbanken
Wintersemester 2013/14
4.1.1 Das Synchronisationsproblem
Wir betrachten eine Flugdatenbank, in der ein Datenobjekt X die Anzahl der
reservierten Plätze in Flug X enthält.
Transaktion T1 storniert N Plätze von Flug X und bucht dafür N
Plätze von Flug Y . Transaktion T2 bucht M Plätze von Flug X.
Für die beiden Transaktionen
T1 = r1 (X); X := X − N ; w1 (X); r1 (Y ); Y := Y + N ; w1 (Y )
T2 = r2 (X); X := X + M ; w2 (X)
erledigen die beiden seriellen Schedules s1,2 = T1 ; T2 und s2,1 = T2 ; T1 die
Aufgabe korrekt.
Prof. Dr. Dietmar Seipel
442
Vorlesung Datenbanken
Wintersemester 2013/14
Verschränkte Schedules wie s1 und s2 können zu Problemen führen:
s2 :
s1 :
T1
T2
T1
r1 (X);
r1 (X);
X := X − N ;
X := X − N ;
w1 (X);
r2 (X);
r2 (X);
X := X + M ;
X := X + M ;
w1 (X);
w2 (X);
r1 (Y );
r1 (Y );
Prof. Dr. Dietmar Seipel
T2
w2 (X);
Y := Y + N ;
Y := Y + N ;
w1 (Y );
w1 (Y );
443
Vorlesung Datenbanken
Wintersemester 2013/14
Dynamische Situation bei der Verarbeitung von Transaktionen.
1. Das Phantom– oder Unrepeatable Read–Problem besteht darin,
daß eine Transaktion ein Datenobjekt zweimal liest, und daß dieses in
der Zwischenzeit von einer anderen Transaktion verändert wird.
2. Das Lost Update–Problem tritt auf, wenn die Operationen zweier
Transaktionen, welche dasselbe Datenobjekt betreffen, verschränkt
ausgeführt werden.
Dann kann unter Umständen der Wert eines Datenobjekts hinterher
falsch sein, da einzelne Update–Operationen verloren gehen.
In s2 hat X nach der Ausführung keinen vernünftigen Wert, weil T2 den
Update von T1 überschreibt, obwohl T2 den Wert von X vor dem Update
durch T1 gelesen hat.
Prof. Dr. Dietmar Seipel
444
Vorlesung Datenbanken
Wintersemester 2013/14
3. Das Temporary Update– oder Dirty Read–Problem tritt auf,
wenn eine Transaktion ein Datenobjekt verändert und danach aus
irgendeinem Grund abgebrochen werden muß.
Dann kann es sein, daß eine andere Transaktion auf diesen temporären
Update zugreift, bevor das Datenobjekt auf seinen alten Wert
zurückgesetzt wurde.
Der temporäre neue Wert wird als dirty data bezeichnet.
Falls Transaktion T1 in s1 nach r1 (Y ) scheitert, so muß der alte Wert
von X wiederhergestellt werden.
Inzwischen hat allerdings T2 schon den temporären, falschen Wert von
X gelesen.
Prof. Dr. Dietmar Seipel
445
Vorlesung Datenbanken
Wintersemester 2013/14
4. Das Incorrect Summary–Problem (fehlerhafte Zusammenfassung) tritt
auf, wenn eine Transaktion eine Aggregatsfunktion berechnet, während
andere Transaktionen gleichzeitig die Datenbank verändern.
Dann kann es sein, daß die Aggregatsfunktion auf manche Tupel vor
dem Update zugreift und auf manche nach dem Update.
Das berechnete Resultat der Aggregatsfunktion entspricht dann keinem
vernünftigen Datenbankzustand.
Im folgenden Schedule s3 berechnet die Transaktion T3 die Summe der
Werte A, . . . , Z, und liest dabei
• X, nachdem dieses von T1 um N verringert wurde, und
• Y , bevor dieses um denselben Betrag N erhöht wurde,
woraus eine um N zu niedrige Summe resultiert.
Prof. Dr. Dietmar Seipel
446
Vorlesung Datenbanken
Wintersemester 2013/14
T1
T3
sum := 0;
r3 (A);
sum := sum + A;
.
..
r1 (X);
X := X − N ;
w1 (X);
r3 (X);
sum := sum + X;
r3 (Y );
sum := sum + Y ;
r1 (Y );
Y := Y + N ;
w1 (Y );
Prof. Dr. Dietmar Seipel
447
Vorlesung Datenbanken
Wintersemester 2013/14
Die Transaktion T1 könnte folgenden S QL–Statements entsprechen,
welche 10 Reservierungen eines Flugs auf einen anderen Flug tauschen:
U PDATE
FLIGHTS
S ET
AVAILABLE = AVAILABLE – 10
W HERE
NUMBER = ’DL 003’ A ND DATE = ’2007–12–04’;
U PDATE
FLIGHTS
S ET
AVAILABLE = AVAILABLE + 10
W HERE
NUMBER = ’LH 007’ A ND DATE = ’2007–12–04’;
Die Transaktion T3 könnte ein Teil der Berechnung des folgenden
S QL–Statements sein, welches die Anzahl der freien Flüge pro Tag ermittelt:
Prof. Dr. Dietmar Seipel
S ELECT
DATE, S UM (AVAILABLE)
F ROM
FLIGHTS
G ROUP B Y
DATE
448
Vorlesung Datenbanken
Wintersemester 2013/14
Ähnliche Probleme können in der C OMPANY–Datenbank entstehen,
wenn die Transaktion T1 Gehaltserhöhungen in E MPLOYEE durchführt,
während die Transaktion T2 die Summe der Löhne pro Abteilung ermittelt.
T1 könnte folgendem S QL–Statement entsprechen:
U PDATE
EMPLOYEE
S ET
SALARY = SALARY * 1.1
W HERE
BDATE > ’1975–12–24’
T2 entspricht folgendem S QL–Statement:
Prof. Dr. Dietmar Seipel
S ELECT
DNO, S UM (SALARY)
F ROM
EMPLOYEE
G ROUP B Y
DNO
449
Vorlesung Datenbanken
Wintersemester 2013/14
4.1.2 Operationen, Log–Buch
Das System protokolliert im Log–Buch alle Operationen, welche die Werte
von Datenobjekten betreffen (d.h. Lese– und Schreiboperationen).
Dadurch kann man bei Transaktionsfehlern immer noch zu einem korrekten
Datenbankzustand gelangen (→ Recovery).
Das Log–Buch wird auf der Festplatte gehalten, und es ist somit gegen fast
alle Systemfehler resistent.
Darüberhinaus wird das Log–Buch auch regelmäßig auf externe
Speichermedien gesichert, um noch besser vor Datenverlust gefeit zu sein.
Prof. Dr. Dietmar Seipel
450
Vorlesung Datenbanken
Wintersemester 2013/14
Folgende Einträge ins Log–Buch sind möglich:
start_transaction(T ): vermerkt den Start der Ausführung der
Transaktion T
write_item(T, X, Vold , Vnew ): vermerkt, daß Transaktion T den Wert des
Datenobjekts X von Vold auf Vnew verändert hat.
read_item(T, X): vermerkt, daß Transaktion T den Wert des
Datenobjekts X gelesen hat.
commit(T ): vermerkt, daß die Transaktion T erfolgreich beendet wurde,
und daß damit der Effekt von T auf die Datenbank permanent gemacht
werden kann.
abort(T ): vermerkt den Abbruch von Transaktion T.
Prof. Dr. Dietmar Seipel
451
Vorlesung Datenbanken
Wintersemester 2013/14
Wir nehmen an, daß Transaktionen nicht geschachtelt werden können.
Bei einem Systemzusammenbruch können wir aufgrund des Log–Buches
einen konsistenten Datenbank–Zustand herstellen:
• Falls eine Transaktion abgebrochen werden soll,
so kann man die Schreib–Operationen dieser Transaktion im Log–Buch
rückwärts verfolgen und einzeln zurücknehmen (undo),
indem man die Datenobjekte wieder auf ihre alten Werte setzt.
• Falls eine Transaktion weiterlaufen soll,
so kann man die Schreiboperationen dieser Transaktion im Log–Buch
vorwärts verfolgen und einzeln wiederholen (redo),
indem man die Datenobjekte auf ihre neuen Werte setzt.
Prof. Dr. Dietmar Seipel
452
Vorlesung Datenbanken
Wintersemester 2013/14
Transaktionen
T5
noch nicht
freigegeben
T
4
T3
T2
T1
checkpoint
T1 : irrelevant
Prof. Dr. Dietmar Seipel
T2 , T3 : restaurieren
crash
Zeit
T4 , T5 : zurücksetzen
453
Vorlesung Datenbanken
Wintersemester 2013/14
Der Commit–Punkt einer Transaktion
Eine Transaktion T erreicht ihren Commit–Punkt, sobald alle ihre
Zugriffsoperationen auf die Datenbank erfolgreich ausgeführt wurden
(und der Effekt der Operationen im Log–Buch protokolliert ist).
Danach heißt T freigegeben (committed), und ihr Effekt wird als permanent
angenommen. T schreibt einen Eintrag commit(T ) ins Log–Buch.
Falls ein Systemfehler auftritt, so wird im Log–Buch rückwärts nach allen
Transaktionen gesucht, welche ihr start_transaction(T ) eingetragen haben.
• Diejenigen Transaktionen darunter, welche noch kein commit(T )
eingetragen haben, müssen während des Recovery rückgängig gemacht
werden (roll–back) mittels undo–Operationen.
• Die Transaktionen mit commit(T )–Eintrag können mittels redo der
Schreib–Operationen aus dem Log–Buch wiederholt werden.
Prof. Dr. Dietmar Seipel
454
Vorlesung Datenbanken
Wintersemester 2013/14
Vor dem Commit einer Transaktion T müssen alle ihre Log–Buch–Einträge
auf Platte gesichert werden (force writing).
Bei einem Systemzusammenbruch können nur diese Teile des Log–Buches
zum Recovery verwendet werden.
Checkpoints
Regelmäßig wird auch ein checkpoint–Eintrag ins Log–Buch geschrieben.
Zu diesem Zeitpunkt werden die Updates von freigegebenen Transaktionen
in der Datenbank auf Platte durchgeführt – und das Log–Buch wird ebenfalls
auf Platte gesichert (Sicherungshierarchie).
Folglich müssen alle Transaktionen, welche ihren commit(T )–Eintrag vor
dem checkpoint–Eintrag im Log haben, bei einem Systemzusammenbruch
nicht wiederholt werden.
Prof. Dr. Dietmar Seipel
455
Vorlesung Datenbanken
Wintersemester 2013/14
Crashes
Bei einem Crash müssen alle laufenden, und noch nicht freigegebenen
Transaktionen zurückgesetzt werden. Dies ist unabhängig davon, ob die
Transaktionen vor (T4 ) oder nach (T5 ) dem letzten Checkpoint gestartet
wurden.
Die vor dem letzten Checkpoint bereits freigegebenen Transaktionen (T1 )
leiden nicht unter dem Crash, da ihre Effekte und Log–Buch–Einträge bereits
auf Platte gesichert wurden – sie sind für unsere Betrachtung hier also
irrelevant.
Nur die zwischem dem letzten Checkpoint und dem aktuellen Crash
freigegebenen Transaktionen müssen restauriert werden. Dies ist unabhängig
davon, ob die Transaktionen vor (T2 ) oder nach (T3 ) dem letzten Checkpoint
gestartet wurden.
Prof. Dr. Dietmar Seipel
456
Vorlesung Datenbanken
Wintersemester 2013/14
Transaktions–Status–Diagramm
BEGIN
TRANSACTION
READ,
WRITE
ACTIVE
END
TRANSACTION
PARTIALLY
COMMITTED
COMMIT
COMMITTED
ABORT
ABORT
FAILED
TERMINATED
Sobald eine Transaktion T alle Datenzugriffe erfolgreich durchgeführt hat,
ist sie partially committed.
Vor dem endgültigen commit müssen Concurrency Control– und Recovery
Control–Checks sicherstellen, daß T keine unerwünschten
Wechselwirkungen mit anderen Transaktionen hatte.
Dieses würde, genau wie ein Fehler bei den Datenzugriffen, zu einem
Abbruch (abort) führen, und T wäre fehlgeschlagen.
Prof. Dr. Dietmar Seipel
457
Vorlesung Datenbanken
Wintersemester 2013/14
4.1.3 Das ACID–Prinzip
Zum Zwecke einer korrekten Synchronisation und der Gewährleistung von
Fehlertoleranz muß die Transaktionsverwaltung folgende vier Eigenschaften
sicherstellen:
Atomarität (Atomicity)
Eine Transaktion wird aus der Sicht des Benutzers vollständig oder gar
nicht ausgeführt. Wird eine Ausführung vor ihrem eigentlichen Ende
abgebrochen, so erscheint die Datenbank hinterher so, als wäre diese
Ausführung nie gestartet worden.
Konsistenz (Consistency)
Alle Integritätsbedingungen der Datenbank werden eingehalten,
d.h. eine Transaktion hinterläßt stets einen konsistenten Zustand,
falls sie in einem solchen gestartet wurde.
Prof. Dr. Dietmar Seipel
458
Vorlesung Datenbanken
Wintersemester 2013/14
Isolation
Jede Transaktion läuft isoliert von anderen Transaktionen ab.
Sie ist aber nicht nur hinsichtlich der Behandlung des
Datenbankpuffer–Bereichs, sondern auch hinsichtlich ihrer
Datenbankbehandlung von anderen Transaktionen unabhängig.
Persistenz (Durability)
Falls die Transaktion dem Benutzer als erfolgreich beendet gemeldet
wird, so überleben die von ihr in der Datenbank erzeugten Effekte jeden
danach auftretenden Hardware– (Hauptspeicher) oder Softwarefehler,
und zwar sogar dann, wenn sie sich zum Zeitpunkt des Fehlers noch im
Datenbankpuffer (und nicht schon in der Datenbank selbst) befinden.
Prof. Dr. Dietmar Seipel
459
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (ACID)
1. Vor und nach einer Transaktion T müssen alle Integritätsbedingungen
(Primär– und Fremdschlüssel–Bedingungen) erfüllt sein. Während der
Transaktion können einzelne Updates von T diese zeitweise verletzen.
2. Der folgende Schedule s entspricht keiner isolierten Ausführung der
beiden Transaktionen T1 und T2 , denn T2 liest das Resultat “X − 1” von
T1 , und T1 liest das Resultat “2 · Y ” von T2 .
s erzeugt in jedem Falle eine Resultats–Datenbank,
welche die Integritätsbedingung “X + Y = 0” verletzt,
auch wenn die Ausgangs–Datenbank diese Bedingung erfüllt.
Für die neuen Werte X ′ und Y ′ gilt nämlich X ′ = 2 · (X − 1) und
Y ′ = 2 · Y + 1. Falls X + Y = 0 gilt, so folgt daraus
X ′ + Y ′ = 2 · (X − 1) + 2 · Y + 1 = 2 · (X + Y ) + 1 = 1.
Prof. Dr. Dietmar Seipel
460
Vorlesung Datenbanken
Wintersemester 2013/14
T1
T2
r1 (X);
X := X − 1;
w1 (X);
r2 (X);
X := 2 · X;
.
.
.
w2 (X);
.
.
.
r2 (Y );
Y := 2 · Y ;
w2 (Y );
r1 (Y );
Y := Y + 1;
w1 (Y );
Prof. Dr. Dietmar Seipel
461
Vorlesung Datenbanken
Wintersemester 2013/14
Transaktionen und Schedules
1. Zeitlich verzahnte Ausführungsreihenfolgen von Operationen (read,
write) verschiedener Transaktionen werden modelliert durch Schedules.
2. Es liegt eine dynamische Situation vor:
Die zu verarbeitenden Transaktionen sind dem DBMS a priori nicht
bekannt; es muß jederzeit bereit sein, neu eintreffende Operationen zu
verarbeiten und insbesondere mit bereits laufenden zu synchronisieren.
p1,1 p1,2 ...
←−−−−−−−
DB
p1,1 q2,1 o3,1 o3,2 p1,2 q2,2 ...
←−−−−−−−−−−−−−−−−
Scheduler
q2,1 q2,2 ...
←−−−−−−−
o3,1 o3,2 ...
←−−−−−−−
Wenn man die Transaktionen wie die Spuren einer Autobahn bei einer Streckenverengung auf
eine einzige Spur und die Aktionen wie die Fahrzeuge betrachtet, dann regelt der Scheduler das
Einfädeln lassen. Dabei müssen nicht immer alle Spuren gleichmäßig zum Zuge kommen.
Prof. Dr. Dietmar Seipel
462
Vorlesung Datenbanken
Wintersemester 2013/14
3. Wir interessieren uns für Bedingungen, unter denen ein solcher Schedule
als korrekt bezeichnet werden kann.
Diese Bedingungen sollen leicht testbar sein.
Die Theorie der Korrektheit von Schedules soll außerdem ohne die
Kenntniss semantischer Information auskommen.
3. Zur Analyse der Korrektheit von Operationenfolgen werden nur
syntaktische Kriterien herangezogen,
nämlich die Folge der Lese– und Schreiboperationen.
Die Korrektheit eines Schedules hängt mit der Äquivalenz zu einem
seriellen Schedule zusammen.
Diese garantiert dann die korrekte Synchronisation beliebiger
Operationenfolgen.
Prof. Dr. Dietmar Seipel
463
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Semantische Äquivalenz)
1. Die beiden Schedules s1 , s2 liefern unterschiedliche Ergebnisse
(X − 1 bzw. X − 2) und sind semantisch nicht äquivalent:
s2 :
s1 :
T1
T2
r1 (X);
T2
r1 (X);
r2 (X);
X := X − 1;
X := X − 1;
w1 (X);
w1 (X);
Prof. Dr. Dietmar Seipel
T1
r2 (X);
X := X − 1;
X := X − 1;
w2 (X);
w2 (X);
464
Vorlesung Datenbanken
Wintersemester 2013/14
2. Die beiden Schedules s′1 , s′2 liefern dasselbe Ergebnis und sind
semantisch äquivalent für boolesche Werte X ∈ {0, 1}, denn
X − 1 = X 2 − 1 ⇔ X ∈ {0, 1},
sonst liefern sie unterschiedliche Ergebnisse.
s′2 :
s′1 :
T1
T2
r1 (X);
T1
T2
r1 (X);
r2 (X);
X := X 2 ;
X := X 2 ;
w1 (X);
w1 (X);
r2 (X);
X := X − 1;
X := X − 1;
w2 (X);
w2 (X);
Nur die Datenoperationen unterscheiden sich im Vergleich zu 1.
Prof. Dr. Dietmar Seipel
465
Vorlesung Datenbanken
Wintersemester 2013/14
s′1 :
s′2 :
T1
T2
r1 (X);
T1
T2
r1 (X);
r2 (X);
X := X 2 ;
X := X 2 ;
w1 (X);
w1 (X);
r2 (X);
X := X − 1;
X := X − 1;
w2 (X);
w2 (X);
Zur Analyse der Korrektheit von Schedules werden nur syntaktische Kriterien
basierend auf der Folge der Lese– und Schreib–Operationen herangezogen.
s1 =
ˆ s′1 =
ˆ r1 (X) r2 (X) w1 (X) w2 (X),
ˆ r1 (X) w1 (X) r2 (X) w2 (X).
s2 =
ˆ s′2 =
Prof. Dr. Dietmar Seipel
466
Vorlesung Datenbanken
Wintersemester 2013/14
4.1.4 Transaktionen, Schedules und Serialisierbarkeit
Im Folgenden sei eine Datenbank eine Menge D = { x, y, z, . . . } von
unteilbaren und disjunkten Objekten (z.B. Datenseiten),
welche in einem Schritt zwischen Sekundär– und Hauptspeicher bzw.
Datenbankpuffer transportiert werden können.
Für die korrekte Synchronisation parallel auszuführender Benutzeraufträge
an eine Datenbank ist es wichtig, deren
• lesende (read, r) und
• schreibende (write, w) Datenzugriffe
zu kontrollieren.
Prof. Dr. Dietmar Seipel
467
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Transaktion)
Eine Transaktion ist eine endliche Folge
ti = p1 . . . pn
von n ∈ IN Lese– und Schreib–Operationen
pj ∈ { ri (Xj ), wi (Xj ) }, mit Xj ∈ D, für 1 ≤ j ≤ n.
Wir machen die Annahme, daß in jeder Transaktion jedes Datenobjekt
höchstens einmal gelesen oder geschrieben wird.
In Gegenwart mehrerer Transaktionen t1 , . . . , tm kann man die Schritte der
verschiedenen Transaktionen durch ihren Index eindeutig zuordnen.
Beispiel (Transaktion)
t1 = r1 (X) w1 (X) r1 (Y ) w1 (Y )
Prof. Dr. Dietmar Seipel
468
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Schedule)
Sei T = { t1 , . . . , tn } eine (endliche) Menge von Transaktionen.
1. Das Shuffle–Produkt shuffle(T ) von T ist die Menge aller Folgen
s = p1 . . . pm von Schritten, welche folgende Bedingungen erfüllen:
• die Folgen ti ∈ T kommen in s als Teilfolgen vor,
• sonst kommen in s keine weiteren Schritte vor.
2. Ein vollständiger Schedule s für T entsteht aus einer Folge
s′ ∈ shuffle(T ) durch Hinzunahme der Pseudo–Schritte ci (commit) und
ai (abort) für jede Transaktion ti ∈ T nach folgenden Regeln:
• entweder ci oder ai ist in s, aber nicht beide: ci ∈ s ⇔ ai ∈
/ s,
• ci bzw. ai steht in s irgendwo hinter dem letzten Schritt von ti .
Prof. Dr. Dietmar Seipel
469
Vorlesung Datenbanken
Wintersemester 2013/14
3. shuffle ac (T ) bezeichnet die Menge aller vollständigen Schedules für T .
4. Ein Schedule ist ein Präfix eines vollständigen Schedules.
5. Ein vollständiger Schedule heißt seriell, falls
s = tπ(1) pπ(1) . . . tπ(n) pπ(n)
gilt für eine Permutation π : h 1, n i −→ h 1, n i und für
Pseudo–Schritte pi ∈ {ci , ai }, für 1 ≤ i ≤ n.
Das englische to give the cards a shuffle bedeutet im Deutschen die Karten
mischen. Dabei werden zwei Kartenstapel – diese entsprechen den
Transaktionen – unter Beibehaltung ihrer relativen Reihenfolge verschränkt.
Prof. Dr. Dietmar Seipel
470
Vorlesung Datenbanken
Wintersemester 2013/14
Permutationen sind bijektive Abbildungen
π : h 1, n i −→ h 1, n i.
Man kann sie durch ihren Funktionsgraphen (Wertetabelle) veranschaulichen:
i
1
2 3
π(i)
3
1 2
Die zweite Zeile enthält eine Permutation des Intervalls h 1, n i.
Für die Transaktionsmenge T = { t1 , t2 , t3 } und die Pseudo–Schritte
c1 , a2 , c3 erhalten wir den seriellen Schedule
s = tπ(1) pπ(1) tπ(2) pπ(2) tπ(3) pπ(3) = t3 c3 t1 c1 t2 a2 .
Da es n! Permutation des Intervalls h 1, n i gibt, gibt es für vorgegebene
Pseudo–Schritte genauso viele mögliche serielle Schedules zu T .
Prof. Dr. Dietmar Seipel
471
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Schedule)
Gegeben sei die Menge T = { t1 , t2 } von Transaktionen:
t1 = r1 (X) w1 (X) r1 (Y ) w1 (Y ),
t2 = r2 (X) w2 (X).
1. s1 = r1 (X) w1 (X) r2 (X) w2 (X) r1 (Y ) w1 (Y ) a1 c2
ist ein vollständiger Schedule.
2. Das Präfix s2 = r1 (X) w1 (X) r2 (X) w2 (X) r1 (Y ) w1 (Y )
von s1 ist ein Schedule.
3. s3 = t1 a1 t2 c2 und s4 = t2 c2 t1 a1 sind serielle Schedules.
Prof. Dr. Dietmar Seipel
472
Vorlesung Datenbanken
Wintersemester 2013/14
Der Status einer Transaktion ergibt sich aus einem Schedule.
Definition (Transaktionsstatus)
1. trans(s) enthält alle an einem Schedule s beteiligten Transaktionen,
commit(s) alle bereits freigegebenen, abort(s) alle abgebrochenen,
und active(s) alle noch aktiven Transaktionen:
trans(s)
= { ti | s enthält Schritte von ti },
commit(s) = { ti ∈ trans(s) | s enhält ci },
abort(s)
= { ti ∈ trans(s) | s enhält ai },
active(s)
= trans(s) \ (commit(s) ∪ abort(s)).
2. Die Menge aller in s vorkommenden Schritte (einschließlich der Schritte
ai und ci ) wird mit op(s) bezeichnet.
Prof. Dr. Dietmar Seipel
473
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Transaktionen, Schedules)
Gegeben sei die Menge T = { t1 , t2 , t3 } von Transaktionen:
t1 = r1 (X) w1 (X) r1 (Y ) w1 (Y ),
t2 = r2 (Z) w2 (X) w2 (Z),
t3 = r3 (X) r3 (Y ) w3 (Z).
1. Dann gilt:
s1 = r1 (X) r2 (Z) r3 (X) w2 (X) w1 (X) r3 (Y )
r1 (Y ) w1 (Y ) w2 (Z) w3 (Z) ∈ shuffle(T ),
s2 = s1 c1 c2 a3 ∈ shuffle ac (T ),
s3 = r1 (X) r2 (Z) r3 (X) ist ein Schedule.
s4 = t1 c1 t3 a3 t2 c2 ist ein serieller Schedule.
Prof. Dr. Dietmar Seipel
474
Vorlesung Datenbanken
Wintersemester 2013/14
2. Für den vollständigen Schedule s = s2 und den seriellen Schedule
s = s4 gilt:
trans(s) =
commit(s) =
abort(s) =
active(s) =
op(s) =
=
{ t1 , t2 , t3 },
{ t1 , t2 },
{ t3 },
∅,
op(t1 ) ∪ op(t2 ) ∪ op(t3 ) ∪ { c1 , c2 , a3 } =
{ r1 (X), w1 (X), r1 (Y ), w1 (Y ),
r2 (Z), w2 (X), w2 (Z),
r3 (X), r3 (Y ), w3 (Z),
c1 , c2 , a3 }.
Prof. Dr. Dietmar Seipel
475
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Abschluß und Projektion eines Schedules)
Sei s ein Schedule.
1. Sei t0 eine Transaktion, welche alle in s angesprochenen Datenobjekte –
in der Reihenfolge des Auftretens in s jedes Datenobjekt genau einmal –
liest und dann freigegeben wird.
Dann heißt der Schedule s̄ = s t0 c0 der Abschluß von s.
2. Die Projektion ΠT (s) von s auf T ⊆ trans(s) ist der Schedule, der
entsteht, wenn man aus s alle Schritte zu den Transaktionen aus
trans(s) \ T entfernt.
3. Die freigegebene Projektion (committed projection) von s ist
CP (s) = Πcommit (s) (s).
4. Der bereinigte Schedule s∗ = Πcommit (s)∪active(s) (s) entsteht aus s,
indem man alle Operationen zu abgebrochenen Transaktionen wegläßt.
Prof. Dr. Dietmar Seipel
476
Vorlesung Datenbanken
Wintersemester 2013/14
Die Transaktion t0 in s̄ liest den am Ende von s aktuellen Datenbankzustand.
Beispiel (Abschluß und Projektion eines Schedules)
Wir betrachten den Schedule
s = w1 (X) r2 (X) w2 (Y ) r1 (Y ) w1 (Y ) w3 (X) w3 (Y ) c1 a2 .
1. Der Abschluß von s ist s̄ = s t0 c0 , wobei t0 = r0 (X) r0 (Y ).
2. Für T = { t1 , t2 } gilt commit(s) = { t1 }, active(s) = { t3 }, und:
ΠT (s) = w1 (X) r2 (X) w2 (Y ) r1 (Y ) w1 (Y ) c1 a2 ,
CP (s) = w1 (X) r1 (Y ) w1 (Y ) c1 ,
s∗
= w1 (X) r1 (Y ) w1 (Y ) w3 (X) w3 (Y ) c1 .
Für einen vollständigen Schedule s gilt active(s) = ∅, und folglich
s∗ = CP (s).
Prof. Dr. Dietmar Seipel
477
Vorlesung Datenbanken
Wintersemester 2013/14
Serialisierbarkeit
Äquivalenz zu einem seriellen Schedule.
Definition (Relationen <s und →s )
Sei s ein Schedule.
1. Steht in s ein Schritt p vor einem Schritt q, so schreiben wir p <s q.
2. Seien ri (X) und wj (X) zwei Operationen von unterschiedlichen
Transaktionen ti bzw. tj in s, die auf demselben Datenobjekt X
operieren.
ri (X) liest X in s von wj (X), falls wj (X) die letzte Schreiboperation
in s vor ri (X) ist, so daß tj vor ri (X) nicht abgebrochen ist.
X
3. Dann schreiben wir wj →s ri .
Prof. Dr. Dietmar Seipel
478
Vorlesung Datenbanken
Wintersemester 2013/14
Die folgende Relation RF (reads from) basiert auf dem Abschluß eines
Schedules, um zusätzlich zu berücksichtigen, welche Schreiboperationen den
resultierenden Datenbankzustand ausmachen.
Definition (Liest–Von–Relation)
Sei s ein Schedule.
1. Die Liest–Von–Relation von s ist
X
X
RF (s) = { wj → ri | wj →s̄ ri }.
2. Die bereinigte Liest–Von–Relation von s ist RF ∗ (s) = RF (s∗ ).
Für einen Schedule s und ti 6= tj ∈ trans(s) gilt:
X
X
wj → ri ∈ RF (s) ⇐⇒ wj →s̄ ri ⇐⇒
wj (X) <s̄ ri (X) ∧ aj 6<s̄ ri (X)∧
( wj (X) <s̄ wk (X) <s̄ ri (X) ⇒ ak <s̄ ri (X) )
Prof. Dr. Dietmar Seipel
479
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Liest–Von–Relation)
1. Für die Schedules s1,2 = w1 (X) w2 (X) und s2,1 = w2 (X) w1 (X) gilt
s1,2 = w1 (X) w2 (X) r0 (X) c0 , s2,1 = w2 (X) w1 (X) r0 (X) c0 ,
und da es keine abgebrochenen Transaktionen gibt
X
RF ∗ (s1,2 ) = RF (s1,2 ) = { w2 → r0 }.
X
RF ∗ (s2,1 ) = RF (s2,1 ) = { w1 → r0 }.
Der Netto–Effekt des Schedules wird von w2 (X) bzw. w1 (X) bewirkt.
2. Unter dem Schutze einer weiteren, abschließenden Schreiboperation
w3 (X) haben beide Schedules denselben Netto–Effekt:
s1,2,3 = w1 (X) w2 (X) w3 (X), s2,1,3 = w2 (X) w1 (X) w3 (X),
X
RF ∗ (s1,2,3 ) = RF ∗ (s2,1,3 ) = { w3 → r0 }.
Der Netto–Effekt beider Schedules wird von w3 (X) bewirkt.
Prof. Dr. Dietmar Seipel
480
Vorlesung Datenbanken
Wintersemester 2013/14
3. Für die Schedules
s1 = w1 (X) r2 (X),
s2 = w1 (X) r2 (X) a1 ,
s3 = w1 (X) a1 r2 (X),
gilt:
X
X
RF (s1 ) = { w1 → r2 , w1 → r0 }.
X
RF (s2 ) = { w1 → r2 }.
RF (s3 ) = ∅.
In s2 und s3 hat w1 (X) keinen Netto–Effekt, da die Transaktion t1
X
abgebrochen wird; der Konflikt w1 → r0 existiert hier nicht.
In s3 wird die Transaktion t1 sogar vor r2 (X) abgebrochen;
X
deswegen existiert auch der Konflikt w1 → r2 hier nicht.
Die bereinigten Liest–Von–Relationen von s2 und s3 sind beide ∅,
da hierfür der Zeitpunkt des Abbruchs von t1 keine Rolle spielt.
Prof. Dr. Dietmar Seipel
481
Vorlesung Datenbanken
Wintersemester 2013/14
4. Für s = r1 (X) r2 (Y ) w1 (Y ) w2 (Y ) und die Schedules
s1 = s c1 c2 , s2 = s c1 a2 , s3 = r1 (X) w1 (Y ) c1 r2 (Y ) w2 (Y ) c2 ,
gilt s¯i = si r0 (X) r0 (Y ) c0 .
Y
Y
a) In s¯1 gilt w2 →s¯1 r0 . In s¯2 gilt wegen a2 hingegen w1 →s¯2 r0 .
Y
Y
b) In s¯3 gilt w2 →s¯3 r0 und zusätzlich w1 →s¯3 r2 .
c) Wir erhalten die folgenden Relationen:
Y
RF ∗ (s1 ) = RF (s1 ) = { w2 → r0 },
Y
RF ∗ (s2 ) = RF (s2 ) = { w1 → r0 },
Y
Y
RF ∗ (s3 ) = RF (s3 ) = { w1 → r2 , w2 → r0 }.
X
5. Für s = w1 (X) r2 (X) a1 sind RF ∗ (s) = ∅ und RF (s) = { w1 → r2 }
unterschiedlich, da der Abbruch a1 erst nach r2 (X) erfolgt.
X
w1 →s̄ r0 gilt aber nicht, da in s̄ der Abbruch a1 vor r0 (X) erfolgt.
Prof. Dr. Dietmar Seipel
482
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (View–Äquivalenz, View–Serialisierbarkeit)
1. Zwei Schedules s, s′ heißen view–äquivalent, in Zeichen s ≈v s′ ,
falls op(s) = op(s′ ) und RF ∗ (s) = RF ∗ (s′ ) gilt.
2. Ein vollständiger Schedule s heißt view–serialisierbar, falls er
view–äquivalent ist zu einem seriellen Schedule s′ (d.h. s ≈v s′ ).
3. VSR ist die Klasse der view–serialisierbaren Schedules.
Satz (Test auf View–Äquivalenz und –Serialisierbarkeit)
1. Das Problem zu entscheiden, ob zwei gegebene Schedules s, s′
view–äquivalent sind, ist in Linearzeit lösbar.
2. Das Problem zu entscheiden, ob ein gegebener Schedule s
view–serialisierbar ist, ist N P–vollständig.
Die Verfahren zur Erzeugung view–serialisierbarer Schedules vermeiden diesen
Test – genau wie die 3NF–Synthese den N P–vollständigen 3NF–Test vermeidet.
Prof. Dr. Dietmar Seipel
483
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (View–Serialisierbarkeit)
1. Wir betrachten die drei Schedules
s
= r1 (X) r2 (Y ) w1 (Y ) w2 (Y ) c1 c2 ,
s1,2 = r1 (X) w1 (Y ) c1 r2 (Y ) w2 (Y ) c2 ,
s2,1 = r2 (Y ) w2 (Y ) c2 r1 (X) w1 (Y ) c1 .
Dann gilt op(s) = op(s1,2 ) = op(s2,1 ), aber
RF ∗ (s) = RF (s)
Y
= { w2 → r0 },
Y
Y
RF ∗ (s1,2 ) = RF (s1,2 ) = { w1 → r2 , w2 → r0 },
Y
RF ∗ (s2,1 ) = RF (s1,2 ) = { w1 → r0 }.
Folglich ist s zu keinem der beiden möglichen Serialisierungen s1,2 und
s2,1 view–äquivalent und damit nicht view–serialisierbar.
Prof. Dr. Dietmar Seipel
484
Vorlesung Datenbanken
Wintersemester 2013/14
2. Wir betrachten die drei leicht variierten Schedules
s
= r1 (X) r2 (Y ) w1 (Y ) w2 (Y ) a1 c2 ,
s1,2 = r1 (X) w1 (Y ) a1 r2 (Y ) w2 (Y ) c2 ,
s2,1 = r2 (Y ) w2 (Y ) c2 r1 (X) w1 (Y ) a1 ,
in denen die Transaktion t1 abgebrochen wird.
Dann gilt op(s) = op(s1,2 ) = op(s2,1 ) und
RF (s) = RF (s1,2 ) = RF (s2,1 ) =
Y
RF ∗ (s) = RF ∗ (s1,2 ) = RF ∗ (s2,1 ) = { w2 → r0 }.
Also ist s view–äquivalent zu s1,2 und zu s2,1 und damit
view–serialisierbar. Die Aktionen der abgebrochenen Transaktion t1
spielen dafür keine Rolle.
Prof. Dr. Dietmar Seipel
485
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Konfliktrelation)
Sei s ein Schedule und t, t′ ∈ trans(s), mit t 6= t′ .
1. Zwei Operationen p(X) ∈ t und q(X) ∈ t′ stehen in s in Konflikt,
falls
a) sie auf demselben Datenobjekt X operieren und
b) mindestens eine von ihnen schreibt, d.h. p = wi oder q = wj .
2. Die Konfliktrelation C(s) von s ist definiert durch
X
C(s) = { p → q | p(X) <s q(X) und
p(X) und q(X) stehen in s in Konflikt }.
3. Die bereinigte Konfliktrelation von s ist C ∗ (s) = C(s∗ ).
Prof. Dr. Dietmar Seipel
486
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Konfliktrelation)
1. Für den Schedule s = w1 (X) erhalten wir C ∗ (s) = C(s) = ∅ und
X
RF ∗ (s) = RF (s) = { w1 → r0 }.
2. Für den Schedule
s = w1 (X) r2 (X) w2 (Y ) r1 (Y ) w1 (Y ) w3 (X) w3 (Y ) c1 a2
erhalten wir folgende Konfliktrelationen:
X
Y
Y
C ∗ (s)
=
{ w1 → w3 , r1 → w3 , w1 → w3 },
C(s)
=
C ∗ (s) ∪ { w1 → r2 , r2 → w3 , w2 → r1 , w2 → w1 , w2 → w3 }.
X
X
Y
Y
Y
Die abgebrochene Transaktion t2 wird in C ∗ (s) nicht berücksichtigt.
C(s) enthält transitive Verknüpfungen wie z.B.
X
X
X
w1 → r2 , r2 → w3 und w1 → w3 .
Prof. Dr. Dietmar Seipel
487
Vorlesung Datenbanken
Wintersemester 2013/14
RF (s) und RF ∗ (s) vs. C(s) und C ∗ (s)
rj
Die Konfliktrelation C(s) berücksichtigt alle Konflikte
X
X
◦
ri
X
wi
wi → rj , wi → wj , ri → wj ,
wj
◦
◦
X
während die Liest–Von–Relation RF (s) nur Konflikte wi → rj
berücksichtigt, bei denen ti vor rj (X) nicht abgebrochen wurde.
Abgebrochene Transaktionen
1. werden in RF ∗ (s) und in C ∗ (s) überhaupt nicht berücksichtigt,
2. während sie in RF (s) nur dann nicht berücksichtigt werden,
wenn der Abbruch vor rj (X) erfolgte.
Für jedes Datenobjekt X erkennt man die letzte wirksame Schreib–Operation
X
wi (X), mit ti 6∈ abort(s), an wi → r0 ∈ RF (s) bzw. an den am weitesten
X
X
rechts stehenden Konflikten wi → p oder p → wi ∈ C ∗ (s), an denen X
beteiligt ist (falls es solche gibt).
Prof. Dr. Dietmar Seipel
488
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (RF (s) und RF ∗ (s) vs. C(s) und C ∗ (s))
1. Für den Schedule s1 = w1 (X) w2 (X) r3 (X) erhalten wir
X
X
RF (s1 ) = { w2 → r3 , w2 → r0 } = RF ∗ (s1 ),
C(s1 )
X
X
X
= { w1 → w2 , w1 → r3 , w2 → r3 } = C ∗ (s1 ).
2. Für s2 = w1 (X) w2 (X) a2 r3 (X) und s3 = w1 (X) w2 (X) r3 (X) a2 erhalten
wir C(s1 ) = C(s2 ) = C(s3 ), aber
X
X
X
X
RF (s2 ) = { w1 → r3 , w1 → r0 },
RF (s3 ) = { w2 → r3 , w1 → r0 },
da der Abbruch a2 bei C gar nicht und bei RF erst für nachfolgende
Lese–Operationen wirksam ist.
X
3. RF ∗ (s2 ) = RF ∗ (s3 ) = RF (s2 ) und C ∗ (s2 ) = C ∗ (s3 ) = { w1 → r3 }
berücksichtigen a2 dagegen gleich.
Prof. Dr. Dietmar Seipel
489
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Konflikt–Äquivalenz, Konflikt–Serialisierbarkeit)
1. Zwei Schedules s und s′ heißen konflikt–äquivalent,
in Zeichen s ≈c s′ , falls op(s) = op(s′ ) und C ∗ (s) = C ∗ (s′ ).
2. Ein vollständiger Schedule s heißt konflikt–serialisierbar,
falls er konflikt–äquivalent ist zu einem seriellen Schedule s′
(d.h. s ≈c s′ ).
3. CSR ist die Klasse der konflikt–serialisierbaren Schedules.
Satz (View– vs. Konflikt–Serialisierbarkeit)
1. Jeder konflikt–serialisierbare Schedule ist auch view–serialisierbar.
2. Es gibt view–serialisierbare Schedules,
die nicht konflikt–serialisierbar sind.
3. Es gilt also CSR ( VSR.
Prof. Dr. Dietmar Seipel
490
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Konflikt–Serialisierbarkeit)
Wir betrachten die folgenden Schedules:
s
=
r1 (X) r1 (Y ) w2 (X) w1 (Y ) r2 (Z) w1 (X) w2 (Y ),
s′
=
r1 (Y ) r1 (X) w1 (Y ) w2 (X) w1 (X) r2 (Z) w2 (Y ).
s′ entstand aus s durch paarweise Vertauschungen von nicht in Konflikt
stehenden Operationen. Dann gilt op(s) = op(s′ ) und
X
Y
X
Y
C ∗ (s) = C ∗ (s′ ) = { r1 → w2 , r1 → w2 , w2 → w1 , w1 → w2 },
und folglich s ≈c s′ . Hier gilt
X
Y
RF ∗ (s) = RF ∗ (s′ ) = { w1 → r0 , w2 → r0 },
und folglich s ≈v s′ .
Prof. Dr. Dietmar Seipel
491
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Konfliktgraph)
Der Konfliktgraph G(s) = (V, E) eines Schedules s ist definiert durch
V = commit(s) und
X
E = { (t, t′ ) ∈ V 2 | ∃ p(X) ∈ t, q(X) ∈ t′ : p → q ∈ C ∗ (s) }.
Beispiel (Konfliktgraph)
Der vollständige Schedule
s = r1 (X) r2 (X) w1 (X) r3 (X) w3 (X) w2 (Y ) c3 c2 w1 (Y ) c1
hat den azyklischen Konfliktgraphen G(s) und
∗
X
X
X
C (s) = { r1 → w3 , r2 → w1 , r2 → w3 ,
X
X
t1
t
2
Y
w1 → r3 , w1 → w3 , w2 → w1 }.
′
s ≈c s = t2 c2 t1 c1 t3 c3 .
Prof. Dr. Dietmar Seipel
t
3
492
Vorlesung Datenbanken
Wintersemester 2013/14
Eigenschaften von Konfliktgraphen
Lemma (Konfliktgraphen)
Zwei konflikt–äquivalente Schedules s und s′ haben denselben
Konfliktgraphen:
s ≈c s′ =⇒ G(s) = G(s′ ).
Beweis.
Sei G(s) = (V, E) und G(s′ ) = (V ′ , E ′ ).
Nach Definition der Konflikt–Äquivalenz s ≈c s′ gilt:
• op(s) = op(s′ ),
• C ∗ (s) = C ∗ (s′ ).
Aus dem ersten folgt V = commit(s) = commit(s′ ) = V ′ , und aus dem
zweitem folgt E = E ′ . Also ist G(s) = G(s′ ).
Prof. Dr. Dietmar Seipel
493
Vorlesung Datenbanken
Wintersemester 2013/14
Lemma (Konfliktgraphen)
Der Konfliktgraph G(s) eines seriellen Schedules s ist azyklisch.
Beweis.
Sei s = t1 p1 . . . tn pn .
X
• Für jede Kante (ti , tj ) ∈ E gibt es p → q ∈ C ∗ (s) mit Operationen
p(X) ∈ ti und q(X) ∈ tj .
• Deshalb gilt i < j.
• Also kann G(s) nach aufsteigenden Indizes topologisch sortiert werden.
• Damit ist G(s) azyklisch.
Prof. Dr. Dietmar Seipel
494
Vorlesung Datenbanken
Wintersemester 2013/14
Konflikt–neutrale Vertauschungen
Die Relationen RF ∗ (s) und C ∗ (s) sind invariant gegenüber gewissen
Vertauschungen der Operationen von s:
s
=
r1 (Y ) r3 (V ) r2 (Y ) w1 (Y ) w1 (X) w2 (X) w2 (Z) w3 (X) c1 c2 c3 ,
↓
s′
=
r2 (Y ) r1 (Y ) w1 (Y ) w1 (X) w2 (X) w2 (Z) r3 (V ) w3 (X) c1 c2 c3
s′ ≈c s, s′ ≈v s
↓
s′′
=
r2 (Y ) w2 (X) w2 (Z) c2 r1 (Y ) w1 (Y ) w1 (X) c1 r3 (V ) w3 (X) c3
s′′ ≈v s, s′′ 6≈c s
Die Leseoperationen r1 (Y ) und r2 (Y ) können vertauscht werden ohne
RF ∗ (s) oder C ∗ (s) zu ändern.
Prof. Dr. Dietmar Seipel
495
Vorlesung Datenbanken
Wintersemester 2013/14
Unter dem Schutze von w3 (X) können w1 (X) und w2 (X) vertauscht
werden, ohne RF ∗ (s) zu ändern; dabei ändert sich aber C ∗ (s).
Aktionen unterschiedlicher Transaktionen, die auf unterschiedliche
Datenobjekte zugreifen, können natürlich vertauscht werden,
ohne RF ∗ (s) oder C ∗ (s) zu ändern:
• Da V sonst nicht vorkommt, kann r3 (V ) nach hinten wandern.
• w2 (X) kann über w1 (Y ) und r1 (Y ) hinweg nach vorne wandern.
Schließlich können auch die Pseudo–Schritte ci and ai (hier nicht vorhanden)
mit Aktionen anderer Transaktionen sowie mit anderen Pseudo–Schritten
vertauscht werden – natürlich können sie aber nicht über Aktionen ihrer
eigenen Transaktion hinweg wandern.
Der Schedule s ist offensichtlich view–serialisierbar, da s zu dem seriellen
Schedule s′′ view–äquivalent ist. Wir werden später sehen, daß s aber nicht
konflikt–serialisierbar ist.
Prof. Dr. Dietmar Seipel
496
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (View– vs. Konflikt–Serialisierbarkeit)
Der vollständige Schedule
s = r1 (Y ) r3 (V ) r2 (Y ) w1 (Y ) w1 (X) w2 (X) w2 (Z) w3 (X) c1 c2 c3
von gerade eben ist view–serialisierbar mit s ≈v s′′ = t2 c2 t1 c1 t3 c3 :
Y
Z
X
RF ∗ (s) = RF ∗ (s′′ ) = { w1 → r0 , w2 → r0 , w3 → r0 }.
Wir erhalten unterschiedliche Konfliktrelationen:
Y
X
X
X
Y
X
X
X
C ∗ (s)
=
{ r2 → w1 , w1 → w2 , w1 → w3 , w2 → w3 },
C ∗ (s′′ )
=
{ r2 → w1 , w2 → w1 , w1 → w3 , w2 → w3 }
und den zyklischen Konfliktgraphen G(s).
t
t
1
2
Der Schedule s ist nicht konflikt–serialisierbar:
s ∈ VSR \ CSR.
Prof. Dr. Dietmar Seipel
t
3
497
Vorlesung Datenbanken
Wintersemester 2013/14
Satz (Test auf Konflikt–Serialisierbarkeit)
Für einen vollständigen Schedule s ist s ∈ CSR, g.d.w. G(s) azyklisch ist.
Der Test s ∈ CSR kann also in polynomieller Zeit erfolgen.
Beweis.
“⇒” Zu einem Schedule s ∈ CSR gibt es nach Definition einen seriellen
Schedule s′ mit s ≈c s′ . Für diesen gilt G(s) = G(s′ ).
Da s′ seriell ist, ist G(s′ ) azyklisch, und somit auch G(s).
“⇐” Sei G(s) = (V, E) mit V = { t1 , . . . , tn } azyklisch.
Dann kann G(s) topologisch sortiert werden mittels einer Permutation
π : h 1, n i −→ h 1, n i.
Sei s′′ der Sub–Schedule von s zu den abgebrochenen Transaktionen
aus s.
Prof. Dr. Dietmar Seipel
498
Vorlesung Datenbanken
Wintersemester 2013/14
Dann betrachten wir folgenden seriellen Schedule
s′ = s′′ tπ(1) cπ(1) . . . tπ(n) cπ(n) .
Wir zeigen, daß C ∗ (s) = C ∗ (s′ ) und somit s ≈c s′ gilt.
Offensichtlich gilt op(s) = op(s′ ), commit(s) = commit(s′ ) und
X
• Für p → q ∈ C ∗ (s), mit p(X) ∈ ti , q(X) ∈ tj , gilt
(ti , tj ) ∈ E
top. Sort.
=⇒
X
ti steht vor tj in s′ =⇒ p → q ∈ C ∗ (s′ ).
X
• Für p → q ∈ C ∗ (s′ ), mit p(X) ∈ tπ(i) , q(X) ∈ tπ(j) , i < j, gilt
top. Sort.
=⇒
X
p(X) <s q(X) =⇒ p → q ∈ C ∗ (s).
Also gilt C ∗ (s) = C ∗ (s′ ) und somit s ≈c s′ .
Prof. Dr. Dietmar Seipel
499
Vorlesung Datenbanken
Wintersemester 2013/14
Der auf C ∗ (s) basierende Konfliktgraph G(s) eines vollständigen Schedules
s kann dessen Konflikt–Serialisierbarkeit also entscheiden:
• Genau dann wenn er azyklisch ist, ist s konflikt–serialisierbar.
• Seine topologische Sortierung liefert dann einen seriellen Schedule s′ ,
der zu s konflikt–äquivalent ist.
Der entsprechende, auf RF ∗ (s) basierende Konfliktgraph kann die
View–Serialisierbarkeit dagegen nicht entscheiden:
• Falls er zyklisch ist, so ist s sicher nicht view–serialisierbar.
• Falls er azyklisch ist, so liefert er eine partielle Ordnung, der potentielle
zu s view–äquivalente serielle Schedules s′ folgen müssen.
• Das heißt aber nicht, daß es dann auch einen zu s view–äquivalenten
seriellen Schedule s′ gibt.
Prof. Dr. Dietmar Seipel
500
Vorlesung Datenbanken
Wintersemester 2013/14
Konfliktgraphen helfen also nicht beim Test auf View–Serialisierbarkeit.
Dies ist auch schon deshalb nicht möglich, da der entsprechende Test
N P–vollständig ist.
Der vollständige Schedule
s = r1 (X) r2 (Y ) w1 (Y ) w2 (Y ) c1 c2
ist nicht view–serialisierbar, obwohl der entsprechende Konfliktgraph zu
Y
RF ∗ (s) = { w2 → r0 } azyklisch ist.
Vorgehensweise in der Praxis
Solange nur ein Präfix eines Schedules bekannt ist, weiß man nicht, welche
der laufenden Transaktionen mit Commit bzw. Abort beendet werden.
Deswegen geben die CSR–basierten Zwei–Phasen–Scheduler Datenobjekte
erst frei, wenn sie alle Datenzugriffe gemacht haben.
Prof. Dr. Dietmar Seipel
501
Vorlesung Datenbanken
Wintersemester 2013/14
Synchronisationsprobleme
Analyse im Hinblick auf Konflikt–Serialisierbarkeit
1. Das Lost–Update–Problem: Der zugehörige Schedule lautet
s = r1 (X) r2 (X) w1 (X) r1 (Y ) w2 (X) w2 (Y ) c1 c2 .
Es gilt
X
X
X
Y
C ∗ (s) = { r1 → w2 , r2 → w1 , w1 → w2 , r1 → w2 },
und der Konfliktgraph G(s) ist zyklisch:
t
1
t
2
Folglich ist s nicht konflikt–serialisierbar, d.h. s ∈
/ CSR.
s ist auch nicht view–serialisierbar, d.h. s ∈
/ VSR.
Prof. Dr. Dietmar Seipel
502
Vorlesung Datenbanken
Wintersemester 2013/14
2. Das Dirty–Read–Problem: Der zugehörige Schedule lautet
s = r1 (X) w1 (X) r2 (X) w2 (X) r1 (Y ) a1 c2 .
Hier gilt s ∈ CSR, aber die abgebrochene Transaktion wird hier nicht
berücksichtigt, und die Betrachtung ist nicht adäquat.
X
Der Abbruch von t1 führt wegen w1 →s r2 auch zum Abbruch von t2 .
3. Das Problem der fehlerhaften Zusammenfassung: Der zugehörige
Schedule lautet:
s = r2 (A) . . . r1 (X) w1 (X) r2 (X) r2 (Y ) r1 (Y ) w1 (Y ) c1 c2 .
X
Y
Hier gilt C ∗ (s) = { w1 → r2 , r2 → w1 }, und der Konfliktgraph G(s)
ist zyklisch; s ist also nicht konflikt–serialisierbar, s ∈
/ CSR:
t
1
t
2
s ist auch nicht view–serialisierbar, d.h. s ∈
/ VSR.
Prof. Dr. Dietmar Seipel
503
Vorlesung Datenbanken
Wintersemester 2013/14
Commit–Serialisierbarkeit
Transaktionen können abbrechen, und das System kann im laufenden Zustand
unterbrochen werden. Deshalb sollte sich ein Korrektheitskriterium de facto nur auf
freigegebene Transaktionen beziehen, und bei einem korrekten Schedule sollte auch
jedes Präfix korrekt sein.
Definition (Abschlußeigenschaften von Schedule–Eigenschaften)
Sei E eine Schedule–Eigenschaft.
1. E ist präfix–abgeschlossen (PA), genau dann wenn gilt:
E gilt für einen Schedule s, g.d.w. E für jedes Präfix von s gilt.
2. E ist commit–abgeschlossen (CA), genau dann wenn gilt:
E gilt für einen Schedule s, g.d.w. E für den Schedule CP(s) gilt.
3. E ist präfix–commit–abgeschlossen (PCA), genau dann wenn gilt:
E gilt für einen Schedule s, g.d.w. E für den Schedule CP(s′ ) zu jedem
beliebigen Präfix s′ von s gilt.
Prof. Dr. Dietmar Seipel
504
Vorlesung Datenbanken
Wintersemester 2013/14
Satz (Präfix–Commit–Abgeschlossenheit)
CA
PA
PCA
VSR
+
–
–
CSR
+
–
+
1. Die View–Serialisierbarkeit ist CA, aber nicht PA und nicht PCA.
2. Die Konflikt–Serialisierbarkeit ist CA und PCA, aber nicht PA.
Beweis.
1. Für s = w1 (X) w2 (X) w2 (Y ) w1 (Y ) c1 c2 w3 (X) w3 (Y ) c3 gilt
s ≈v t1 c1 t2 c2 t3 c3 ≈v t2 c2 t1 c1 t3 c3 ,
da man w1 (χ) und w2 (χ) unter dem Schutz des abschließenden w3 (χ)
vertauschen kann, für χ = X, Y , d.h. s ∈ VSR.
Für das Präfix s′ = w1 (X) w2 (X) w2 (Y ) w1 (Y ) c1 c2 von s gilt aber
CP (s′ ) = s′ und s′ 6≈v t1 c1 t2 c2 , s′ 6≈v t2 c2 t1 c1 , d.h. s′ ∈
/ VSR.
Also ist die V.–S. nicht PCA.
Prof. Dr. Dietmar Seipel
505
Vorlesung Datenbanken
Wintersemester 2013/14
2. Für s ∈ CSR ist G(s) azyklisch.
Der Graph G(CP (s′ )) zu einem Präfix s′ von s ist ein Teilgraph von
G(s), und somit ebenfalls azyklisch, d.h. CP (s′ ) ∈ CSR.
Also ist die K.–S. PCA.
3. Die V.–S. und die K.–S. sind beide CA,
denn für einen vollständigen Schedule s gilt s∗ = CP (s),
und folglich RF ∗ (s) = RF ∗ (CP (s)) und C ∗ (s) = C ∗ (CP (s)).
4. Jeder serialisierbare Schedule s ∈ VSR oder s ∈ CSR muß vollständig
sein, aber für einen vollständigen und seriellen – und damit auch
serialisierbaren – Schedule s muß nicht jedes Präfix s′ vollständig sein.
Z.B. ist für den serialisierbaren Schedule s = w1 (X) c1 das Präfix
s′ = w1 (X) nicht vollständig und damit auch nicht serialisierbar.
Die V.–S. und die K.–S. sind also beide natürlich nicht PA.
Prof. Dr. Dietmar Seipel
506
Vorlesung Datenbanken
Wintersemester 2013/14
Fehlersicherheit von Schedules
Definition (RC , ACA und ST ) Sei s ein Schedule.
RC . s heißt rücksetzbar (recoverable), falls für alle ti 6= tj ∈ trans(s) gilt:
X
wj →s ri ∧ ci ∈ s ⇒ cj <s ci .
RC bezeichnet die Klasse der rücksetzbaren Schedules.
ACA. s vermeidet kaskadierende Aborts (avoids cascading aborts),
falls für alle ti 6= tj ∈ trans(s) gilt:
X
wj →s ri ⇒ cj <s ri (X).
ACA bezeichnet die Klasse aller Schedules, welche kaskadierende Aborts
vermeiden. Sie vermeiden das Problem des dirty read.
ST . s heißt strikt, falls für alle ti 6= tj ∈ trans(s) und alle p ∈ {r, w} gilt:
wj (X) <s pi (X) ⇒ aj <s pi (X) ∨ cj <s pi (X).
ST bezeichnet die Klasse der strikten Schedules.
Prof. Dr. Dietmar Seipel
507
Vorlesung Datenbanken
Wintersemester 2013/14
RC , ACA und ST sind PCA.
Satz (Klassen von Schedules)
s0
VSR
ST ( ACA ( RC .
Später:
s1
RC
1. E(2PL) ⊆ CSR,
ACA
s2
CSR
s3
ST
s5
s4
2. E(S2PL) ⊆ CSR ∩ ST ,
3. E(TO–Basis) ⊆ CSR,
4. E(TO–Thomas) ⊆ VSR,
5. E(TO–Mehrversionen) ⊆ VSR.
Prof. Dr. Dietmar Seipel
508
Vorlesung Datenbanken
Wintersemester 2013/14
Beweis.
ST ⊆ ACA.
Für s ∈ ST und ti 6= tj ∈ trans(s) gilt:
X
wj →s ri
=⇒ wj (X) <s ri (X) ∧ aj 6<s ri (X)
ST
=⇒ cj <s ri (X).
ACA ⊆ RC .
Für s ∈ ACA und ti 6= tj ∈ trans(s) gilt:
X
wj →s ri ∧ ci ∈ s
ACA
=⇒
cj <s ri (X) ∧ ri (X) <s ci
=⇒
c j <s c i .
Striktheit nur bezüglich der Lese–Operationen pi (X) = ri (X) impliziert
offensichtlich auch schon ACA.
Prof. Dr. Dietmar Seipel
509
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiele (RC , ACA, ST )
RC . jede Transaktion wird erst nach der Freigabe aller Transaktionen, von
denen sie gelesen hat, freigegeben:
s1 = r1 (X) w1 (X) r2 (X) w2 (X) c2 c1 ∈
/ RC
s2 = r1 (X) w1 (X) r2 (X) w2 (X) c1 c2 ∈ RC
ACA. eine Transaktion darf nur Werte lesen, welche von bereits
freigegebenen Transaktionen zuletzt geschrieben wurden:
s2 ∈
/ ACA
s3 = r1 (X) w1 (X) w2 (X) c1 c2 ∈ ACA
s4 = r1 (X) w1 (X) c1 r2 (X) w2 (X) c2 ∈ ACA
ST . eine Transaktion darf nur Werte lesen oder überschreiben, welche von
bereits abgeschlossenen Transaktionen zuletzt geschrieben wurden:
s3 ∈
/ ST , s4 ∈ ST
Prof. Dr. Dietmar Seipel
510
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (VSR und CSR vs. ST )
Für den folgenden Schedule gilt s5 ∈ ST \ VSR :
s5 = r1 (X) w2 (Y ) w2 (X) c2 r1 (Y ) c1 .
Y
X
1. s5 ∈
/ CSR, denn C ∗ (s) = { r1 → w2 , w2 → r1 }.
2. s5 ∈
/ VSR, denn für s1,2 = t1 c1 t2 c2 und s2,1 = t2 c2 t1 c1 gilt
Y
X
Y
X
RF (s1,2 ) = { w2 → r0 , w2 → r0 },
RF (s2,1 ) = { w2 → r1 , w2 → r1 } ∪ RF (s1,2 ),
RF (s5 )
Y
= { w2 → r1 } ∪ RF (s1,2 ).
3. Wegen w2 (Y ) <s5 c2 <s5 r1 (Y ) gilt s5 ∈ ST .
Prof. Dr. Dietmar Seipel
511
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (VSR \ CSR vs. RC )
Der vollständige Schedule
s = r1 (Y ) r3 (V ) r2 (Y ) w1 (Y ) w1 (X) w2 (X) w2 (Z) w3 (X) c1 c2 c3 ,
für den bekanntermaßen s ∈ VSR \ CSR gilt, kann mit dem vollständigen
Schedule
s4,5 = ̺{17→4,27→5} (s1 ) = r4 (X) w4 (X) r5 (X) w5 (X) c5 c4 ∈
/ RC
zu einem Schedule
s0 = s4,5 s ∈ (VSR \ CSR) \ RC
kombiniert werden.
Wir sehen später noch, daß für den Schedule s1 von oben s1 ∈ E(2PL) gilt:
s1 = r1 (X) w1 (X) r2 (X) w2 (X) c2 c1 ∈
/ RC .
Prof. Dr. Dietmar Seipel
512
Vorlesung Datenbanken
Wintersemester 2013/14
4.2 Concurrency Control
Wir garantieren die Korrektheit von Schedules durch die Verwendung
spezieller Scheduling–Techniken:
1. Beim Zwei–Phasen–Sperrprotokoll müssen Datenobjekte vor dem
Zugriff durch eine Transaktion gesperrt und nach dem Zugriff wieder
freigegeben werden. In der Sperrphase dürfen nur Sperren gesetzt
werden. Mit dem ersten Entsperrschritt beginnt die zweite Phase,
in der nur noch Sperren freigegeben werden dürfen.
2. Bei Zeitstempelverfahren werden Daten beim Zugriff mit Lese– und
Schreib–Zeitstempeln versehen. Beim Zugriff auf ein Datenobjekt wird
getestet, ob die Zeitstempelordnung verletzt wird.
Prof. Dr. Dietmar Seipel
513
Vorlesung Datenbanken
Wintersemester 2013/14
Überlegungen zum Scheduler–Entwurf
Der Transaktionsmanager (TM) nimmt die auszuführenden Transaktionen
vom Codegenerator entgegen.
Der Scheduler erhält vom TM einen (“zufällig erzeugten”) Input–Schedule
mit Schritten vom Typ r, w, a, c. Er hat die Aufgabe, hieraus einen
korrekten Output–Schedule zu generieren. Dazu kann er für jeden einzelnen
Schritt grundsätzlich eine der drei folgenden Aktionen ausführen:
1. ausführen (execute): möglich für r, w, a, c; der Schritt wird an den
Output–Schedule angehängt.
2. zurückweisen (reject): möglich für r, w; die betreffende Transaktion
wird abgebrochen, also wird ein a an den Output–Schedule angehängt.
3. verzögern (delay): möglich für r, w; der Schritt wird als derzeit nicht
ausführbar an den TM zurückgegeben.
Prof. Dr. Dietmar Seipel
514
Vorlesung Datenbanken
Wintersemester 2013/14
Der Daten–Manager (DM) führt die Schritte des (korrekten)
Output–Schedules der Reihe nach aus:
• r liest ein Datenobjekt aus der Datenbank in den Puffer.
• w schreibt ein Datenobjekt in die Datenbank oder in den Puffer.
• c macht das Ergebnis der Transaktion permanent.
• a macht die Transaktion durch geeignete Recovery–Maßnahmen
ungeschehen.
Prof. Dr. Dietmar Seipel
515
Vorlesung Datenbanken
Wintersemester 2013/14
... Transaktionen ...
Transaktions-Manager
Input-Schedule
Scheduler
r, w, a, c
BOT/EOT
commit(s)
abort(s)
active(s)
trans(s)
korrekter Output-Schedule s
Data-Manager
Recovery-Manager
Puffer-Manager
Datenbank
Komponenten der Transaktionsverarbeitung in einem DBMS.
Prof. Dr. Dietmar Seipel
516
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (aggressiv, konservativ)
Ein Scheduler heißt
1. aggressiv, falls er überwiegend durchläßt, d.h. nur selten verzögert.
Hier besteht die Gefahr, daß er irgendwann festhängt (Deadlock).
2. konservativ, falls er überwiegend verzögert.
Im Extermfall wird der Output–Schedule dabei seriell,
wenn immer alle Transaktionen bis auf eine verzögert werden.
Definition (Sicherheit von Schedules)
Ein Scheduler S heißt
1. s–sicher, falls E(S) ⊆ CSR,
2. f–sicher, falls E(S) ⊆ ST ,
3. sicher, falls E(S) ⊆ CSR ∩ ST ,
wobei E(S) die Menge aller von S als Output erzeugbaren Schedules ist.
Prof. Dr. Dietmar Seipel
517
Vorlesung Datenbanken
Wintersemester 2013/14
4.2.1 Das Zwei–Phasen–Sperrprotokoll
Zur Synchronisation des Zugriffs verschiedener Transaktionen auf
gemeinsam benutzte Daten werden Sperren (Locks) verwendet,
welche auf Datenobjekte gesetzt bzw. wieder aufgegeben werden können.
Definition (Sperren)
Sei X ein Datenobjekt und ti eine Transaktion. Dann bezeichnet
rli (X) eine Lese–Sperre (read lock) und
wli (X) eine Schreib–Sperre (write lock)
von ti auf X. Das Rücksetzen (Aufheben) von Sperren erfolgt mit
rui (X) für Lese–Sperren (read unlock) bzw.
wui (X) für Schreib–Sperren (write unlock).
Prof. Dr. Dietmar Seipel
518
Vorlesung Datenbanken
Wintersemester 2013/14
Ein sperrender Scheduler macht aus jeder Transaktion formal eine um
Sperr–Operationen erweiterte Transaktion (locked transaction).
Beispiel (Sperren, Locked Transaction)
Im folgenden Schedule s wurde jede Daten–Operation pi (X) um
entsprechende Sperren zu pli (X) pi (X) pui (X) zu s′ erweitert:
s
=
r1 (X) w2 (X) w2 (Y ) c2 w1 (Y ) c1 ,
s′
=
rl1 (X) r1 (X) ru1 (X) wl2 (X) w2 (X) wu2 (X)
wl2 (Y ) w2 (Y ) wu2 (Y ) c2 wl1 (Y ) w1 (Y ) wu1 (Y ) c1 .
Der resultierende Schedule s′ ist nach dem Zwei–Phasen–Sperrprotokol aber
nicht erlaubt, da t1 mittels ru1 (X) die Lese–Sperre auf X freigibt und
mittels wl1 (Y ) später noch eine Schreib–Sperre auf Y anfordert –
analoges gilt für wu2 (X) und wl2 (Y ).
Prof. Dr. Dietmar Seipel
519
Vorlesung Datenbanken
Wintersemester 2013/14
Definition (Sperrprotokoll)
Ein Scheduler arbeitet nach einem Sperrprotokoll, falls für jeden Output s
und jede Transaktion ti ∈ trans(s) gilt:
1. pi (X) ∈ s für p ∈ { r, w } =⇒ pli (X) <s pi (X) <s pui (X).
2. Auf jedem Datenobjekt werden Sperren derselben Art von jeder
Transaktion höchstens einmal gesetzt,
d.h. s enthält höchstens einen Schritt rli (X) bzw. wli (X).
3. Kein lock/unlock–Schritt ist redundant.
4. Ist ein Datenobjekt X durch zwei verschiedene Transaktionen ti und tj
an einer Stelle von s gesperrt, so sind diese Sperren nicht in Konflikt.
rli (X) wli (X)
Prof. Dr. Dietmar Seipel
Kompatibilitäts–Matrix:
rlj (X)
+
−
+ bedeutet kein Konflikt
wlj (X)
−
−
– bedeutet Konflikt
520
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiele (Sperrprotokoll)
1. Der folgende Schedule s ist nach dem Sperrprotokoll erlaubt:
s = rl1 (X) r1 (X) rl2 (X) r2 (X) ru2 (X) wl1 (Y ) ru1 (X) w1 (Y ) wu1 (Y ).
Die Lesesperren rl1 (X) und rl2 (X) sind kompatibel.
Dadurch kann t2 verschränkt mit t1 nach r1 (X) schon r2 (X) ausführen.
Z.B. kann t2 die Wartezeit ausnutzen, die ensteht falls t1 noch auf etwas
warten muß, bevor es w1 (Y ) ausführen kann.
2. Der folgende Schedule s′ ist nach dem Sperrprotokoll nicht erlaubt:
s′ = wl1 (X) w1 (X) rl2 (X) r2 (X) ru2 (X) wl1 (Y ) wu1 (X) w1 (Y ) wu1 (Y ).
Die Schreibsperre wl1 (X) (anstelle von rl1 (X) verglichen mit oben)
und die Lesesperre rl2 (X) sind nicht kompatibel.
Prof. Dr. Dietmar Seipel
521
Vorlesung Datenbanken
Wintersemester 2013/14
3. Man könnte versuchen, s′ zu korrigieren, indem man wu1 (X) vor
rl2 (X) einschiebt, da dann die Schreibsperre wl1 (X) nicht meht aktiv
ist, wenn die Lesesperre rl2 (X) erfolgt:
s′ = wl1 (X) w1 (X) wu1 (X) rl2 (X) r2 (X) ru2 (X) wl1 (Y ) w1 (Y ) wu1 (Y ).
Die entstandene direkte Einklammerung von Aktionen mit den
entsprechenden Sperr– und Entsperrschritten ist aber bei dem folgenden
2PL–Scheduling nicht erlaubt, da der Sperrschritt wl1 (Y ) erfolgt
nachdem mit wu1 (X) bereits die Entsperrphase von t1 begonnen hat.
Offensichtlich wäre die angedeutete naive, direkte Einklammerung
pli (X) pi (X) pui (X) von Aktionen pi (X) mit den entsprechenden Sperr–
und Entsperrschritten für jeden Schedule möglich.
Um die bekannten Probleme bei der Verwaltung paralleler Transaktionen zu
lösen muß man weitere Bedingungen – siehe 2PL–Scheduling – stellen.
Prof. Dr. Dietmar Seipel
522
Vorlesung Datenbanken
Wintersemester 2013/14
In kommerziellen Systemen wird am häufigsten das
Zwei–Phasen–Sperrprotokoll (2PL) verwendet.
Definition (2PL, Two–Phase Locking)
2PL. Ein Sperrprotokoll heißt zweiphasig, falls für jeden erzeugten
Schedule s und jede Transaktion ti ∈ trans(s) gilt: nach dem ersten
Entsperrschritt pui (X) erfolgt kein weiterer Sperrschritt qli (Y ),
p, q ∈ { r, w }. Ein entsprechender Scheduler heißt 2PL–Scheduler.
C2PL. Ein 2PL–Scheduler heißt C2PL–Scheduler (konservativer oder
statischer 2PL–Scheduler), falls jede Transaktion vor ihrer ersten
Datenoperation ri (X) oder wi (X) alle benötigten Sperren setzt.
S2PL. Ein 2PL–Scheduler heißt S2PL–Scheduler (strenger oder
dynamischer 2PL–Scheduler), falls jede Transaktion alle von ihr
gehaltenen Sperren erst nach ihrer letzten Datenoperation freigibt.
Prof. Dr. Dietmar Seipel
523
Vorlesung Datenbanken
Wintersemester 2013/14
2 Phasen: Beim 2PL kann man jede Transaktion unterteilen in
1. eine Wachstumsphase, in der Sperren gesetzt, und
2. eine Schrumpfphase, in der Sperren freigegeben
werden können. In beiden Phasen können auch Datenoperationen ausgeführt
werden. Bei C2PL bzw. S2PL werden in der Wachstums– bzw. der
Schrumpf–Phase keine Datenoperationen ausgeführt.
Commit: Vor dem erfolgreichen Abschluß einer Transaktion t muß
sichergestellt werden, daß alle Transaktionen t′ , von denen t gelesen hat,
bereits erfolgreich abgeschlossen wurden.
Eigenschaften
2PL erzeugt konflikt–serialisierbare, d.h. s–sichere, Schedules,
C2PL erzeugt deadlock–freie Schedules,
S2PL erzeugt strikte, und damit auch sichere, Schedules.
Prof. Dr. Dietmar Seipel
524
Vorlesung Datenbanken
Wintersemester 2013/14
Wachstumsphase und Schrumpfphase beim 2PL–Scheduling
Sperren
6
Wachstumsphase
Schrumpfphase
Zeit
2PL:
Sperren
Sperren
6
Zeit
C2PL: Sperren ab BOT (Begin of Trans.)
Prof. Dr. Dietmar Seipel
6
Zeit
S2PL: Sperren bis EOT (End of Trans.)
525
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiele (2PL)
1. Der Schedule s′ von oben ist nicht zwei–phasig, denn
ru1 (X) <s′ wl1 (Y ) und wu2 (X) <s′ wl2 (Y ):
s′
=
rl1 (X) r1 (X) ru1 (X) wl2 (X) w2 (X) wu2 (X)
wl2 (Y ) w2 (Y ) wu2 (Y ) c2 wl1 (Y ) w1 (Y ) wu1 (Y ) c1 .
In einem zwei–phasigen Schedule kann t1 den unlock ru1 (X) erst nach
wl1 (Y ) ausführen, und erst dann kann t2 mit wl2 (X) starten.
Mit wl2 (Y ) muß t2 bis nach wu1 (Y ) warten.
2. Wenn man w2 (Y ) und w1 (Y ) vertauscht, so wird der folgende
nicht–serielle, zwei–phasige Schedule möglich:
s′′
=
rl1 (X) r1 (X) wl1 (Y ) ru1 (X) wl2 (X) w2 (X)
w1 (Y ) wu1 (Y ) c1 wl2 (Y ) wu2 (X) w2 (Y ) wu2 (Y ) c2 .
Prof. Dr. Dietmar Seipel
526
Vorlesung Datenbanken
Wintersemester 2013/14
3. Wir betrachten die beiden Transaktionen t1 = r1 (X) w1 (Y ) und
t2 = w2 (Y ) w2 (X). Dann kann der Schedule
s′′ = rl1 (X) r1 (X) wl2 (Y ) w2 (Y )
von einem 2PL–Scheduler nicht fortgesetzt werden.
Hier wartet t1 auf t2 wegen Y und t2 auf t1 wegen X (Deadlock).
Ein C2PL–Scheduler könnte s′′ nicht aus t1 und t2 erzeugen.
Ein S2PL–Scheduler könnte s′′ auch erzeugen.
4. Der Schedule s′′′ ist zwar zwei–phasig:
s′′′ = rl1 (X) r1 (X) wl1 (Y ) ru1 (X) w1 (Y ) wu1 (Y ),
aber wegen ru1 (X) <s′′′ w1 (Y ) nicht streng zwei–phasig.
s′′′′ = rl1 (X) r1 (X) wl1 (Y ) w1 (Y ) ru1 (X) wu1 (Y )
ist streng zwei–phasig.
Prof. Dr. Dietmar Seipel
527
Vorlesung Datenbanken
Wintersemester 2013/14
Satz (Zwei–Phasen–Scheduler)
1. Ein 2PL–Scheduler ist s–sicher: E(2PL) ( CSR.
2. Ein S2PL–Scheduler ist sicher: E(S2PL) ⊆ CSR ∩ ST .
Beispiel (Echte Inklusion)
s = w1 (X) r2 (X) c2 r3 (Y ) c3 w1 (Y ) c1 .
Dann gilt s ∈ CSR wegen s ≈c t3 c3 t1 c1 t2 c2 . Die beiden Schedules
s′ = wl1 (X) w1 (X) wu1 (X) rl2 (X) r2 (X) ru2 (X) c2
rl3 (Y ) r3 (Y ) ru3 (Y ) c3 ,
s′′ = wl1 (X) w1 (X) wl1 (Y ) wu1 (X) rl2 (X) r2 (X) ru2 (X) c2
können von einem 2PL–Scheduler aber nicht komplettiert werden.
Prof. Dr. Dietmar Seipel
528
Vorlesung Datenbanken
Wintersemester 2013/14
• Zwischen w1 (X) und r2 (X) müssen wu1 (X) und rl2 (X) stehen.
• Wenn man – wie in s′ – wl1 (Y ) nicht vor wu1 (X) ausführt,
dann kann man den Lock später nicht mehr bekommen.
Deswegen kann w1 (Y ) nun nicht ausgeführt werden.
• Wenn man – wie in s′′ – wl1 (Y ) vor wu1 (X) ausführt,
dann kann der Lock rl3 (Y ) nicht erfolgen.
Da andererseits wu1 (Y ) natürlich nicht vor w1 (Y ) erfolgen kann,
kann rl3 (Y ) und damit auch r3 (Y ) nun nicht ausgeführt werden.
s ist überhaupt nicht von einem 2PL–Scheduler erzeugbar:
s 6∈ E(2PL).
Prof. Dr. Dietmar Seipel
529
Vorlesung Datenbanken
Wintersemester 2013/14
4.2.2 Deadlocks
Definition (Wartegraph)
Der Wartegraph WG(s) = (V, E) eines Schedules ist gegeben durch
V = active(s),
E = { (ti , tj ) ∈ V | ti wartet darauf, ein Datenobjekt zu sperren,
welches von tj gesperrt ist }.
Am Ende von s liegt ein Deadlock vor, falls WG(s) zyklisch ist.
Dann wartet eine Menge T von Transaktionen wechselseitig auf die Freigabe
der von anderen Transaktionen aus T gehaltenen Sperren.
Beispiel (Deadlock)
s = rl1 (X) r1 (X) wl2 (Y ) w2 (Y ) wl1 (Y ) wl2 (X)
|
{z
}
gewünscht
Prof. Dr. Dietmar Seipel
t1
t
2
530
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Deadlock im Straßenverkehr)
Das rote Auto 1 möchte über die Route (C, D, E, F, G, H) nach H fahren,
das blaue Auto 2 über (F, E, D, C, B, A) nach A.
Sie treffen sich an zwei Hindernissen und blockieren sich gegenseitig: das
rote Auto 1 möchte von D nach E fahren, das blaue Auto 2 von E nach D.
1
A
?
C
B
D
E
G
F
6
2
H
Prof. Dr. Dietmar Seipel
D- E
531
Vorlesung Datenbanken
Wintersemester 2013/14
Wenn die Autos sich wie beim 2PL–Scheduling verhalten, dann möchte
keiner zurückfahren:
1. das rote Auto 1 möchte E sperren und kann seine Sperre auf D nicht
hergeben, da es nachher noch weitere Sperren auf F, G, . . . benötigt, und
2. das blaue Auto 2 möchte D sperren und kann seine Sperre auf E nicht
hergeben, da es nachher noch weitere Sperren auf C, B, . . . benötigt.
Es wäre ein Deadlockzustand erreicht.
Beim konservativen C2PL–Scheduling würde ein Auto dagegen erst
losfahren, wenn seine gesamte Fahrtroute für andere Autofahrer gesperrt ist.
Damit könnte ein solcher Deadlock nicht auftreten. Der Durchsatz wäre bei
einem solchen – im Straßenverkehr unrealistischen – Vorgehen allerdings
sehr viel geringer, da auf vielen Routen nur ein Auto unterwegs wäre.
Prof. Dr. Dietmar Seipel
532
Vorlesung Datenbanken
Wintersemester 2013/14
Die Fahrtrouten entsprechen Transaktionen:
t1 = w1 (C) w1 (D) w1 (E) w1 (F ) w1 (G) w1 (H),
t2 = w2 (F ) w2 (E) w2 (D) w2 (C) w2 (B) w2 (A).
Zum Zeitpunkt des Aufeinandertreffens könnte ein 2PL–Scheduler den
folgenden, verschränkten Schedule abgearbeitet haben:
s
=
wl1 (C) w1 (C) wl2 (F ) w2 (F ) wl1 (D) w1 (D) wl2 (E) w2 (E).
Jetzt liegt ein Deadlock vor, da t1 die Sperre wl1 (E) setzen möchte, obwohl
t2 bereits E sperrt, und da t2 die Sperre wl2 (D) setzen möchte, obwohl t1
bereits D sperrt.
Ein konservativer C2PL–Scheduler würde die Transaktionen dagegen seriell
(erst t1 , dann t2 , oder umgekehrt) abarbeiten und keinen Deadlock erzeugen.
Prof. Dr. Dietmar Seipel
533
Vorlesung Datenbanken
Wintersemester 2013/14
Deadlock–Verhinderung mit Zeitstempeln
Eine Transaktion ti erhält einen Transaktionszeitstempel TS (ti ),
welcher der Startzeit von ti entspricht:
falls ti vor tj startet, so gilt TS (ti ) < TS (tj ).
Annahme: ti versucht ein Datenobjekt zu sperren,
welches schon von tj gesperrt ist.
wait–die: Falls TS (ti ) < TS (tj ), d.h. falls ti älter als tj ist,
dann soll ti warten dürfen; andernfalls wird ti abgebrochen.
wound–wait: Falls TS (ti ) < TS (tj ),
dann wird tj abgebrochen; andernfalls darf ti warten.
Beide Verfahren begünstigen Transaktion, die schon lange laufen, und von
denen man somit annimmt, daß sie bereits viel Arbeit erledigt haben.
Prof. Dr. Dietmar Seipel
534
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Deadlock–Verhinderung im Straßenverkehr)
In unserem Straßenverkehrs–Beispiel würde für den verschränkten Schedule
s
=
wl1 (C) w1 (C) wl2 (F ) w2 (F ) wl1 (D) w1 (D) wl2 (E) w2 (E)
dann mit der Folge wl1 (E) wl2 (D) von Sperranfragen so verfahren:
• t1 versucht das Datenobjekt E zu sperren, welches schon von t2 gesperrt
ist. Die wait–die–Methode würde die Transaktion t1 zum roten Auto,
das früher losgefahren ist, warten lassen.
• Danach versucht t2 das Datenobjekt D zu sperren, welches schon von t1
gesperrt ist. wait–die würde die blaue Transaktion t2 nun abbrechen.
• Die wound–wait–Methode würde die Transaktion t2 sofort abbrechen.
Somit hätten in unserem konkreten Beispiel eines bereits vorhandenen
Deadlocks beide Verfahren denselben Effekt.
Prof. Dr. Dietmar Seipel
535
Vorlesung Datenbanken
Wintersemester 2013/14
Falls das blaue Auto 2 stattdessen in E nach I abbiegen möchte, so liegt
eigentlich kein Deadlock vor, und es wäre nicht nötig t2 abzubrechen:
1
A
?
C
B
D
E
G
F
6
2
H
I
D- E
-
Das rote Auto 1 möchte über die Route (C, D, E, F, G, H) nach H fahren,
das blaue Auto 2 über (F, E, I) nach I.
Sie treffen sich an zwei Hindernissen, und das blaue Auto blockiert das rote
eigentlich nur vorübergehend, da es nach I abbiegen möchte.
Prof. Dr. Dietmar Seipel
536
Vorlesung Datenbanken
Wintersemester 2013/14
Der verschränkte Schedule
s
=
wl1 (C) w1 (C) wl2 (F ) w2 (F ) wl1 (D) w1 (D) wl2 (E) w2 (E)
kann dann mit der Folge wl1 (E) wl2 (I) von Sperranfragen so verfahren:
• Jetzt versucht t1 das Datenobjekt E zu sperren, welches schon von t2
gesperrt ist, aber nicht umgekehrt.
• Die wait–die–Methode würde die Transaktion t1 zum roten Auto, das
früher losgefahren ist, warten lassen. Da das blaue Auto dann nach I
abbiegt, löst sich das Problem auf, sobald t2 seine Sperren freigibt.
• Die wound–wait–Methode würde die Transaktion t2 dagegen sofort und
unnötigerweise abbrechen.
Somit hätten in unserem modifizierten Beispiel beide Verfahren
unterschiedliche Effekte.
Prof. Dr. Dietmar Seipel
537
Vorlesung Datenbanken
Wintersemester 2013/14
4.2.3 Zeitstempelverfahren
Ein Zeitstempel TS (t) ist ein eindeutiger Identifikator,
welcher vom DBMS kreiert wird für eine Transaktion t.
Die Ordnung der Zeitstempel leitet sich von den Startzeiten der
Transaktionen ab.
Für jedes Datenobjekt X werden zwei Zeitstempel gehalten:
read_TS (X):
Der Lese–Zeitstempel ist der größte Zeitstempel TS (t) unter allen
Transaktionen t, welche X erfolgreich gelesen haben.
write_TS (X):
Der Schreib–Zeitstempel ist der größte Zeitstempel TS (t) unter allen
Transaktionen t, welche X erfolgreich geschrieben haben.
Prof. Dr. Dietmar Seipel
538
Vorlesung Datenbanken
Wintersemester 2013/14
Beim Datenzugriff auf ein Datenobjekt X wird getestet,
ob die Zeitstempelordnung verletzt wird:
1. Transaktion ti führt eine Schreiboperation wi (X) aus:
a) Falls read_TS (X) > TS (ti ) oder write_TS (X) > TS (ti ),
so breche ti ab, denn eine spätere Transaktion hat bereits auf X
zugegriffen.
b) Ansonsten führe die Schreiboperation aus und setze
write_TS (X) := TS (ti ).
2. Transaktion ti führt eine Leseoperation ri (X) aus:
a) Falls write_TS (X) > TS (ti ), so breche ti ab, denn eine spätere
Transaktion hat bereits den gewünschten Wert von X überschrieben.
b) Ansonsten führe die Leseoperation aus und setze
read_TS (X) := max { TS (ti ), read_TS (X) }.
Prof. Dr. Dietmar Seipel
539
Vorlesung Datenbanken
Wintersemester 2013/14
Diese Vorgehensweise wird als Basis–TO–Algorithmus bezeichnet
(TO für timestamp ordering).
Wenn zwei Operationen in Konflikt stehen und in der falschen Reihenfolge
ausgeführt werden sollen, dann wird die spätere der beiden zurückgewiesen
und die zugehörige Transaktion abgebrochen.
Eigenschaften
1. Die erzeugten Schedules sind konflikt–serialisierbar,
und der zugehörige serielle Schedule ergibt sich jeweils aus der Ordnung
der Zeitstempel.
2. Das Verfahren garantiert nicht die Vermeidung kaskadierender Aborts
(ACA).
Prof. Dr. Dietmar Seipel
540
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Lost Update)
s2 :
T1
T2
read_TS (X) = write_TS (X) = 0
r1 (X);
TS (T1 ) = 1, read_TS (X) = 1
X := X − N ;
r2 (X);
TS (T2 ) = 3, read_TS (X) = 3
X := X + M ;
w1 (X);
read_TS (X) = 3 > 1 = TS (T1 )
r1 (Y );
w2 (X);
Y := Y + N ;
w1 (Y );
Bei der Operation w1 (X) wird die Transaktion T1 abgebrochen,
denn die spätere Transaktion T2 hat bereits auf X zugegriffen.
Prof. Dr. Dietmar Seipel
541
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (Incorrect Summary)
T1
T3
read_TS (. . . ) = write_TS (. . . ) = 0
sum := 0;
TS (T3 ) = 1
r3 (A);
read_TS (A) = 1
sum := sum + A;
r1 (X);
TS (T1 ) = 4, read_TS (X) = 4
X := X − N ;
w1 (X);
write_TS (X) = 4
r3 (X);
.
.
.
write_TS (X) = 4 > 1 = TS (T3 )
sum := sum + X;
.
.
.
Bei der Operation r3 (X) wird die Transaktion T3 abgebrochen, denn die
spätere Transaktion T1 hat bereits den gewünschten Wert von X überschrieben.
Prof. Dr. Dietmar Seipel
542
Vorlesung Datenbanken
Wintersemester 2013/14
TO–Thomas–Algorithmus
Man kann die Schreibregel von Thomas verwenden, um mehr Parallelität zu
erreichen:
1’. Transaktion ti führt eine Schreiboperation wi (X) aus:
a) Falls read_TS (X) > TS (ti ), so breche die Transaktion ab.
Eine spätere Transaktion hat X bereits gelesen.
b) Falls write_TS (X) > TS (ti ), so ignoriere die Schreiboperation
einfach. Eine spätere Transaktion hat X bereits überschrieben, und
die Schreiboperation ist somit irrelevant.
c) Ansonsten führe die Schreiboperation aus und setze
write_TS (X) := TS (ti ).
Hier wird lediglich eine spezielle Art von View–Serialisierbarkeit garantiert.
Die N P–Vollständigkeit des VSR–Tests ist hier kein Problem, da
TO–Thomas einen VSR–Schedule erzeugt, ohne ihn testen zu müssen.
Prof. Dr. Dietmar Seipel
543
Vorlesung Datenbanken
Wintersemester 2013/14
Beispiel (View Serialisierbarkeit)
T1
T2
read_TS (X) = write_TS (X) = 0
r1 (X);
TS (T1 ) = 1, read_TS (X) = 1
w2 (X);
w1 (X);
TS (T2 ) = 2, write_TS (X) = 2
write_TS (X) = 2 > 1 = TS (T1 )
1. Die Operation w1 (X) wird ignoriert, da die spätere Transaktion T2 den
Wert von X bereits überschrieben hat – die Schreiboperation ist somit
irrelevant.
2. Das System führt also den Schedule s = r1 (X) w2 (X) w1′ (X) aus,
bei dem w1′ (X) ohne Effekt bleibt.
3. s ist view–äquivalent zum Schedule s′ = r1 (X) w1 (X) w2 (X).
Prof. Dr. Dietmar Seipel
544
Vorlesung Datenbanken
Wintersemester 2013/14
Eigenschaften
Zeitstempelverfahren sind deadlock–frei.
Allerdings kann es dazu kommen, daß Transaktionen immer wieder
abgebrochen und neu gestartet werden (→ Verhungern, starvation).
Strikte CSR–Schedules
Außerdem kann der Basis–TO–Algorithmus auch so modifiziert werden,
daß er strikte CSR–Schedules erzeugt:
Führt eine Transaktion ti eine Schreiboperation wi (X) oder eine
Leseoperation ri (X) aus mit TS (ti ) > write_TS (X),
so wird die Operation bis nach dem Commit bzw. Abort derjenigen
Transaktion, welche X zuletzt geschrieben hat, verzögert.
Prof. Dr. Dietmar Seipel
545
Vorlesung Datenbanken
Wintersemester 2013/14
4.2.4 Mehrversionen–Scheduling–Verfahren
Hier werden mehrere Versionen der Datenobjekte gehalten
(→ erhöhter Speicherbedarf).
• Dadurch können Leseoperationen, welche sich auf frühere Versionen
beziehen, immer noch ausgeführt werden.
• Man arbeitet hier mit View–Serialisierbarkeit und erreicht dadurch mehr
Parallelität.
• Die Versionen eines Datenobjekts stellen seine Entwicklungsgeschichte
dar.
• Im Extremfall hat man es mit temporalen Datenbanken (vgl.
Börsencharts) zu tun.
Prof. Dr. Dietmar Seipel
546
Vorlesung Datenbanken
Wintersemester 2013/14
Mehrversionen–Zeitstempelverfahren (kein ACA)
Zu jedem Datenobjekt X werden mehrere
Versionen X1 , . . . , Xk
gehalten zusammen mit folgenden Zeitstempeln:
read_TS (Xi ):
Der Lese–Zeitstempel ist der größte Zeitstempel TS (t) unter allen
Transaktionen t, welche Xi erfolgreich gelesen haben.
write_TS (Xi ):
Der Schreib–Zeitstempel ist der größte Zeitstempel TS (t) unter allen
Transaktion t, welche Xi erfolgreich geschrieben haben.
Prof. Dr. Dietmar Seipel
547
Vorlesung Datenbanken
Wintersemester 2013/14
Beim Datenzugriff einer Transaktion ti auf X wird diejenige Version Xm ,
mit 1 ≤ m ≤ k, gewählt, die den höchsten Schreib–Zeitstempel unter allen
Versionen mit write_TS (Xm ) ≤ TS (ti ) hat:
1. Falls ti eine Schreiboperation wi (X) ausführt:
a) Falls read_TS (Xm ) > TS (ti ), so brechen wir ti ab, da die
Transaktion tj mit dem Zeitstempel TS (tj ) = read_TS (Xm )
ansonsten die falsche Version Xm gelesen hätte.
b) Andernfalls kreieren wir eine neue Version Xk+1 von X mit
read_TS (Xk+1 ) = write_TS (Xk+1 ) = TS (ti ).
2. Falls ti eine Leseoperation ri (X) ausführt,
so lesen wir den Wert von Xm und setzen
read_TS (Xm ) := max { read_TS (Xm ), TS (ti ) }.
Man kann also in jedem Fall vergangene Versionen eines Datenobjekts X
lesen. Eine bereits gelesene Version kann man aber nicht mehr überschreiben.
Prof. Dr. Dietmar Seipel
548
Vorlesung Datenbanken
Wintersemester 2013/14
Mehrversionen–Zwei–Phasen–Sperrprotokoll
Zu jedem Datenobjekt X werden zwei Versionen X1 und X2 gehalten:
1. X1 enthält immer einen Wert, der von einer freigegebenen Transaktion
geschrieben wurde.
2. X2 wird kreiert, wenn eine Transaktion ti eine Schreib–Sperre auf X
beantragt.
Dann wird X2 zur lokalen Kopie für ti , und andere Transaktionen
können fortfahren, die freigegebene Version X1 von X zu lesen.
Das Mehrversionen–Zwei–Phasen–Sperrprotokoll garantiert ACA.
Prof. Dr. Dietmar Seipel
549
Vorlesung Datenbanken
Wintersemester 2013/14
Man arbeitet mit folgender Kompatibilitäts–Matrix:
rlj (X)
wlj (X) clj (X)
rli (X)
+
+
−
wli (X)
+
−
−
cli (X)
−
−
−
1. Will eine Transaktion ti freigegeben werden, so muß sie eine
Zertifizierungs–Sperre (certify lock) cli (X) für alle Datenobjekte X
beantragen, für welche sie eine Schreib–Sperre wli (X) hält.
2. Erst wenn ti alle erforderlichen Zertifizierungs–Sperren erhalten hat,
kann ti freigegeben werden.
Dies vermeidet kaskadierende Aborts, Deadlocks können auftreten.
Prof. Dr. Dietmar Seipel
550
Vorlesung Datenbanken
Wintersemester 2013/14
4.3 Recovery
Das Ziel ist die fehlertolerante Verarbeitung von Transaktionen.
Man kann sich 3 Fehlerklassen vorstellen:
1. Transaktionsfehler: Eine Transaktion erreicht ihren Commit–Punkt
nicht. Gründe dafür können ein Fehler im Programm, aus welchem die
Transaktion resultiert, oder die Verwicklung der Transaktion in einen
Deadlock mit Auswahl derselben als Opfer sein.
Dann muß die Transaktion rückgängig gemacht werden (roll back).
2. Systemfehler: Fehler im DBMS–Code, im Betriebssystem oder in der
Rechner–Hardware mit dem Effekt, daß flüchtiger Speicher
(Hauptspeicher, Datenbankpuffer) verloren geht.
3. Mediafehler: z.B. Headcrashes auf der Platte oder Hardwarefehler im
Betriebssystem mit dem Effekt, daß stabiler Speicher
(Sekundärspeicher) verloren geht.
Prof. Dr. Dietmar Seipel
551
Vorlesung Datenbanken
Wintersemester 2013/14
Update–Konzepte
1. Beim verzögerten Update werden die Änderungen nur im Log–Buch und
im lokalen Arbeitsbereich einer Transaktion ausgeführt.
Zum Commit–Zeitpunkt einer Transaktion wird das Log–Buch auf Platte
geschrieben (force write), und beim nächsten Checkpoint werden auch
die Änderungen aus dem Datenbankpuffer auf Platte (in die Datenbank)
geschrieben.
Bei einem Transaktionsfehler ist also kein UNDO nötig.
2. Beim direkten Update werden die Änderungen im Log–Buch und in der
Datenbank ausgeführt. Hier benötigt man REDO und UNDO.
3. Beim Shadow–Paging werden für geänderte Datenseiten zwei Versionen
verwaltet: die aktuellen Seiten und die alten Seiten (Schattenseiten). Die
Schattenseiten enthalten einen alten, konsistenten Datenbankzustand.
Hier benötigt man kein UNDO.
Prof. Dr. Dietmar Seipel
552
Vorlesung Datenbanken
Wintersemester 2013/14
Recovery
Die Wiederherstellung eines konsistenten Datenbankzustandes nach einem
Fehler erfolgt mit Hilfe des Log–Buches.
1. Nach einem Systemzusammenbruch wird eine alte Version der
Datenbank eingespielt, und die Aktionen der freigegebenen
Transaktionen werden aus dem Log–Buch rekonstruiert (REDO).
2. Bei einem Transaktionsfehler werden die vorgenommenen Aktionen der
fehlerhaften Transaktionen zurückgenommen (UNDO).
Nur Schreiboperationen müssen zurückgenommen werden:
AFIM (after image) → BFIM (before image).
Die Leseoperationen stehen nur im Log–Buch, um Konflikte zu
entdecken.
Prof. Dr. Dietmar Seipel
553