n n n n n n n n n n VLDatenbank-Implementierungstechniken–7–1 n n n VLDatenbank-Implementierungstechniken–7–2 n n n VLDatenbank-Implementierungstechniken–7–3

(1)

7. Transaktionsverwaltung

■ Transaktionseigenschaften

■ Probleme im Mehrbenutzerbetrieb

■ Serialisierbarkeit

■ Transaktionsabbruch und Fehlersicherheit

■ Ausnutzung semantischer Informationen

■ Erweiterte Transaktionsmodelle

■ Architektur der Transaktionsverwaltung

■ Sperrende und nicht-sperrende Verfahren

■ Transaktionen in SQL-Systemen

■ Transaktionsmonitore

VL Datenbank-Implementierungstechniken – 7–1

Transaktionen im Mehrbenutzerbetrieb

Ablaufintegrität

■ Fehler durch „gleichzeitigen“ Zugriff mehrerer Benutzer auf dieselben Daten

■ mehrere Programme laufen simultan

→nebenläufige, konkurrierende Prozesse

■ Transaktion als Verarbeitungseinheit

Beispielsszenarien

■ 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

(2)

Transaktionseigenschaften

Eine Transaktion ist eine Folge von Operationen (Ak- tionen), die die Datenbank von einem konsistenten Zustand in einen konsistenten, eventuell veränder- ten, Zustand überführt, wobei das ACID-Prinzip ein- gehalten werden muß.

ACID-Eigenschaften

■ 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, daß er mit dieser Datenbank alleine arbeitet

■ Durability (Dauerhaftigkeit / Persistenz):

nach erfolgreichem Abschluß einer Transaktion muß das Ergebnis dieser Transaktion „dauerhaft“ in der

Datenbank gespeichert werden

Kommandos einer Transaktionssprache

■ Beginn einer Transaktion:

Begin-of-Transaction-Kommando BOT

■ commit: die Transaktion soll erfolgreich beendet werden

■ abort: die Transaktion soll abgebrochen werden

(3)

Probleme im Mehrbenutzerbetrieb

■ Inkonsistentes Lesen: Nonrepeatable Read

■ Lesen inkonsistenter Zustände

■ Abhängigkeiten von nicht freigegebenen Daten: Dirty Read

■ Das Phantom-Problem

■ Verlorengegangenes Ändern: Lost Update

■ Integritätsverletzung durch Mehrbenutzer-Anomalie

■ Probleme bei Cursor-Referenzen

Nonrepeatable Read

Beispiel:

■ ZusicherungX=A+B+Cam Ende der TransaktionT1

■ XundY seien lokale Variablen

■ Tiist die Transaktioni

■ IntegritätsbedingungA+B+C = 0

Beispiel für inkonsistentes Lesen

T1 T2

X :=A;

Y :=A/2; A:=Y; C :=C+Y; commit;

X :=X+B; X :=X+C; commit;

(4)

Lesen inkonsistenter Zustände

IntegritätsbedingungX+Y = 0

T1 T2

read(X);

read(Y);

write(X);

Y :=Y + 1;

read(X);

read(Y);

write(Y);

commit;

Dirty Read

T1 T2

read(X);

X :=X+ 100; write(X);

read(X);

Y :=Y +X; write(Y);

commit;

abort;

Das Phantom-Problem

T1 T2

select count (*) intoX

fromMitarbeiter;

insert

intoMitarbeiter values(M eier,50000,· · ·);

commit;

updateMitarbeiter setGehalt=

Gehalt+10000/X;

(5)

Lost Update

T1 T2 X

read(X); 10

X :=X+ 1; 10

X:=X+ 1; 10

write(X); 11

Mehrbenutzer-Anomalie

IntegritätsbedingungA=B

T1 := hA:=A+ 10;B:=B+ 10i T2 := hA:=A∗1.1;B:=B∗1.1i T1undT2erhalten isoliert die IB

Mehrbenutzer-Anomalie II

T1 T2 A B

read(A); 10 10

A:=A+ 10;

write(A); 20

read(A);

A:=A∗1.1;

write(A); 22 read(B);

B:=B∗1.1;

write(B); 11

read(B);

B:=B+ 10;

write(B); 22 21

(6)

Probleme bei Cursor-Referenzen

T1 T2

Positioniere CursorC1

auf nächstes Tupel mit EigenschaftP (TupelA)

