Kapitel 10
Dr. Brigitte Mathiak
Transaktionsverwaltung
Lernziele

• Begriff und Eigenschaften von Transaktionen
• Mehrbenutzer-Synchronisation
 Theorie der Serialisierbarkeit
 Zwei-Phasen-Sperrprotokolle
 Deadlocks und deren Vermeidung
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
2
Transaktionsverwaltung

Beispiel einer typischen Transaktion in einer
Bankanwendung:
1. Lese den Kontostand von A in die Variable a : read(A,a);
2. Reduziere den Kontostand um 50 EUR: a:= a – 50;
3. Schreibe den neuen Kontostand in die Datenbasis: write(A,a);
4. Lese den Kontostand von B in die Variable b: read(B,b);
5. Erhöhe den Kontostand um 50 EUR: b := b + 50;
6. Schreibe den neuen Kontostand in die Datenbasis: write(B, b);
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
3
Fehler bei unkontrolliertem Mehrbenutzerbetrieb
Verlorengegangene Änderungen (lost update)
Überweisung
Zinsen
Datenbanken, SS 12
Schritt
T1
1.
read(A,a1)
2.
a1 := a1 – 300
T2
3.
read(A,a2)
4.
a2 := a2 * 1.03
5.
write(A,a2)
6.
write(A,a1)
7.
read(B,b1)
8.
b1 := b1 + 300
9.
write(B,b1)
Kapitel 10: Transaktionsverwaltung
A
B
200
300
206
-100
300
600
4
Operationen auf Transaktions-Ebene
In den klassischen Transaktionssystemen:
 begin of transaction (BOT): Mit diesem Befehl wird der
Beginn einer eine Transaktion darstellende Befehlsfolge
gekennzeichnet.
 commit: Hierdurch wird die Beendigung der Transaktion
eingeleitet. Alle Änderungen der Datenbasis werden durch
diesen Befehl festgeschrieben, d.h. sie werden dauerhaft in die
Datenbank eingebaut.
 abort: Dieser Befehl führt zu einem Selbstabbruch der
Transaktion. Das Datenbanksystem muss sicherstellen, dass die
Datenbasis wieder in den Zustand zurückgesetzt wird, der vor
Beginn der Transaktionsausführung existierte.
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
5
Abschluss einer Transaktion
Für den Abschluss einer Transaktion gibt es zwei
Möglichkeiten:
1. Den erfolgreichen Abschluss durch ein
commit.
2. Den erfolglosen Abschluss durch ein abort.
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
6
Eigenschaften von Transaktionen: ACID
Atomicity (Atomarität)
Alles oder nichts !
Consistency
Konsistenter DB-Zustand muss in konsistenten Zustand übergehen !
Isolation
Jede Transaktion hat die DB „für sich allein“
Durability (Dauerhaftigkeit)
Änderungen erfolgreicher Transaktionen dürfen nie verloren gehen
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
7
Transaktionsverwaltung in SQL
commit work
Die in der Transaktion vollzogenen Änderungen werden – falls keine
Konsistenzverletzung oder andere Probleme aufgedeckt werden –
festgeschrieben.
Schlüsselwort work ist optional
rollback work
Alle Änderungen sollen zurückgesetzt werden.
Anders als der commit-Befehl muss das DBMS die „erfolgreiche“
Ausführung eines rollback-Befehls immer garantieren können.
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
8
Transaktionsverwaltung in SQL
Beispielsequenz auf Basis des Universitätsschemas:
INSERT INTO Vorlesungen
values (5275, 'Kernphysik', 3, 2141);
INSERT INTO Professoren
values (2141, 'Meitner', 'C4', 205);
COMMIT
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
9
Fehler bei unkontrolliertem Mehrbenutzerbetrieb
Verlorengegangene Änderungen (lost update)
Überweisung
Zinsen
Datenbanken, SS 12
Schritt
T1
1.
read(A,a1)
2.
a1 := a1 – 300
T2
3.
read(A,a2)
4.
a2 := a2 * 1.03
5.
write(A,a2)
6.
write(A,a1)
7.
read(B,b1)
8.
b1 := b1 + 300
9.
write(B,b1)
Kapitel 10: Transaktionsverwaltung
A
B
200
300
206
-100
300
600
10
Fehler bei unkontrolliertem Mehrbenutzerbetrieb II
Abhängigkeit von nicht freigegebenen Änderungen
Datenbanken, SS 12
Schritt
T1
1.
2.
read(A,a1)
a1 := a1 – 300
3.
write(A,a1)
T2
4.
read(A,a2)
5.
a2 := a2 * 1.03
6.
write(A,a2)
7.
read(B,b1)
8.
...
9.
abort
Kapitel 10: Transaktionsverwaltung
11
Fehler bei unkontrolliertem Mehrbenutzerbetrieb III
Phantomproblem
T1
T2
select sum(KontoStand)
from Konten
insert into Konten
values (C,1000,...)
select sum(Kontostand)
from Konten
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
12
Der Datenbank-Scheduler
T1
T2
T3
...... Tn
Transaktions-Manager TM
Scheduler
Daten-Manager
Recovery-Manager
Puffer-Manager
Datenbank
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
13
Aufgabe des Schedulers
 Reihung der Operationen verschiedener Transaktionen,
so dass die einzelnen Transaktionen
- Bis zuletzt ohne kaskadierendes Rollback rücksetzbar sind (Atomicity)
- Keine ungültigen Datenzustände erzeugen können (Consistency)
- Die Parallelität zu anderen Transaktionen nicht bemerken (Isolation)
- Committete Änderungen dauerhaft vorliegen (Durability)
 Verschiedene Ansätze möglich:
