12. Transaktionen Beispielszenarien Transaktion ACID

Beispielszenarien
12. Transaktionen
■
Transaktionsbegriff
■
Probleme im Mehrbenutzerbetrieb
■
Serialisierbarkeit
■
Sperrprotokolle zur Synchronisation
■
Isolationsebenen in SQL
■
Platzreservierung für Flüge quasi gleichzeitig aus vielen
Reisebüros
→ Platz könnte mehrfach verkauft werden, wenn
mehrere Reisebüros den Platz als verfügbar
identifizieren
■
überschneidende Kontooperationen einer Bank
■
statistische Datenbankoperationen
→ Ergebnisse sind verfälscht, wenn während der
Berechnung Daten geändert werden
VL Datenbanken I – 12–1
VL Datenbanken I – 12–2
ACID-Eigenschaften
Transaktion
Eine Transaktion ist eine Folge von Operationen (Aktionen), die die Datenbank von einem konsistenten
Zustand in einen konsistenten, eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss.
■
Atomicity (Atomarität):
Transaktion wird entweder ganz oder gar nicht
ausgeführt
■
Consistency (Konsistenz oder auch Integritätserhaltung):
Datenbank ist vor Beginn und nach Beendigung einer
Transaktion jeweils in einem konsistenten Zustand
■
Isolation (Isolation):
Nutzer, der mit einer Datenbank arbeitet, sollte den
Eindruck haben, dass er mit dieser Datenbank alleine
arbeitet
■
Durability (Dauerhaftigkeit / Persistenz):
nach erfolgreichem Abschluss einer Transaktion muss
das Ergebnis dieser Transaktion „dauerhaft“ in der
Datenbank gespeichert werden
Aspekte:
■
Semantische Integrität: Korrekter (konsistenter)
DB-Zustand nach Ende der Transaktion
■
Ablaufintegrität: Fehler durch „gleichzeitigen“ Zugriff
mehrerer Benutzer auf dieselben Daten vermeiden
VL Datenbanken I – 12–3
VL Datenbanken I – 12–4
Kommandos einer Transaktionssprache
■
Beginn einer Transaktion:
Begin-of-Transaction-Kommando BOT (in SQL implizit!)
■
commit: die Transaktion soll erfolgreich beendet werden
■
abort: die Transaktion soll abgebrochen werden
Transaktion: Integritätsverletzung
■
Beispiel:
Übertragung eines Betrages B von einem
Haushaltsposten K1 auf einen anderen Posten K2
◆ Bedingung: Summe der Kontostände der
Haushaltsposten bleibt konstant
◆
■
vereinfachte Notation
Transfer = < K1:=K1-B; K2:=K2+B >;
■
Realisierung in SQL: als Sequenz zweier elementarer
Änderungen ; Bedingung ist zwischen den einzelnen
Änderungsschritten nicht unbedingt erfüllt!
VL Datenbanken I – 12–5
Vereinfachtes Modell für Transaktion
Repräsentation von Datenbankänderungen einer
Transaktion
■
read(A,x): weise den Wert des DB-Objektes A der
Variablen x zu
■
write(x, A): speichere den Wert der Variablen x im
DB-Objekt A
VL Datenbanken I – 12–6
Probleme im Mehrbenutzerbetrieb
■
Inkonsistentes Lesen: Nonrepeatable Read
■
Abhängigkeiten von nicht freigegebenen Daten: Dirty
Read
■
Das Phantom-Problem
■
Verlorengegangenes Ändern: Lost Update
Beispiel einer Transaktion T :
read(A, x); x := x − 200; write(x, A); read(B , y );
y := y + 100; write(y , B );
VL Datenbanken I – 12–7
VL Datenbanken I – 12–8
Nonrepeatable Read
Beispiel für inkonsistentes Lesen
Beispiel:
■
T1
Zusicherung X = A + B + C am Ende der Transaktion T1
■ X
und Y seien lokale Variablen
■ Ti
ist die Transaktion i
■
T2
X := A;
Y := A/2;
A := Y ;
C := C + Y ;
commit;
Integritätsbedingung A + B + C = 0
X := X + B ;
X := X + C ;
commit;
VL Datenbanken I – 12–9
Dirty Read
T1
VL Datenbanken I – 12–10
Das Phantom-Problem
T1
T2
T2
select count (*)
into X
from Mitarbeiter;
read(X );
X := X + 100;
write(X );
insert
into Mitarbeiter
values (M eier, 50000, · · · );
commit;
read(X );
Y := Y + X ;
write(Y );
commit;
update Mitarbeiter
set Gehalt =
Gehalt +10000/X;
commit;
abort;
VL Datenbanken I – 12–11
VL Datenbanken I – 12–12
Lost Update
Einführung in die Serialisierbarkeit
T1
T2
X
read(X );
read(X );
X := X + 1;
X := X + 1;
write(X );
write(X );
T1 : read A; A := A − 10; write A; read B;
B := B + 10; write B;
T2 : read B; B := B − 20; write B; read C;
C := C + 20; write C;
10
10
10
10
11
11
Ausführungsvarianten für zwei Transaktionen:
■
seriell, etwa T1 vor T2
■
„gemischt“, etwa abwechselnd Schritte von T1 und T2
VL Datenbanken I – 12–13
Beispiele für verschränkte Ausführungen
Ausführung 1
T1
T2
read A
A − 10
write A
read B
B + 10
write B
read B
B − 20
write B
read C
C + 20
write C
Ausführung 2
T1
T2
read A
read B
A − 10
B − 20
write A
write B
read B
read C
B + 10
C + 20
write B
write C
Ausführung 3
T1
T2
read A
A − 10
read B
write A
B − 20
read B
write B
B + 10
read C
write B
C + 20
write C
VL Datenbanken I – 12–15
VL Datenbanken I – 12–14
Effekt unterschiedlicher Ausführungen
A
B
C
A+B+C
initialer Wert
10
10
10
30
nach Ausführung 1
nach Ausführung 2
nach Ausführung 3
0
0
0
0
0
20
30
30
30
30
30
50
VL Datenbanken I – 12–16
Serialisierbarkeit
Das Read/Write-Modell
■
Eine verschränkte Ausführung mehrerer Transaktionen heißt serialisierbar, wenn ihr Effekt identisch zum
Effekt einer (beliebig gewählten) seriellen Ausführung
dieser Transaktionen ist.
Transaktion T ist eine endliche Folge von Operationen
(Schritten) pi der Form r(xi ) oder w(xi ):
T = p1 p2 p3 · · · pn mit pi ∈ {r(xi ), w(xi )}
■
Vollständige Transaktion T hat als letzten Schritt
entweder einen Abbruch a oder ein Commit c:
T = p1 · · · p n a
oder
T = p1 · · · pn c.
VL Datenbanken I – 12–17
VL Datenbanken I – 12–18
Schedule
Serieller Schedule
Ein Schedule ist ein Präfix eines vollständigen Schedules.
Ein serieller Schedule s für T ist ein vollständiger Schedule
der folgenden Form:
s := Tρ(1) · · · Tρ(n)
r1 (x)r2 (x)w1 (x) r2 (y)a1 w2 (y)c2
|
{z
}
ein
Schedule
|
{z
}
für eine Permutation ρ von {1, . . . , n}
resultierende serielle Schedules für zwei Transaktionen
T1 := r1 (x)w1 (x)c1 und T2 := r2 (x)w2 (x)c2 :
s1 := r1 (x)w1 (x)c1 r2 (x)w2 (x)c2
|
{z
}|
{z
}
ein vollständiger Schedule
T1
T2
s2 := r2 (x)w2 (x)c2 r1 (x)w1 (x)c1
|
{z
}|
{z
}
T2
VL Datenbanken I – 12–19
T1
VL Datenbanken I – 12–20
Korrektheitskriterium
Konflikte
T1
Ein Schedule s ist korrekt, wenn der Effekt des Schedules s (Ergebnis der Ausführung des Schedules)
äquivalent dem Effekt eines (beliebigen) seriellen
Schedules s0 bzgl. derselben Menge von Transaktionen ist (in Zeichen s ≈ s0 ).
T2
T1
read A
read A
read A
unabhängig von Reihenfolge
T1
Ist ein Schedule s äquivalent zu einem seriellen
Schedule s0 , dann ist s serialisierbar (zu s0 ).
T2
write A
abhängig von Reihenfolge
T2
T1
write A
write A
read A
abhängig von Reihenfolge
T2
write A
abhängig von Reihenfolge
VL Datenbanken I – 12–21
Graphbasierter Test
Konfliktserialisierbarkeit
■
■
VL Datenbanken I – 12–22
Zwei Schedules s und s0 heissen konfliktäquivalent,
wenn die Reihenfolge von zwei in Koflikt stehenden
Operationen in beiden Schedules gleich ist.
andernfalls: unterschiedliche Effekte, z.B.
Konfliktgraph G(s) = (V, E) von Schedule s:
1. Knotenmenge V enthält alle in s vorkommende
Transaktionen
2. Kantenmenge E enthält alle gerichteten Kanten
zwischen zwei in Konflikt stehenden Transaktionen
w1 (x)w2 (x) vs. (w2 (x)w1 (x)
Ein Schedule s ist genau dann konfliktserialisierbar,
wenn s konfliktäquivalent zu einem seriellen Schedule ist.
VL Datenbanken I – 12–23
VL Datenbanken I – 12–24
Zeitlicher Verlauf dreier Transaktionen
T1
T2
Konfliktgraph
T3
G(s):
r(y)
T1
r(u)
r(y)
w(y)
w(x)
w(x)
w(z)
T2
T3
w(x)
s = r1 (y)r3 (u)r2 (y)w1 (y)w1 (x)w2 (x)w2 (z)w3 (x)
VL Datenbanken I – 12–25
Eigenschaften von Konfliktgraph G(s)
VL Datenbanken I – 12–26
Sperrprotokoll
1. Ist s ein serieller Schedule, dann ist der vorliegende
Konfliktgraph ein azyklischer Graph
■
Sichern der Serialisierbarkeit durch exklusiven Zugriff
auf Objekte (Synchronisation der Zugriffe)
2. Für jeden azyklischen Graphen G(s) lässt sich ein
serieller Schedule s0 konstruieren, so daß s
konfliktserialisierbar zu s0 ist (Test bspw. durch
topologisches Sortieren)
■
Implementierung über Sperren und Sperrprotokolle
■
Sperrprotokoll garantiert Konfliktserialisierbarkeit ohne
zusätzliche Tests!
3. Enthält ein Graph Zyklen, dann ist der zugehörige
Schedule nicht konfliktserialisierbar
VL Datenbanken I – 12–27
VL Datenbanken I – 12–28
Sperrmodelle
Kompatibilitätsmatrix
Schreib- und Lesesperren in folgender Notation:
■ rl(x):
■ wl(x):
■
für elementare Sperren
Lesesperre (engl. read lock) auf einem Objekt x
Schreibsperre (engl. write lock) auf einem Objekt
rlj (x)
wlj (x)
x
rli (x) wli (x)
√
—
—
—
Entsperren ru(x) und wu(x), oft zusammengefaßt u(x) für
engl. unlock
VL Datenbanken I – 12–29
Sperrdisziplin
Verklemmungen
■
Schreibzugriff w(x) nur nach Setzen einer Schreibsperre
wl(x) möglich
■
Lesezugriffe r(x) nur nach rl(x) oder wl(x) erlaubt
■
nur Objekte sperren, die nicht bereits von einer anderen
Transaktion gesperrt
■
■
■
VL Datenbanken I – 12–30
nach rl(x) nur noch wl(x) erlaubt, danach auf x keine
Sperre mehr; Sperren derselben Art werden maximal
einmal gesetzt
nach u(x) durch ti darf ti kein erneutes rl(x) oder wl(x)
ausführen
t1
wl(x)
t2
wl(y)
delay → wl(y)
wl(x)
Verklemmung!
← delay
Alternativen:
■
Verklemmungen werden erkannt und beseitigt
■
Verklemmungen werden von vornherein vermieden
vor einem commit müssen alle Sperren aufgehoben
werden
VL Datenbanken I – 12–31
VL Datenbanken I – 12–32
Verklemmungserkennung und -auflösung
Wartegraph
6
5
T1
4
2
wl(x)
w(x)
u(x)
wl(y)
w(y)
u(y)
3
Auflösen durch Abbruch einer Transaktion, Kriterien:
■
Anzahl der aufgebrochenen Zyklen,
■
Länge einer Transaktion,
■
Rücksetzaufwand einer Transaktion,
■
Wichtigkeit einer Transaktion, ...
T2
wl(x)
w(x)
u(x)
neue
Sperre
1
Sperrprotokolle: Notwendigkeit
wl(y)
w(y)
u(y)
VL Datenbanken I – 12–33
#Sperren
Zwei-Phasen-Sperr-Protokoll
VL Datenbanken I – 12–34
Konflikt bei Nichteinhaltung des 2PL
T1
2PL
AnforderungsPhase
T2
u(x)
wl(x)
wl(y)
..
.
FreigabePhase
u(x)
u(y)
Zeit
VL Datenbanken I – 12–35
wl(y)
..
.
VL Datenbanken I – 12–36
S2PL
#Sperren
Konservatives 2PL-Protokoll
#Sperren
#Sperren
Striktes Zwei-Phasen-Sperr-Protokoll
C2PL
CS2PL
FreigabePhase
Zeit
Zeit
AnforderungsPhase
AnforderungsPhase
AnforderungsPhase
FreigabePhase
vermeidet Deadlocks!
Zeit
Freigabe-Phase
vermeidet kaskadierende Abbrüche!
VL Datenbanken I – 12–37
VL Datenbanken I – 12–38
Bedeutung der Isolationsebenen
Transaktionen in SQL-DBS
Aufweichung von ACID in SQL-92: Isolationsebenen
set transaction
[ { read only | read write }, ]
[isolation level
{ read uncommitted |
read committed |
repeatable read |
serializable }, ]
[ diagnostics size ...]
Standardeinstellung:
■
read uncommitted
◆ schwächste Stufe: Zugriff auf nicht geschriebene
Daten, nur für read only Transaktionen
◆ statistische und ähnliche Transaktionen (ungefährer
Überblick, nicht korrekte Werte)
◆ keine Sperren → effizient ausführbar, keine anderen
Transaktionen werden behindert
■
read committed (Standard)
◆ nur Lesen endgültig geschriebener Werte, aber
nonrepeatable read möglich
set transaction read write,
isolation level serializable
VL Datenbanken I – 12–39
VL Datenbanken I – 12–40
Bedeutung der Isolationsebenen (II)
■
■
Isolationsebenen (III)
repeatable read
◆ kein nonrepeatable read, aber Phantomproblem kann
auftreten
Isolationsebene
serializable
◆ garantierte Serialisierbarkeit
◆
Transaktion sieht nur Änderungen, die zu Beginn der
Transaktion committed waren (plus eigene
Änderungen)
Dirty
Unrepeatable
Phantom
Read
Read
Read
Read Uncommitted
+
+
+
Read Committed
–
+
+
Repeatable Read
–
–
+
Serializable
–
–
–
VL Datenbanken I – 12–41
Isolationsebenen: read committed
T1
select A from R
→ alter Wert
select A from R
→ alter Wert
VL Datenbanken I – 12–42
Isolationsebenen: serializable
T2
T1
update R set A = neu
set transaction
isolation level
serializable
T2
set transaction ...
update R set A = neu
where C = 42
commit
commit
select A from R
→ neuer Wert
update R set A = neu
where C = 42
→ Fehler
VL Datenbanken I – 12–43
VL Datenbanken I – 12–44
Oracle (I)
Oracle (II)
■
Unterstützung der Isolationsebenen Read Committed
und Serializable
■
darüber hinaus: Read-Only-Modus (nicht Bestandteil
von SQL-92)
set transaction isolation level read committed;
set transaction isolation level serializable;
set transaction isolation level read only;
Isolationsebenen für eine Menge von Transaktionen
alter session
set isolation_level Isolationsebene;
Explizite Kommandos zum Setzen von Sperren
lock table Tabelle in row share mode;
lock table Tabelle in share mode;
lock table Tabelle in row exclusive mode;
lock table Tabelle in share row exclusive mode;
lock table Tabelle in exclusive mode;
VL Datenbanken I – 12–45
Oracle: Sperrmodi
VL Datenbanken I – 12–46
Oracle: Implizite Sperren
Modus
Tupel
Relation
row share
row exclusive
share
share row exclusive
exculsive
read lock (rl) intended rl
write lock (wl) intended wl
–
rl
–
read intended wl
–
wlk
VL Datenbanken I – 12–47
select
insert/update/delete
select...for update
commit/rollback
→ keine Sperre
→ write lock / row exclusive
→ read lock / row share
→ Freigabe aller Sperren
VL Datenbanken I – 12–48