Verändere

EigenschaftP →P⁰ vonA

Lies laufendes Tupel

Probleme mit Cursor: SQL-Notation

T₁ T₂

declareC₁cursor for select *

fromMitarbeiter whereAbt=’Verkauf’;

...

updateMitarbeiter setAbt=’Einkauf’

whereMName= ...;

fetchC1into ...

Serialisierbarkeit

■ Einführung in die Thematik

■ Formalisierung von Abläufen (Schedules)

■ Serialisierbarkeitsbegriffe

■ Vergleich der Serialisierbarkeitsbegriffe

(7)

Einführung in die Serialisierbarkeit

T1 : readA; A:=A−10; writeA; readB;

B:=B+ 10; writeB;

T2 : readB; B:=B−20; writeB; readC; C :=C+ 20; writeC;

Ausführungsvarianten für zwei Transaktionen:

■ seriell, etwaT1vorT2

■ „gemischt“, etwa abwechselnd Schritte vonT1undT2

Beispiele für verschränkte Ausführungen

Ausführung 1 Ausführung 2 Ausführung 3 T1 T2 T1 T2 T1 T2

readA readA readA

A−10 readB A−10

writeA A−10 readB

readB B−20 writeA

B+ 10 writeA B−20

writeB writeB readB

readB readB writeB

B−20 readC B+ 10

writeB B+ 10 readC

readC C+ 20 writeB

C+ 20 writeB C+ 20

writeC writeC writeC

Effekt unterschiedlicher Ausführungen

A B C A+B+C initialer Wert 10 10 10 30 nach Ausführung 1 0 0 30 30 nach Ausführung 2 0 0 30 30 nach Ausführung 3 0 20 30 50

(8)

Vereinfachtes Modell

Lock-Unlock-Modell

T1 : lockA; unlockA; lockB; unlockB;

T2 : lockB; unlockB; lockC; unlockC;

Beispiele II

Ausführung 1 Ausführung 2 verbotene Ausführung

T1 T2 T1 T2 T1 T2

lockA lockA lockA

unlockA lockB lockB

lockB unlockA unlockA

unlockB unlockB lockB

lockB lockB unlockB

unlockB lockC lockC

readC unlockB unlockB

unlockC unlockC unlockC

Semantik mit Berechnungsfunktionen I

T1 T2 T3

lockA lockB lockA

lockB lockC lockC

unlockA f1(A, B) unlockB f3(B, C) unlockC f6(A, C) unlockB f2(A, B) lockA unlockA f7(A, C)

unlockC f⁴(A, B, C) unlockA f⁵(A, B, C)

(9)

Semantik mit Berechnungsfunktionen II

Schritt A B C

(1) T1: lockA A0 B0 C0

(2) T2: lockB A0 B0 C0

(3) T2: lockC A0 B0 C0

(4) T2: unlockB A0 f3(B0, C0) =σ_i C0

(5) T1: lockB A0 σi C0

(6) T1: unlockA f1(A0, σi) =σii σi C0

(7) T2: lockA σ_ii σ_i C0

(8) T2: unlockC σ_ii σ_i f4(σii, B0, C0) =σ_iii (9) T2: unlockA f5(σii, B0, C0) =σiv σi σiii

(10) T3: lockA σiv σi σiii

(11) T3: lockC σ_iv σ_i σ_iii

(12) T1: unlockB σiv f2(A⁰, σi) σiii

(13) T3: unlockC σiv f2(A0, σi) f6(σiv, σiii) (14) T3: unlockA f7(σiv, σ_iii) f2(A0, σ_i) f6(σiv, σ_iii)

Letzter Wert für A voll ausgeschrieben

f7(σiv, σiii) = f7(f5(f1(A0, f3(B0, C0)), B0, C0), f4(f1(A0, f3(B0, C0)), B0, C0))

Serialisierbarkeit

Eine verschränkte Ausführung mehrerer Transaktio- nen heißt serialisierbar, wenn ihr Effekt identisch zum Effekt einer (beliebig gewählten) seriellen Ausführung dieser Transaktionen ist.

(10)

Konfliktgraph

T

T₃

1

2

Der Begriff des Schedules

1 2 3 v4 v v v

Scheduler

1 2 3 4

w1 w w w₄ ₃ ₂

u u u u

3 w₁ u₁ v2 v1 2 v

... w

Das Read/Write-Modell