- sperrbasierte Synchronisation (am meisten benutzt) Pessimistische
Synchronisation
- Zeitstempel-basierte Synchronisation
- optimistische Synchronisation (bei vorwiegend lesenden Zugriffen)
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
14
Sperrbasierte Synchronisation
Sichert Serialisierbarkeit zu
Zwei Sperrmodi
 S (shared, read lock, Lesesperre):
 X (exclusive, write lock, Schreibsperre):
 Verträglichkeitsmatrix (auch Kompatibilitätsmatrix genannt)
Datenbanken, SS 12
NL
S
X
S


-
X

-
-
Kapitel 10: Transaktionsverwaltung
15
Zwei-Phasen-Sperrprotokoll (2PL): Definition
Jedes Objekt, das von einer Transaktion benutzt werden soll, muss vorher
entsprechend gesperrt werden.
Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an.
Eine Transaktion muss die Sperren anderer Transaktionen auf dem von ihr
benötigten Objekt gemäß der Verträglichkeitstabelle beachten. Wenn die
Sperre nicht gewährt werden kann, wird die Transaktion in eine
entsprechende Warteschlange eingereiht – bis die Sperre gewährt werden
kann.
Jede Transaktion durchläuft zwei Phasen:

Eine Wachstumsphase, in der sie Sperren anfordern, aber keine freigeben darf
und

eine Schrumpfphase, in der sie ihre bisher erworbenen Sperren freigibt, aber
keine weiteren anfordern darf.
Bei EOT (Transaktionsende) muss eine Transaktion alle ihre Sperren
zurückgeben.
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
16
Zwei-Phasen Sperrprotokoll: Grafik
#Sperren
Wachstum
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
Schrumpfung
Zeit
17
Verzahnung zweier TAs gemäß 2PL
T1 modifiziert nacheinander die Datenobjekte A und B
(z.B. eine Überweisung)
T2 liest nacheinander dieselben Datenobjekte A und B
(z.B. zur Aufsummierung der beiden Kontostände).
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
18
Verzahnung zweier TAs gemäß 2PL
Schritt
T1
1.
BOT
2.
lockX(A)
3.
read(A)
4.
write(A)
5.
BOT
6.
lockS(A)
7.
lockX(B)
8.
read(B)
9.
unlockX(A)
read(A)
11.
lockS(B)
12.
write(B)
13.
unlockX(B)
15.
Bemerkung
T2 muss warten
T2 wecken
10.
14.
Datenbanken, SS 12
T2
T2 muss warten
T2 wecken
read(B)
commit
16.
unlockS(A)
17.
unlockS(B)
18.
commit
Kapitel 10: Transaktionsverwaltung
19
Strenges Zwei-Phasen Sperrprotokoll
2PL schließt kaskadierendes Rücksetzen nicht aus
Erweiterung zum strengen 2PL:
- alle Sperren werden bis EOT gehalten
- damit ist kaskadierendes Rücksetzen ausgeschlossen
- Verhindert allerdings keine Deadlocks
#Sperren
Wachstumsphase
EOT
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
Zeit
20
Verklemmungen (Deadlocks)
Ein verklemmter Schedule
Schritt
T1
1.
BOT
2.
lockX(A)
T2
3.
BOT
4.
lockS(B)
5.
read(B)
6.
read(A)
7.
write(A)
8.
lockX(B)
9.
10.
Datenbanken, SS 12
Bemerkung
T1 muss warten auf T2
lockS(A)
T2 muss warten auf T1
...
 Deadlock
...
Kapitel 10: Transaktionsverwaltung
21
Verklemmungen

a: können entdeckt und dann aufgelöst

b: oder gleich vermieden werden.
Beides ist u.U. teuer. Mögliche Techniken:
Ad a:
1. Time-Out (Transaktionen, die zu lange warten, werden abortet)
2. Zyklenerkennung (Es wird parallel analysiert wer auf wen wartet
und dann intelligent und gezielt abortet)
Ad b:
3. Preclaiming (Transaktion setzen alle Locks gleich Anfang)
4. Zeitstempel (Man wartet nicht auf jüngere Transaktionen)
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
22
Deadlocks sind fatal für die Performance
Umso mehr Transaktionen pro Zeit stattfinden umso höher ist die
Wahrscheinlichkeit, dass zwei sich gegenseitig locken
Umso aufwändiger ist die Deadlockbehandlung
Umso langsamer wird das System
Ressourcen
Datenbanken, SS 12
-> bis zum Stillstand (ungraceful failure)
Kapitel 10: Transaktionsverwaltung
#Transaktionen
pro Zeit
23
Transaktionspuffer
Es werden nicht mehr Transaktionen gleichzeitig ausgeführt als das
System verkraften kann.
Der Preis sind verschiedene Limitierungen:
•
Bei Überlast werden zunächst Transaktionen später begonnen,
•
dann werden Transaktionen direkt abgewiesen
•
Transaktionen, die zu lange dauern, werden abgebrochen
Ressourcen
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
#Transaktionen
pro Zeit
24
Fazit
Bei Mehrbenutzerbetrieb kann es zu Fehlern kommen
Um das zu vermeiden gibt es Transaktionen
Transaktionen gehorchen dem ACID Prinzip
Diese werden von der Datenbank mit Hilfe von Locks realisiert
Locks können zu Deadlocks führen
Diese müssen erst aufgelöst werden (z.B. mit Zeitstempeln)
Trotzdem ist das schlecht für die Performanz
-> die meisten Datenbanken sind daher sehr konservativ
Datenbanken, SS 12
Kapitel 10: Transaktionsverwaltung
25