Transaktionen
Aufgabe
x und y seien zwei Konten mit den Kontoständen 1000 bzw. 800. Gegeben seien zudem zwei Transaktionen T1 und T2:
T1: T2:
BOT(T1) BOT(T2)
READ1(x) READ2(x)
Y:=x x:=x+30
WRITE1(Y) WRITE2(x)
X:=x-50 EOT2(T2)
WRITE1(x)
EOT1(T1)
Dabei bedeutet etwa READ1(x) Transaktion 1 liest den Kontostand des Kontos x; x:=x-50 „Vermindere den Kontostand des
Kontos x um 50“ etc. Stellen Sie bei den folgenden Ausschnitten eines Logbandes jeweils fest, ob solche Logbandeinträge überhaupt
möglich sein könne bei einer Datenbank, die mindestens über die LOCK Typen exclusive und share verfügt, und falls es sich um einen
gültigen Logbandeintrag handelt, welche Endzustände die Kontenstände der Konten x, y haben, nachdem die Restart/Recovery- Verfahren
- falls nötig- des DBMS abgeschlossen sind. (Before und Afterimages sind vorhanden)
a1. BOT(T2); READ2(X); BOT(T1); READ1(x); WRITE1(y);
WRITE1(X); EOT(T1); WRITE2(x);……..Transaction Abend
a2. BOT(T2); BOT(T1); READ1(X); READ2(x); WRITE2(x);……..System Crash
a3. BOT(T2); BOT(T1); READ1(X); WRITE1(y); WRITE1(x); READ2(x); EOT(T1);
WRITE2(x); EOT(T2);……..Head Crash
Erläutern Sie mit jeweils einem Beispiel (bezogen auf die Buchstaben A,C,I,D), warum der ACID Forderungskatalog des
Transaktionskonzeptes wichtig ist für eine Datebank!
Im folgenden ist mit Tx(Y) gemeint: Die Transaktion x greift auf den Satz mit Schlüssel Y zu und forderte für diesen Satz eine
exklusive Sperre (Lock) an. EOT(Tx) bedeutet: Transaktion x wird beendet und gibt alle gehaltenen Sperren frei. (Sie können
davon ausgehen, dass vor dem Zeitpunkt 1 keine anderen Transaktionen gegonnen wurden) Folgendes spielt sich ab dem Zeitpunkt 1 ab:
|
Zeitpunkt |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
|
Aktion |
T1(A) |
T2(B) |
T1(C) |
T4(D) |
T5(A) |
T2(E) |
T3(F) |
T2(F) |
EOT(T1) |
T6(A) |
EOT(T5) |
|
Zeitpunkt |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
|
Aktion |
T6(C) |
T7(G) |
T8(H) |
T9(G) |
T8(E) |
EOT(T7) |
T9(H) |
T3(G) |
T10(A) |
EOT(T6) |
T11(C) |
|
Zeitpunkt |
23 |
24 |
25 |
26 |
|
|
|
|
|
|
|
|
Aktion |
T12(D) |
T12(D) |
T12(A) |
T4(G) |
|
|
|
|
|
|
|
Erstellen Sie den Wait_for_Graphen und ermitteln Sie damit, ob es zu irgendeinem Zeitpunkt eine DEADLOCK- Situation gibt?
d1. Warum sollte es mehrere LOG Files geben?
d2. Warum sollte jeder LOG File mindestens einmal (auf ein anderes device) gespiegelt werden?
d3. Erläutern Sie die Aufgabe eines checkpoints!
Lösung:
zu
a1) Transaction 2 Abend
|
|
|
|
|
|
STOP |
|
|
|
|
|
|
S-Lock(x) |
X-Lock(y) |
X-Lock(y) |
|
|
|
BOT(T2) |
Read2(x) |
BOT(T1) |
Read1(x) |
Write1(y) |
Write1(x) |
EOT(T1) |
Write2(x) |
|
|
S-Lock(x) |
|
|
|
|
|
|
Wenn T1 auf y schreiben möchte, setzt es ein X-Lock. Danach möchte T1 auf x schreiben und versucht ein X-Lock zu setzen,
da aber T2 noch ein S-Lock auf die Tabelle x hat, muss T1 solange warten, bis T2 die Tabelle freigibt!
Passiert nun ein Transaction 2 Abend, muss das Redo-Log-File die Transaktion 2 zurücksetzen und die Transaktion 1 neu durchführen.
Kann in einem Logbuch so nicht vorkommen!
zu
a2) System Crash
|
|
|
S-Lock(T1) |
|
|
|
BOT(T2) |
BOT(T1) |
Read1(x) |
Read2(x) |
Write2(x) |
|
|
|
|
S-Lock(T2) |
|
Beide Transactionen wurden nicht beendet und der Zustand vor beiden Transaktionen muss wieder hergestellt werden.
Deshalb müssen beide Transaktionen zurückgesetzt werden.
Kann in einem Logbuch so nicht vorkommen!
zu
a3) Head Crash
|
|
|
S-Lock(x) |
X-Lock(y) |
X-Lock(x) |
|
|
|
|
|
BOT(T2) |
BOT(T1) |
Read1(x) |
Write1(y) |
Write1(x) |
Read2(x) |
EOT(T1) |
Write2(x) |
EOT(T2) |
|
|
|
|
|
|
S-Lock(x) WAIT auf T1(x) |
|
X-Lock(x) |
|
Das READ2 auf x kann erst einmal nicht erfolgen, da auf x noch ein X-Lock von der Transaktion 1 sitzt.
Es wird nun aber ein Wait auf x gesetzt, was nach Beendigung der Transaktion 1 aktiviert wird und somit beide Transaktionen zum Abschluss kommen, bevor der Head Crash passiert. Nun wird das Backup eingespielt und ein Rollfoward dieser Transaktionen wieder aufgespielt!
Kontostand:
|
Ereignisse |
x |
Y |
|
Read 1 (x) Anfangsbestand |
1000 |
800 |
|
Write1 (y) = y:= x |
1000 |
1000 |
|
Write1 (x) = x = x - 50 |
950 |
1000 |
|
EOT 1 |
950 |
1000 |
|
Read 2 (x) |
950 |
1000 |
|
Write 2 (x) = x +30 |
980 |
1000 |
zu b)
A Atomicity Eine Transaktion wird vollständig oder überhaupt nicht ausgeführt!
C Konsistenz Eine Transaktion hält die Integritätsbedingungen stets ein und hinterlässt einen konsistenten Zustand
I Isolation Eine Transaktion läuft stets isoliert ab. Ein Programm erhält nur gesicherte Daten
D Persistenz Falls eine Transaktion als erfolgreich beendet wurde, so überleben diese Daten jeden Crash
zu c)
A T1 , T5 , T6 , T10 , T12
B T2
C T1 , T6 , T11
D T4 , T12
, T12
E T2 , T8
F T3
, T2
G T7 , T9
, T3 , T4
H T8
, T9
T12 T10
T4
T3 T2
T9 T8
zu d1)
Es sollte mehr davon geben, da wenn das Erste voll geschrieben ist, es archiviert wird und dann
auf dem Zweiten weiter geschrieben werden muss, da sonst die Datenbank stehen bleiben würde!
Gehen wir davon aus, das ein Log-File groß genug wäre alle Transaktionen zu speichern, so ist ein Zweites immer als Sicherung da!
zu d2)
Da es auch zu Platten Crashs kommen kann, würde man auch das Log-File verlieren, wenn man es
nicht auf eine andere Platte gespeichert hätte!
zu d3)
Ein Checkpoint hilft bei der Verringerung des Suchaufwandes bei der Rekonstruktion von Daten.
Man kann durch Setzen eines Checkpoints folgende Ereignisse erzwingen, die sehr hilfreich zum schnellen Wiederherstellen der Datensätze sind.
- Inhalt vom Log-Puffer wird in das Log-Buch eingetragen
- Checkpoint Eintrag ins Log-Buch
- Inhalt des Datenbank-Puffers wird in die Datenbank geschrieben
- Die Adresse des Checkpoint Eintrages wird in einem Restart-File gespeichert
Fällt ein System nun aus, so durchsucht der Recovery- Manager das Restart-File nach den jüngsten Records und den passenden Checkpoint Einträgen. Danach durchsucht er das Log-Buch nach zu bearbeitenden UNDO`s oder REDO`s! Hat er solche gefunden spielt er sie auf oder setzt sie zurück.