■ TransaktionT ist eine endliche Folge von Operationen (Schritten)pider Formr(xi)oderw(xi):

T =p1p2p3· · ·pnmitpi∈ {r(xi), w(xi)}

■ Vollständige TransaktionT hat als letzten Schritt entweder einen Abbruchaoder ein Commitc:

T =p1· · ·pna oder

T=p1· · ·pnc.

(11)

Verschränkte Ausführungen

SHUFFLE(T): Menge aller verschränkten Ausführungen der Einzelschritte aller in der Menge_T enthaltenen

TransaktionenTi

■ alle Schritte der TransaktionenTisind genau einmal enthalten

■ relative Reihenfolge der Einzelschritte einer Transaktion wird beibehalten

T1 := r1(x)w1(x) T2 := r2(x)r2(y)w2(y)

SHUFFLE(T) = {r1(x)w1(x)r2(x)r2(y)w2(y), r2(x)r1(x) w1(x)r2(y)w2(y), . . .}

Schedule

Ein Schedule ist ein Präfix eines vollständigen Sche- dules.

r1(x)r2(x)w1(x)

| {z }

ein Schedule

r2(y)a1w2(y)c2

| {z }

ein vollständiger Schedule

Serieller Schedule

Ein serieller SchedulesfürT ist ein vollständiger Schedule der folgenden Form:

s:=T_ρ(1)· · ·T_ρ(n) für eine Permutationρvon{1, . . . , n}

resultierende serielle Schedules für zwei Transaktionen T1:=r1(x)w1(x)c1undT2:=r2(x)w2(x)c2:

s1:=r1(x)w1(x)c1

| {z }

T1

r2(x)w2(x)c2

| {z }

T2

s2:=r2(x)w2(x)c2

| {z }

T2

r1(x)w1(x)c1

| {z }

T1

(12)

Korrektheitskriterium

Ein Schedulesist korrekt, wenn der Effekt des Sche- dules s (Ergebnis der Ausführung des Schedules) äquivalent dem Effekt eines (beliebigen) seriellen Scheduless⁰bzgl. derselben Menge von Transaktio- nen ist (in Zeichens≈s⁰).

Ist ein Schedule s äquivalent zu einem seriellen Schedules⁰, dann istsserialisierbar (zus⁰).

Äquivalenzrelationen I

■ Sichtserialisierbarkeit VSR

◆ Idee: „Sicht“ einer Schreiboperation auf vergangene Entwicklung der Datenbankzustände durch

vorangegangene Leseoperationen

◆ Begriff „Liest-von-Relation“RF(s)für Schedules: RF(s) := {(Ti, x, Tj)|rj(x)liest x von Ti}

◆ exponentieller Aufwand für Test auf Sichtserialisierbarkeit

Äquivalenzrelationen II

■ Konfliktserialisierbarkeit CSR

◆ Idee: Bestimmung der Konflikte zwischen Transaktionen

◆ Operationenpundqstehen in Konflikt, wenn sie auf demselben DB-Objekt arbeiten und mindestens eine davon schreibt:

C(s) :={(p, q) |p, qsind in Konflikt undp→sq}

◆ graphbasierter Test: Konfliktgraph muß azyklisch sein

◆ effizienter Test möglich (topologisches Sortieren) CSR_⊂VSR

(13)

Transaktionsabbruch/Fehlersicherheit

Aus Sicht der Fehlersicherheit ist folgender Schedulesnicht akzeptabel:

s =r1(x)w1(x)r2(x)a1w2(x)c2

... aber serialisierbar in VSR und CSR!

Rücksetzbarkeit RC

■ sheißt rücksetzbar (engl. recoverable), falls folgende Bedingung erfüllt ist:

(T_iliest vonT_jins)∧(c_i∈s)⇒(c_j →s c_i)

■ Beispiel:

s1=w1(x)w1(y)r2(u)w2(x)r2(y)w2(y)c2w1(z)c1

Ins1liestT2das DatenobjektyvonT1, aberc2kommt vorc1—s1ist nicht rücksetzbar.

s2=w1(x)w1(y)r2(u)w2(x)r2(y)w2(y)w1(z)c1c2

s2ist rücksetzbar (aber: Probleme bei Abbruch vonT1

anstelle vonc1;dirty read!)

Vermeidung kaskadierender Abbrüche

■ Ein Schedulesvermeidet kaskadierende Abbrüche (engl. avoiding cascading aborts ACA), falls gilt:

(TiliestxvonTjins)⇒(cj→sri(x)) Transaktion darf nur Daten lesen, die zuletzt von einer bereits abgeschlossenen Transaktion geschrieben wurden

■ Beispiel:

◆ s₂gehört nicht in die Klasse ACA

◆ s3jedoch vermeidet kaskadierende Abbrüche:

s3=w1(x)w1(y)r2(u)w2(x)w1(z)c1r2(y)w2(y)c2

◆ Daher:s3∈ACA

(14)

Probleme mit Before-Images

DB-Inhalt Operation

x= 1(Anfangswert)

x= 2 w1(x_←2) [BFx,T1= 1] x= 3 w2(x_←3) [BFx,T2= 2]

a1 Rücksetzen von w1(x ← 2) mit BFx:= 1.

Überschreiben durch T2 muß erhalten bleiben!

x= 3

a₂ Rücksetzen von w₂(x ← 3) mit BFx:=??

Striktheit ST

■ Ein Schedulesheißt strikt (engl. strict), falls die folgende Bedingung gilt:

(wj(x)→spi(x)∧j6=i)⇒ (aj<s pi(x)∨cj<spi(x), (p∈ {r, w}))

Das heißt, es darf kein „geschriebenes“ Objekt einer noch nicht beendeten Transaktion gelesen oder überschrieben werden

■ Beispiel:

◆ s3∈/ST

◆ s4ist strikt, alsos4∈ST:

s4=w1(x)w1(y)r2(u)w1(z)c1w2(x)r2(y)w2(y)c2

Zusammenhang zwischen den Klassen

RC

ST

VSR CSR

seriell ACA

(15)

Operationen: Benutzerkommandos

Benutzerkommandos, die den Abbruch einer Transaktion beeinflussen können:

■ commit versucht ein Commit durchzuführen_;gelingt aber nicht immer (Integritätsverletzung)_;tatsächliches Commit ist erst duch die Erfolgsmeldung des DBMS garantiert

■ abort erzwingt endgültigen Abbruch einer Transaktion

■ andere Datenbank-Operationen, die zum Abbruch führen können: Division durch Null,

Integritätsverletzungen

Operationen: Intern

■ commit führt intern ein endgültiges Commit durch

■ für abort zwei Varianten:

◆ abort+restart bricht die Transaktion ab, aber versucht durch ein erneutes Starten, diese

Transaktion zu einem erfolgreichen Ende zu führen (durch Eingriff des Schedulers; bei wiederholten erfolglosen abort+restart auch endgültiger Abbruch möglich)

◆ abort+stop realisiert den endgültigen Abbruch (expliziter Benutzerwunsch oder bei nichtreparablen Integritätsverletzungen)

Operationen: Zusammenhang

abort

abort+restart abort+stop DB-Operation

Benutzerebeneintern

commit commit

(16)

Ausnutzung semantischer Informationen

■ Bisher: Read/Write-Modell

◆ low-level Operationen

◆ keine spezielle Optimierung möglich

■ Ausnutzung semantischer Informationen

■ höhere Operationen

■ Vertauschbarkeitsrelationen

Erweiterte Transaktionsmodelle

■ Probleme mit ACID-Transaktionen

■ Auswege

◆ Geschachtelte Transaktionen (engl. nested transactions):

hierarchische Ansammlung von Vater- / Sohntransaktionen

◆ Sagas:

Zwischenergebnisse bereits durch ein Commit anderen Transaktionen verfügbar, aber trotzdem bei einem späteren Abbruch wieder rückgängig gemacht

;Formalisierung von Abhängigkeiten zwischen Teiltransaktionen

Der Scheduler

T1 T2 Tn

Scheduler (SC) Manager (TM)

Manager (SM)

korrekter Schedule (bestehend aus r, w, c, a) Transaktions-

Recovery Manager (RM)

Puffer Manager (PM) Speicher

(17)

Transaktionsoperationen

Transaktionsklammern

■ BOT (Begin of Transaction)

■ EOT (End of Transaction) Schritte:

■ r(read),

■ w(write),

■ a(abort), und

■ c(commit).

t={r|w}^∗(a|c)

Zustände einer Transaktion

stopped

active

aborted committed

running delayed

initial BOT

execute

delay

restart

reject EOT

stop retry

Behandlung eines Schritts

■ ausführen (execute)

Transaktion_→Zustand running.

■ verzögern (delay)

Transaktion_→Zustand delayed

■ zurückweisen (reject)

Transaktion_→Zustand aborted

(18)

Aggressive Scheduler

■ ein Scheduler ist aggressiv, wenn er Konflikte zuläßt und dann versucht, aufgetretene Konflikte zu erkennen und aufzulösen

■ maximiert die Parallelität von Transaktionen

■ Risiko: Transaktionen werden erst am Ende ihrer Ausführung zurückgesetzt

Konservative Scheduler

■ ein Scheduler arbeitet konservativ, wenn er Konflikte möglichst vermeidet, dafür aber Verzögerungen von Transaktionen in Kauf nimmt

■ erlauben nur eine geringe Parallelität von Transaktionen

■ minimieren den Rücksetzungsaufwand für abgebrochene Transaktionen

■ im Extremfall findet keine Parallelisierung von Transaktionen mehr statt, d.h., es werden immer alle Transaktionen bis auf eine verzögert

Sperrmodelle

Schreib- und Lesesperren in folgender Notation:

■ rl(x): Lesesperre (engl. read lock ) auf einem Objektx

■ wl(x): Schreibsperre (engl. write lock ) auf einem Objekt x

Entsperrenru(x)undwu(x), oft zusammengefaßtu(x)für engl. unlock

(19)

Sperrdisziplin

■ Schreibzugriffw(x)nur nach Setzen einer Schreibsperre wl(x)möglich

■ Lesezugriffer(x)nur nach drl(x)oderwl(x)erlaubt

■ nur Objekte sperren, die nicht bereits von einer anderen Transaktion gesperrt

■ nachrl(x)nur nochwl(x)erlaubt, danach aufxkeine Sperre mehr; Sperren derselben Art werden maximal einmal gesetzt

■ nachu(x)durchtidarftikein erneutesrl(x)oderwl(x) ausführen

■ vor einem commit müssen alle Sperren aufgehoben werden

Verklemmungen

t1 t2

wl(x) wl(y) delay_→ wl(y)

wl(x) ←delay Verklemmung!

Alternativen:

■ Verklemmungen werden erkannt und beseitigt

■ Verklemmungen werden von vornherein vermieden

Verklemmungserkennung und -auflösung

Wartegraph

1 2 3

4

6 5

neue Sperre

Auflösen durch Abbruch einer Transaktion, Kriterien:

■ Anzahl der aufgebrochenen Zyklen,

■ Länge einer Transaktion,

■ Rücksetzaufwand einer Transaktion,

■ Wichtigkeit einer Transaktion, ...

(20)

Livelock-Problem

1. T1sperrtA

2. T2willAsperren, muß aber warten

3. T3will danachAsperren, muß auch warten 4. T1gibtAfrei

5. T3kommt vorT2an eine Zeitscheibe, sperrtA 6. T2will weiterhinAsperren, muß aber warten 7. T4will danachAsperren, muß auch warten 8. T3gibtAfrei

9. T4kommt vorT2an die nächste Zeitscheibe ...

Sperrprotokolle: Notwendigkeit

T1 T2

wl(x) w(x) u(x)

wl(x) w(x) u(x) wl(y) w(y) u(y) wl(y) w(y) u(y)

Zwei-Phasen-Sperr-Protokoll

2PL

Phase Phase

Freigabe- Anforderungs-

#Sperren

Zeit

(21)

Konflikt bei Nichteinhaltung des 2PL

T1 T2

u(x)

wl(x) wl(y) ... u(x) u(y) wl(y) ...

Striktes Zwei-Phasen-Sperr-Protokoll

Zeit

S2PL

Phase

Freigabe-Phase Anforderungs-

#Sperren

vermeidet kaskadierende Abbrüche!

Konservatives 2PL-Protokoll

Zeit Anforderungs-

Phase

C2PL

Freigabe-

#Sperren

Zeit Anforderungs-

Phase

#Sperren

Phase Freigabe-

CS2PL

vermeidet Deadlocks!

(22)

Sperrgranulate

■ Granularitätshierarchien in Datenbanken

■ Hierarchische Sperren

■ Baumprotokolle für Baumindexe

Granularitätshierarchien in RDBS

Datenbank Datei Cluster Datenbank

Attribut Seite

Granularitätshierarchien

Logisch Physisch

Relation Tupel

Hierarchische Sperren

■ Sperren pflanzen sich nach unten (in Richtung der Blätter) fort

■ Sperren dürfen nicht von oben (von der Wurzel her) überschrieben werden

■ Zusätzlich: intentionale Sperren (engl. intentional locks) Warnungen vor Sperren, die sich in der Hierarchie weiter unten befinden

irl(intentionale Lesesperre) undiwl(intentionale Schreibsperre)

(23)

Kompatibilitätsmatrix

■ für elementare Sperren

rli(x) wli(x) rlj(x) √

— wlj(x) — —

Kompatibilitätsmatrix

■ für hierarchische Sperren

rli(x) wli(x) irli(x) iwli(x) riwli(x) rlj(x) √

— ^√ — —

wlj(x) — — — — —

irlj(x) √

— ^√ ^√ ^√

iwlj(x) — — ^√ ^√ —

riwlj(x) — — ^√ — —

Ablauf des hierarchischen Sperren

1. Sperren werden auf einem Pfad in der Reihenfolge von der Wurzel zum Zielobjekt gesetzt

2. Datenobjekt, auf dem gearbeitet werden soll, wird gesperrt: Schreib- oder Lesesperre (dabei Sperrenverträglichkeitsmatrix beachten!) 3. Alle anderen Knoten auf dem Pfad bekommen

intentionale Sperren

4. Sperren können verschärft werden, das heißt einrlkann zumwlwerden, einirlzumrlund einirlzumiwl 5. Freigabe erfolgt in umgekehrter Reihenfolge

(24)

Hierarchisches Sperren: Beispiel I

(BetriebsDB)

(Tamara Jagellowsk)

Attribut ...

...

... (Projekt)

(Mario De Monti)

(Telefon) (Gehalt)

Datenbank

Attribut (Mitarbeiter)

BetriebsDB BetriebsDB

Tamara, ..., Mario

Gehalt, ..., Telefon

Mitarbeiter Mitarbeiter

T ₁ T₂

rl (implizit) rl (implizit) rl (explizit)

irl (explizit) iwl (explizit)

iwl (explizit)

Tupel Tupel

Relation Relation

Hierarchisches Sperren: Beispiel II

(BetriebsDB)

(Tamara Jagellowsk)

Attribut ...

...

... (Projekt)

(Mario De Monti)

(Telefon) (Gehalt)

Datenbank

Attribut (Mitarbeiter)

BetriebsDB

Tamara

Telefon Gehalt

Mitarbeiter BetriebsDB

rl (explizit)

iwl (explizit)

wl (explizit)

T1 T₂

irl (explizit)^Tamara irl (explizit)Mitarbeiter irl (explizit)

Tupel Tupel

Hierarchisches Sperren: riwl

Datenbank

(Mitarbeiter) (BetriebsDB)

(Tamara Jagellowsk) ...

... (Projekt)

(Mario De Monti)

2

Mitarbeiter Mitarbeiter

riwl (explizit)

Tamara, ..., Mario rl (implizit) wl (explizit)^Tamara

T sperrt

riwl (explizit) T sperrt1

BetriebsDB BetriebsDB

irl (explizit)

rl (explizit)^Mario

Tupel Tupel

(25)

Sperren in Indexstrukturen

Baumprotokoll

1. Objektokann nur dann vonT gesperrt werden, wenn sein direkter Vorgänger bereits vonT gesperrt ist 2. erste Regel gilt nicht für die erste Sperre einer

Transaktion

3. Sperren können jederzeit wieder freigegeben werden 4. Kein Objekt kann innerhalb einer TransaktionT zweimal

gesperrt werden

Beispiel Baumprotokoll

lockA; lockB; unlockA; lockD

B D

F

E

C

G A

Ablauf im Baumprotokoll

T1 T2 T3

lockA lockB lockD unlockB

lockB lockC

lockE unlockD

lockF unlockA

lockG unlockC

unlockE lockE

unlockF unlockB

unlockG unlockE

(26)

Baumprotokolleigenschaften

Baumprotokoll erzwingt nicht 2PL!

Falls alle Transaktionen dem Baum-Protokoll genü- gen, ist jeder korrekte Schedule serialisierbar.

Nicht-sperrende Verfahren

■ Zeitstempelbasierte Verfahren erzwingen eine korrekte Reihenfolge der Bearbeitungsschritte mittels geeigneter Markierungen der Transaktionen

■ Serialisierbarkeitstester verwalten einen Konfliktgraphen, und realisieren daher eine direkte Überprüfung der Konfliktserialisierbarkeit

■ Zertifikatoren führen zunächst die kompletten Transaktion aus und versuchen erst am Ende festzustellen, ob die Transaktion gemäß dem Serialisierbarkeitsbegriffs abgelaufen sind

Zeitmarkenverfahren

■ Zeitmarken sind eindeutig und werden fortlaufend vergeben.

■ Für jedes Datenobjektxwerden zwei Werte geführt:

◆ max-r-scheduled[x]:

Variable, die den Zeitstempel der letzten Leseoperation aufxenthält

◆ max-w-scheduled[x]:

Variable, die den Zeitstempel der letzten Schreiboperation aufxenthält

(27)

Timestamp-Ordering-Regel

Eine Operation pi[x] wird vorqk[x] genau dann aus- geführt, wennts(Ti)< ts(Tk)gilt.

■ pundq: inkompatible Operationen der TransaktionenTi

bzw.Tk (i6=k) auf einem Objektx

■ ts(Ti)bzw.ts(Tk)sind Zeitstempel der TransaktionenTi

bzw.T_k

■ Formal:

Sindpi(x)undqj(x)in Konflikt, so gilt:

pi(x)wird vorqj(x)ausgeführt_⇐⇒ts(Ti)< ts(Tj).

Basis-TO-Algorithmus

if pi[x] ist eingetroffen then if pi[x] ist ri[x] then

if ts(Ti)<max-w-scheduled[x] then weise Operation zurück;

else

max-r-scheduled[x] :=

max(max-r-scheduled[x], ts(Ti));

gebe Operation weiter;

else /* pi[x] ist wi[x] */

if ts(Ti)<max-w-scheduled[x] or ts(Ti)<max-r-scheduled[x] then weise Operation zurück;

else

max-w-scheduled[x] :=ts(Ti);

gebe Operation weiter;

Nachteile und Vorteile der TO-Verfahren

■ Nachteil: Anfälligkeit gegen stark variierende Laufzeiten von Transaktionen

◆ lang andauernde Transaktionen bearbeiten ihre letzten Schritte längere Zeit nach der Vergabe der Zeitmarke

◆ kommen damit mit diesen Schritten mit größerer Wahrscheinlichkeit „zu spät“

■ Vorteil: einfache Realisierung in verteilten Systemen

(28)

Zeitmarkenverfahren: Ablauf

T1 T2 T3 A B C

mrs mws mrs mws mrs mws

ts= 200 ts= 150 ts= 175 0 0 0 0 0 0

readB 0 0 200 0 0 0

readA 150 0 200 0 0 0

readC 150 0 200 0 175 0

writeB 150 0 200 200 175 0

writeA 150 200 200 200 175 0

writeC⇓ 150 200 200 200 175 ⇓

abort 150 200 200 200 175 0

Optimiertes Zeitmarkenverfahren

Optimierte BTO-Regel:

■ bei negativen Ausgang des Vergleichs einer schreibenden Transaktion mit der

max-w-scheduled-Marke wird das Schreiben ignoriert sofern kein Konflikt mit der max-w-scheduled-Marke auftritt

■ alter Wert von max-w-scheduled wird übernommen und die Transaktion läuft weiter

;„Optimierung für blindes Schreiben“

Opt. Zeitmarkenverfahren: Ablauf

T1 T2 T3 A C

mrs mws mrs mws

ts= 200 ts= 150 ts= 175 0 0 0 0

readA 150 0 0 0

readC 150 0 175 0

writeA 150 200 175 0

writeA√ 150√ 200 (⇓) 175 0

(29)

Livelocks im Zeitmarkenverfahren

T1 T2 T1⁰ T2⁰ A B

mrs mws mrs mws

ts= 100 ts= 110 ts= 120 ts= 130 0 0 0 0

writeB 0 0 0 100

writeA 0 110 0 100

readA⇓ 0 110⇓ 0 100

writeB 0 110 0 120

readB⇓ 0 110 0 120⇓

writeA 0 130 0 120

readA⇓ 0 130⇓ 0 120

Serialisierbarkeitsgraphentester

Problem: Bereinigen des Konfliktgraphens r0(x)w1(x)w1(y1)c1

| {z }

T¹

... wn(x)wn(yn)cn

| {z }

Tn

w0(z)

t0 t

1

t2

.. .

tn

Optimistische Verfahren: Phasen

1. Ausführungsphase (execute): Transaktion wird ausgeführt, d.h. alle Lese- und Schreiboperationen;

Schreiboperationen jedoch nicht in der Datenbank, sondern auf einer lokalen Kopie des Datenbankobjekts im Puffer

2. Validierung (validate)

für jede Transaktion, die commit ausführen will, wird geprüft, ob sie im Sinne der Konfliktserialisierbarkeit korrekt abgelaufen ist

3. Persistenzphase (persist):

falls keine Konflikte aufgetreten sind, Zurückschreiben aller geänderten Datenbankobjekte in den stabilen Speicher (d.h. in die Datenbank)

(30)

Validierungskriterium

Transaktionszähler T C

∀Ti, Tj:n(Ti)< n(Tj)mit

n(Ti) =Wert von TC nach der Validierung vonTi: 1. Tibeendet seine valpersist-Phase, bevorTj

diese beginnt.

2. x∈ws(Ti)∩rs(Tj)⇒Tibeendet valpersist-Phase, bevorTjxliest.

3. x∈rs(Ti)∩ws(Tj)⇒Tiliestxvor Beginn der valpersist-Phase vonTj

ws(Ti)ist write-set vonTi(alle vonTigeschriebenen DB-Objekte)

rs(Ti)ist read-set vonTi(gelesene DB-Objekte)

Optimistische Scheduler

Rückwärtsvalidierung

Vorwärtsvalidierung execute

validate

validate persist persist

execute execute execute

execute

execute validate persist persist validate

3 2 1 3 2 T1 T

T

Optimistische Scheduler II

■ Rückwärtsvalidierung:

◆ Test vonrs(Ti)gegenws(Tj)für bereits abgeschlosseneTj

◆ ausgenommen davon sindTj, die bereits vor Beginn vonTiein commit ausgeführt haben

◆ bei Konflikt: Zurücksetzen vonTi

◆ im Beispiel: Test vonrs(T1)gegenws(T2)undws(T3)

■ Vorwärtsvalidierung

◆ Test vonws(Ti)gegenrs(Tj)für TransaktionenTj, die aktiv sind (also in der Ausführungsphase)

◆ bei Konflikt: Zurücksetzen vonTj

(31)

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:

set transaction read write, isolation level serializable

Bedeutung der Isolationsstufen

■ 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

◆ nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich

■ repeatable read

◆ kein nonrepeatable read, aber Phantomproblem kann auftreten

■ serializable

◆ garantierte Serialisierbarkeit

Isolationsebenen II

Isolationsebene Dirty Unrepeatable Phantom

Read Read Read

Read Uncommitted + + +

Read Committed – + +

Repeatable Read – – +

Serializable – – –

(32)

Oracle I

■ 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;

Oracle II

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;

Transaktionsmonitore

Presentation Server Presentation Server

Workflow Controller

(33)

Transaktionsmonitore: Architektur

■ Präsentations-Server, engl. presentation server realisiert als Client die Kommunikation mit dem Anwender (Kommandosprache oder Menü-gesteuerte Oberflächen zum Absetzen von Transaktionen etc.)

■ Workflow-Kontroller (engl. workflow controller ) erzwingt die Zuteilung (engl. routing) der

Transaktionsanforderungen an verschiedenen DBMS und realisiert z.B. das Zwei-Phasen-Commit-Protokoll

■ Transaktions-Server (engl. transaction server ) realisieren die Kopplung der lokalen DBMS mit dem Transaktionsmonitor

Vorteile eines Transaktionsmonitors

■ bietet eine einheitliche Schnittstelle für die

Transaktionsprogrammierung auf verschiedenen DBMS

■ bei verteilter Verarbeitung Übernahme der Routing der Transaktionen und der Erzwingung von

Commit-Protokollen

■ Übernahme von Systemfunktionen wie Lastbalancierung, Fehlerkontrolle und Systemkonfiguration

■ kann Funktionen wie das Schreiben eines Log-Buchs oder die Kommunikationsüberwachung übernehmen

■ Transaktions-Server eines TP-Monitors kann auch Daten einkapseln, die nicht von einem DBMS mit voller

Transaktionsfunktionalität verwaltet werden