6. Grundlagen des Transaktionskonzepts

6. Grundlagen des Transaktionskonzepts
What can go wrong, will go wrong ...
• Transaktionskonzept
• GBIS-Rahmen: Einordnung
- führt ein neues Verarbeitungsparadigma ein
- ist Voraussetzung für die Abwicklung betrieblicher Anwendungen
(mission-critical applications)
Anwendung
Daten
Steuerung
Funktionen
- erlaubt „Vertragsrecht“ in rechnergestützten IS zu implementieren
• ACID-Transaktionen zur Gewährleistung weit reichender
Zusicherungen zur Qualität der Daten, die gefährdet sind durch
SW-Architektur
- fehlerhafte Programme und Daten im Normalbetrieb
- inkorrekte Synchronisation von Operationen im Mehrbenutzerbetrieb
• Wie erzielt man Atomarität von DB-Operationen und Transaktionen?
- vielfältige Fehler im DBS und seiner Umgebung
- Atomare Aktionen
- Schlüsselrolle von Synchronisation sowie Logging und Recovery
• Erhaltung der DB-Konsistenz
➥ Logging und Recovery bietet Schutz vor erwarteten Fehlern!
• Entwicklungsziele
• Anomalien im Mehrbenutzerbetrieb
Build a system used by millions of people that is always available –
out less than 1 second per 100 years = 8 9’s of availability!
- Verlorengegangene Änderungen
(J. Gray: 1998 Turing Lecture)
- Inkonsistente Analyse, Phantom-Problem usw.
- Verfügbarkeit heute (optimistisch):1
• Synchronisation von Transaktionen
• für Web-Sites: 99%
- Ablaufpläne, Modellannahmen
• für gut administrierte Systeme: 99,99%
- Korrektheitskriterium, Konsistenzerhaltende Ablaufpläne
• höchstens: 99,999%
• Theorie der Serialisierbarkeit
- Künftige Verfügbarkeit
- Äquivalenz von Historien, Serialisierbarkeitstheorem
• da fehlen noch 5 9’
- Klassen von Historien
• bis 2010 nicht zu erreichen???
• Zwei-Phasen-Sperrprotokolle (2PL)
• ...
• Logging und Recovery
• Commit-Verarbeitung
1.
6-1
Despite marketing campaigns promising 99,999% availability, well-managed servers today
achieve 99,9% to 99%, or 8 to 80 hours downtime per year (Armando Fox)
6-2
Atomarität ist keine natürliche Eigenschaft von Rechnern
erzwungenes
abnormales Ende
erzwungenes ROLLBACK
DML3
DML2
DML1
BOT
• Atomicity:
• Consistency:
Konsistenz und semantische Integrität der DB ist durch fehlerhafte Daten
und Operationen eines Programms gefährdet.
• Isolation:
Isolierte Ausführung bedeutet „logischen Einbenutzerbetrieb“
abnormales Ende
ROLLBACK
DMLn
•
•
•
DML3
DML2
DML1
BOT
• Durability:
Dauerhaftigkeit heißt, dass die Daten und Änderungen erfolgreicher
Transaktionen jeden Fehlerfall „überleben“ müssen
➥ ACID-Transaktionen befreien den Anwendungsprogrammierer von den
Aspekten der Ablaufumgebung des Programms und von möglichen Fehlern!
• Wie setzt man diese Forderungen systemtechnisch um?
- hier nur Einführung von Begriffen
- vertiefende Betrachtung und Diskussion von Realisierungskonzepten
6-3
normales Ende
COMMIT
DMLn
•
•
•
DML3
DML2
DML1
in nachfolgenden Vorlesungen (DBAW, TAS)
BOT
Mögliche Ausgänge einer Transaktion
Systemausfall,
Programm,
fehler
usw.
Transaktionen als dynamische Kontrollstruktur
6-4
Lies / Schreibe Seite
Stelle Seite bereit
Gib Seite frei
Select ... From ... Where
Insert ... Into
Füge Satz ein
Modifiziere Zugriffspfad
6-5
• Abbildung der Miniwelt
Realisierung verlangt vor allem
- Synchronisation im Mehrbenutzerbetrieb (concurrency transparency)
- Logging und Recovery (failure transarency)
SQL garantiert Anweisungsatomarität und natürlich Transaktionsatomarität!
SQL-Opn
...
SQL-Op1
Schutzmaßnahmen im Ausführungspfad des DBS funktionieren nicht!
Schichtenspezifische
Operationen
Schutzbedürfnis einer flachen Transaktion
und Zusicherungen an den Programmierer
Erhaltung der DB-Konsistenz
Reale Welt
Modell
Angestellter
Vorgesetzter
Manager
Abbildungsrichtung
• Erhaltung der semantischen Datenintegrität
- Beschreibung der „Richtigkeit“ von Daten durch Prädikate und Regeln,
bereits bekannt:
• modellinhärente Bedingungen (relationale Invarianten)
• anwendungsspezifische Bedingungen (Check, Unique, Not Null, ...)
- aktive Maßnahmen des DBS erwünscht (Trigger, ECA-Regeln)
- „Qualitätskontrollen“ bei Änderungsoperationen
• Ziel
- Nur DB-Änderungen zulassen, die allen definierten Constraints entsprechen
(offensichtlich „falsche“ Änderungen zurückweisen!)
- Möglichst hohe Übereinstimmung von DB-Inhalt und Miniwelt
(Datenqualität)
➥ Integritätsbedingungen der Miniwelt sind explizit bekannt zu machen,
um automatische Überwachung zu ermöglichen.
6-6
Warum Mehrbenutzerbetrieb?
Unkontrollierter Mehrbenutzerbetrieb
• Ausführung von Transaktionen
• Abhängigkeit von nicht freigegebenen Änderungen
t
Einbenutzerbetrieb
...
T1
...
T2
...
T2
read (A);
A := A + 100
write (A);
...
T3
Mehrbenutzerbetrieb
T1
...
...
read (A);
read (B);
B := B + A;
write (B);
commit;
T1
T2
T3
abort;
- CPU-Nutzung während TA-Unterbrechungen
- Geänderte, aber noch nicht freigegebene Daten werden als „schmutzig“
bezeichnet (dirty data), da die TA ihre Änderungen bis Commit (einseitig)
zurücknehmen kann
• E/A
• Denkzeiten bei Mehrschritt-TA
• Kommunikationsvorgänge in verteilten Systemen
- bei langen TA zu große Wartezeiten für andere TA (Scheduling-Fairness)
Anomalien im unkontrollierten Mehrbenutzerbetrieb
1. Abhängigkeit von nicht freigegebenen Änderungen
(dirty read, dirty overwrite)
- Schmutzige Daten dürfen von anderen TAs nicht in „kritischen” Operationen
benutzt werden
• Verlorengegangene Änderung (Lost Update)
T1
A in DB
read (A);
read (A);
2. Verlorengegangene Änderung (lost update)
3. Inkonsistente Analyse (non-repeatable read)
T2
A := A - 1;
write (A);
4. Phantom-Problem
A := A - 1;
5. Integritätsverletzung durch Mehrbenutzer-Anomalie
write (A);
6. Instabilität von Cursor-Positionen
➥ nur durch Änderungs-TA verursacht
6-7
➥ Verlorengegangene Änderungen sind auszuschließen!
6-8
6-9
6 - 10
Phantom-Problem
UPDATE Pers
SET Gehalt = Gehalt + 2000
WHERE Pnr = 3456
UPDATE Pers
SET Gehalt = Gehalt + 1000
WHERE Pnr = 2345
Änderungstransaktion
Lesetransaktion
IF gsumme <> summe THEN
<Fehlerbehandlung>
SELECT Gehaltssumme INTO :gsumme
FROM Abt
WHERE Anr = 17
SELECT SUM (Gehalt) INTO :summe
FROM Pers
WHERE Anr = 17
(Gehaltssumme überprüfen)
Zeit
3456
UPDATE Abt
SET Gehaltssumme = Gehaltssumme + 55.000
WHERE Anr = 17
INSERT INTO Pers (Pnr, Anr, Gehalt)
VALUES (4567, 17, 55.000)
(Einfügen eines neuen Angestellten)
Änderungstransaktion
48.000
3456
50.000
40.000
39.000
2345
2345
Gehalt)
DB-Inhalt
(Pnr,
Zeit
Einfügungen oder Löschungen können Leser zu falschen Schlussfolgerungen verleiten:
summe := summe + gehalt
SELECT Gehalt INTO :gehalt
FROM Pers
WHERE Pnr = 3456
SELECT Gehalt INTO :gehalt
FROM Pers
WHERE Pnr = 2345
summe := summe + gehalt
(Gehaltssumme berechnen)
Lesetransaktion
Das wiederholte Lesen einer gegebenen Folge von Daten führt auf verschiedene Ergebnisse:
Inkonsistente Analyse (Non-repeatable Read)
Synchronisation von Transaktionen
• TRANSAKTION: Ein Programm T mit DML-Anweisungen,
Synchronisation von Transaktionen (2)
• Beispiel für einige Ausführungsvarianten
das folgende Eigenschaft erfüllt:
Ausführung 1
Wenn T allein auf einer konsistenten DB ausgeführt wird, dann terminiert T
(irgendwann) und hinterlässt die DB in einem konsistenten Zustand.
(Während der TA-Verarbeitung gibt es keine Konsistenzgarantien!)
T1
Ausführung 2
T2
T1
read (A)
T2
read (A)
read (B)
read (B)
B-2
B+1
write (A)
write (A)
B-2
write (B)
read (B)
write (B)
write (B)
read (B)
read (C)
B+1
C+2
write (B)
read (B)
write (B)
B-2
B+1
read (C)
read (C)
C+2
write (B)
C+2
write (C)
T3
T2
A-1
A-1
read (B)
T2
T1
read (A)
A-1
write (A)
• Ablaufpläne für 3 Transaktionen
T1
Ausführung 3
write (C)
write (C)
➥ Bei serieller Ausführung bleibt der Wert von A + B + C unverändert!
verzahnter
Ablaufplan
serieller
Ablaufplan
• Was ist das Ergebnis der verschiedenen Ausführungsvarianten?
A
➥ Wenn Transaktionen seriell ausgeführt werden, dann bleibt die
Konsistenz der DB erhalten.
• Ziel der Synchronisation:
B
C
initialer Wert
nach T1; T2
nach Ausf. 2
logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien
nach Ausf. 3
nach T2; T1
➥ Fundamentale Fragestellung:
Wann ist die parallele Ausführung von n Transaktionen
auf gemeinsamen Daten korrekt?
6 - 11
- Ziel: Äquivalenz der Ergebnisse von verzahnten Ausführungen
zu einer der möglichen seriellen Ausführungen
6 - 12
A+B+C
Modellbildung für die Synchronisation
• Wie kann die Korrektheit der Ausführung im Mehrbenutzerbetrieb
überprüft werden?
- Korrektheitskriterium: Konfliktserialisierbarkeit
Synchronisation – Modellannahmen
• Read/Write-Modell (Page Model)
- DB ist Menge von unteilbaren, uninterpretierten Datenobjekten
(z. B. Seiten)
- Geschichtsschreiber zeichnet Historie H auf
• Umformung der aufgezeichneten Operationsfolge H in eine
äquivalente serielle Operationsfolge
- DB-Anweisungen lassen sich nachbilden durch atomare Lese- und Schreiboperationen auf Objekten:
• ri[A], wi[A] zum Lesen bzw. Schreiben des Datenobjekts A
• „post mortem“-Analyse
• ci , ai zur Durchführung eines commit bzw. abort
• Tatsächliche Umsetzung
- Scheduler überprüft jede Operation Opi und erzwingt einen
serialisierbaren Ablaufplan S (Schedule)
• wenn Opi in S konfliktfrei ist, wird sie ausgeführt
und an S angehängt
• sonst wird Opi blockiert oder gar die zugehörige Transaktion
zurückgesetzt
- Transaktion wird modelliert als eine endliche Folge von Operationen p i:
T = p1 p2 p3 ... pn
mit
pi ∈ {r[xi], w[xi]}
- Eine vollständige TA hat als letzte Operation entweder einen Abbruch a
oder ein Commit c
T = p1 ... pn a
oder
T = p1 ... pn c
➥ Für eine TA Ti werden diese Operationen mit ri, wi, ci oder ai
bezeichnet, um sie zuordnen zu können
• Die Ablauffolge von TA mit ihren Operationen lässt sich wie folgt
beschreiben:
r1[A] r2[A] r3[B] w1[A] w3[B] r1[B] c1 r3[A] w2[A] a2 w3[C] c3 ...
6 - 13
6 - 14
Korrektheitskriterium der Synchronisation
Konsistenzerhaltende Ablaufpläne
• Serieller Ablauf von Transaktionen
• Die TA T1-T3 müssen so synchronisiert werden, dass der resultierende Zustand der DB gleich dem ist, der bei der seriellen Ausführung in
einer der folgenden Sequenzen zustande gekommen wäre:
TA = {T1, T2, T3}
DB = {A, B, C}
T1
A
T1, T2, T3
T1, T3, T2
C
B
T2
T2, T1, T3
T2, T3, T1
T3, T1, T2
T3, T2, T1
C
• Bei n TA gibt es n! (hier 3! = 6) mögliche serielle Ablaufpläne
A
T3
B
t
• Serielle Ablaufpläne können verschiedene Ergebnisse haben!
Ausführungsreihenfolge:
Abbuchung/Einzahlung auf Konto: TA1: - 5000; TA2: + 2000
Konto
• T1 | T2 bedeutet:
Stand = 2000
Limit = 2000
T1 sieht keine Änderungen von T2 und
T2 sieht alle Änderungen von T1
• Formales Korrektheitskriterium: Serialisierbarkeit:
• Nicht alle seriellen Ablaufpläne sind möglich!
Die parallele Ausführung einer Menge von TA ist serialisierbar,
wenn es eine serielle Ausführung derselben TA-Menge gibt,
die den gleichen DB-Zustand
und die gleichen Ausgabewerte
wie die ursprüngliche Ausführung erzielt.
r [x]
T1
w [z]
r [y]
T2
w [x]
T3
T4
• Hintergrund:
w [y]
r [x]
- Serielle Ablaufpläne sind korrekt!
- Jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar
6 - 15
6 - 16
Theorie der Serialisierbarkeit
Theorie der Serialisierbarkeit (2)
• Ablauf einer Transaktion
• Historie2
- Häufigste Annahme: streng sequentielle Reihenfolge der Operationen
- Unter einer Historie versteht man den Ablauf einer (verzahnten)
Ausführung mehrerer TA
- Serialisierbarkeitstheorie lässt sich auch auf Basis einer partiellen Ordnung
(<i) entwickeln
- Sie spezifiziert die Reihenfolge, in der die Elementaroperationen
verschiedener TA ausgeführt werden
- TA-Abschluss: abort oder commit – aber nicht beides!
• Einprozessorsystem: totale Ordnung
• Konsistenzanforderungen an eine TA
- Falls Ti ein abort durchführt, müssen alle anderen Operationen pi[A] vor ai
ausgeführt werden: pi[A] <i ai
• Mehrprozessorsystem: parallele Ausführung einiger Operationen
möglich ➥ partielle Ordnung
• Konfliktoperationen:
Kritisch sind Operationen verschiedener Transaktionen
auf denselben DB-Daten,
wenn diese Operationen nicht reihenfolgeunabhängig sind!
- Analoges gilt für das commit: pi[A] <i ci
- Wenn Ti ein Datum A liest und auch schreibt, ist die Reihenfolge festzulegen:
ri[A] <i wi[A]
oder
wi[A] <i ri[A]
• Was sind Konfliktoperationen?
- ri[A] und rj[A]: Reihenfolge ist irrelevant
• Beispiel: Überweisungs-TA T1 (von K1 nach K2)
r1[K1]
oder
r1[K1]
w1[K1]
w1[K1]
r1[K2]
➥ kein Konflikt!
r1[K2]
w1[K2]
- ri[A] und wj[A]: Reihenfolge ist relevant und festzulegen.
c1
Entweder ri[A] → wj[A]
w1[K2]
➥ R/W-Konflikt!
c1
oder wj[A] → ri[A]
➥ W/R-Konflikt!
- Totale Ordnung: r1[K1] → w1[K1] → r1[K2] → w1[K2] → c1
- wi[A] und rj[A]: analog
- Partielle Ordnung
r1[K1] → w1[K1]
r1[K2] → w1[K2]
- wi[A] und wj[A] Reihenfolge ist relevant und festzulegen
➥ W/W-Konflikt!
c1
2.
6 - 17
Der Begriff Historie bezeichnet eine retrospektive Sichtweise, also einen abgeschlossenen Vorgang. Ein Scheduling-Algorithmus (Scheduler) produziert Schedules, wodurch noch nicht abgeschlossene Vorgänge bezeichnet werden. Manche Autoren machen jedoch keinen Unterschied zwischen Historie und Schedule.
6 - 18
Theorie der Serialisierbarkeit (3)
• Beschränkung auf Konflikt-Serialisierbarkeit3
Theorie der Serialisierbarkeit (4)
• Beispiel-Historie für 3 TA
• Historie H für eine Menge von TA {T1, ..., Tn}
ist eine Menge von Elementaroperationen mit partieller Ordnung <H,
r2[A] →
↑
so dass gilt:
H=
n
1. H =
∪
w2[B] →
r3[B] →
w3[A] →
w2[C] → c2
↑
w3[B] →
↑
w3[C] → c3
↑
Ti
r1[A] →
i=1
w1[A] →
c1
2. <H ist verträglich mit allen <i-Ordnungen, d.h.
n
<H ⊇
∪
i
<i
- Reihenfolge konfliktfreier Operationen (zwischen TA) wird nicht spezifiziert
1
3. Für zwei Konfliktoperationen p, q ∈ H gilt entweder
p <H q
- Mögliche totale Ordnung4
oder
H1 = r1[A] → r3[B] → w1[A] → w3[A] → c1 → r2[A] → w3[B] →
q <H p
w3[C] → c3 → w2[B] → w2[C] → c2
• Ein Schedule ist ein Präfix einer Historie
3.
In der Literatur werden verschiedene Formen der Serialisierbarkeit, also der Äquivalenz zu einer seriellen Historie, definiert. Die Final-State-Serialisierbarkeit besitzt die geringsten Einschränkungen. Intuitiv sind zwei
Historien (mit der gleichen Menge von Operationen) final-state-äquivalent, wenn sie jeweils denselben Endzustand für einen gegebenen Anfangszustand herstellen. Historien mit dieser Eigenschaft sind in der Klasse FSR
zusammengefasst. Die View-Serialisierbarkeit (Klasse VSR) schränkt FSR weiter ein. Die hier behandelte
Konflikt-Serialisierbarkeit (Klasse CSR) ist für praktische Anwendungen die wichtigste. Sie ist effizient überprüfbar und unterscheidet sich bereits dadurch wesentlich von den beiden anderen Serialisierbarkeitsbegriffen.
Es gilt: CSR
⊂ VSR ⊂ FSR
4.
6 - 19
Alternative Schreibweise bei einer totalen Ordnung: Weglassen der →
6 - 20
Theorie der Serialisierbarkeit (5)
• Definition: Äquivalenz zweier Historien
Serialisierbare Historie
• Eine Historie H ist serialisierbar, wenn sie äquivalent zu einer seriellen
- Zwei Historien H und H’ sind äquivalent, wenn sie die Konfliktoperationen
der nicht abgebrochenen TA in derselben Reihenfolge ausführen:
H ≡ H’, wenn pi <H qj, dann auch pi <H’ qj
Historie Hs ist
- Einführung eines Konfliktgraph G(H)
(auch Serialisierbarkeitsgraph SG(H) genannt)
• Konstruktion des G(H) über den erfolgreich abgeschlossenen TA
- Anordnung der konfliktfreien Operationen ist irrelevant
- Reihenfolge der Operationen innerhalb einer TA bleibt invariant
• Konfliktoperationen pi, qj aus H mit pi <H qj fügen eine Kante Ti → Tj
in G(H) ein, falls nicht schon vorhanden
- Beispiel-Historie
r1[A] →
• Beispiel
H=
r1[A] →
r2[A] →
w2[B] →
↑
↑
w1[A] →
w1[B] →
w1[A] →
w1[B] →
↑
c2
r2[A]
H=
c1
↑
→
w2[B] →
c2
↓
c1
r3[A] →
w3[A] →
c3
- Zugehöriger Konfliktgraph
- Totale Ordnung
H1 = r1[A] → w1[A] → r2[A] → w1[B] → c1 → w2[B] → c2
H2 = r1[A] → w1[A] → w1[B] → c1 → r2[A] → w2[B] → c2
G(H):
• Serialisierbarkeitstheorem
Eine Historie H ist genau dann serialisierbar, wenn der zugehörige
Konfliktgraph G(H) azyklisch ist
H1 ≡ H2 (ist seriell)
➥ Topologische Sortierung!
• CSR
bezeichne die Klasse aller konfliktserialisierbaren Historien. Die Mitgliedschaft in
CSR lässt sich in Polynomialzeit in der Menge der teilnehmenden TA testen
6 - 21
6 - 22
Serialisierbare Historie (2)
• Historie
Serialisierbare Historie (3)
• Anforderungen an im DBMS zugelassene Historien
- Serialisierbarkeit ist eine Minimalanforderung
H=
w1[A] → w1[B] → c1 → r2[A] → r3[B] → w2[A] → c2 → w3[B] → c3
- TA Tj sollte zu jedem Zeitpunkt vor Commit lokal rücksetzbar sein
• andere mit Commit abgeschlossene Ti dürfen nicht betroffen sein
• kritisch sind Schreib-/Leseabhängigkeiten
wj[A] → ... → ri[A]
• Konfliktgraph
• Ti darf erst nach Tj ein Commit durchführen
- Rücksetzen von TA Tj sollte kein kaskadierendes Rücksetzen verursachen
G(H) :
• andere noch nicht abgeschlossene Ti dürfen nicht betroffen sein
• Ti darf Änderungen von Tj erst nach dem Commit von Tj sehen
- Wie kritisch für das lokale Rücksetzen von Tj sind
• Topologische Ordnungen
Hs1 = w1[A] → w1[B] → c1 → r2[A] → w2[A] → c2 → r3[B] → w3[B] → c3
ri[A] → ... → wj[A]
oder
wj[A] → ... → wi[A]
Hs1 = T1 | T2 | T3
oder
wi[A] → ... → wj[A]
Hs2 = w1[A] → w1[B] → c1 → r3[B] → w3[B] → c3 → r2[A] → w2[A] → c2
Hs2 = T1 | T3 | T2
H ≡ Hs1 ≡ Hs2
6 - 23
6 - 24
Zweiphasen-Sperrprotokolle 5
RX-Sperrverfahren
• Sperrmodi
• Einhaltung folgender Regeln gewährleistet Serialisierbarkeit:
- Sperrmodus des Objektes: NL (no lock), R (read), X (exclusive)
1. Vor jedem Objektzugriff muss Sperre mit ausreichendem Modus
angefordert werden
- Sperranforderung einer Transaktion: R, X
2. Gesetzte Sperren anderer TA sind zu beachten
• Kompatibilitätsmatrix:
ModusÜbergang
NL
R
X
aktueller Modus
des Objekts
NL
R
X
angeforderter
Modus der TA
R
+
+
-
R
R
R
-
X
+
-
-
X
X
-
-
3. Eine TA darf nicht mehrere Sperren für ein Objekt anfordern
4. Zweiphasigkeit:
- Anfordern von Sperren erfolgt in einer Wachstumsphase
- Freigabe der Sperren in Schrumpfungsphase
- Sperrfreigabe kann erst beginnen, wenn alle benötigten Sperren
gehalten werden
- Falls Sperre nicht gewährt werden kann, muss die anfordernde TA warten, bis
das Objekt freigegeben wird (Commit/Abort der die Sperre besitzenden TA)
5. Spätestens bei Commit sind alle Sperren freizugeben
- Wartebeziehungen werden in einem Wait-for-Graph (WfG) verwaltet
• Beispiel für ein 2PL-Protokoll (2PL: two-phase locking)
• Ablauf von Transaktionen
T1
T2
lock (a, X)
BOT
a
b
NL
NL
Bem.
X1
R2
...
unlock (b)
...
lock (b, R)
unlock (c)
R2, R1
lock (a, R)
- dynamische Entscheidung:
Sperr-Escalation
...
lock (c, X)
...
lock (b, R)
Zugriff auf n Sätze einer Tabelle
- einzelne Sätze oder
ganze Tabelle sperren?
lock (a, X)
...
lock (b, R)
X1
T2 wartet,
WfG:
NL --> R2
T2 wecken
unlock (a)
Commit
...
unlock (a)
...
An der SQL-Schnittstelle ist die Sperranforderung und -freigabe nicht sichtbar!
...
unlock(b)
R2
6 - 25
5.
Eswaran, K.P. et al.: The notions of consistency and predicate locks in a data base system,
in: Comm. ACM 19:11, 1976, 624-633
6 - 26
Zweiphasen-Sperrprotokolle (2)
• Formen der Zweiphasigkeit
Sperranforderung
und -freigabe
Zweiphasen-Sperrprotokolle (3)
• Strikte 2PL-Protokolle
- SS2PL (strong 2PL) gibt alle Sperren (X und R) erst bei Commit frei
- S2PL (strict 2PL) gibt alle X-Sperren erst bei Commit frei
#Sperren
- Sie verhindern dadurch kaskadierendes Rücksetzen
zweiphasig:
BOT
EOT
BOT
EOT
strikt
zweiphasig:
➥ Auftreten von Verklemmungen (Deadlocks) ist inhärent und kann bei
pessimistischen Methoden (blockierende Verfahren) nicht vermieden werden.
• Nicht-serialisierbare Historie
läuft vor ab
preclaiming:
BOT
EOT
T1
w(a)
w(c)
• Anwendung des 2PL-Protokolls
T1
BOT
lock (a, X)
read (a)
write (a)
T2
Bem.
BOT
lock (a, X)
T2 wartet: WfG
lock (b, X)
read (b)
unlock (a)
r(c)
T2
T3
SG
w(b)
r(b)
r(a)
• RX-Verfahren verhindert das Auftreten einer nicht-serialisierbaren Historie,
aber nicht (immer) Deadlocks
wartet auf
T2 wecken
read (a)
write (a)
unlock (a)
commit
T1
T2
unlock (b)
T3
X(a)
WfG
X(c)
R(c)
X(b)
R(b)
R(a)
➥ Zweiphasiges Protokoll reicht für den praktischer Einsatz nicht aus!
6 - 27
6 - 28
Logging und Recovery 6
Logging und Recovery (2)
transient
Hauptspeicher
• Aufgabe des DBMS:
Automatische Behandlung aller erwarteten Fehler
A
A‘
B
T1
• Was sind erwartete Fehler?
Crash
B‘
T6
7
- DB-Operation wird zurückgewiesen, Commit wird nicht akzeptiert, . . .
T2
T4
T7
- Stromausfall, DBMS-Probleme, . . .
- Geräte funktionieren nicht (Spur, Zylinder, Platte defekt)
C
C‘
T5
T3
- auch beliebiges Fehlverhalten der Gerätesteuerung?
- falsche Korrektur von Lesefehlern? . . .
• Fehlermodell von zentralisierten DBMS
- Transaktionsfehler (z. B. Deadlock) → Transaktions-Recovery
A
B
C
nicht-atomares
Einbringen von Seiten
A
B‘
C‘
materialisierte
DB
permanent
Externspeicher
- Systemfehler (Verlust aller HSP-Inhalte) → Crash-Recovery
- Gerätefehler → Medien-Recovery
- Katastrophen → Katastrophen-Recovery
• Erhaltung der physischen Datenintegrität
- Periodisches Erstellen von Datenkopien
- Führen von Änderungsprotokollen für den Fehlerfall (Logging)
- Bereitstellen von Wiederherstellungsalgorithmen im Fehlerfall
(Recovery)
• Logging
Sammeln von Redundanz im Normalbetrieb,
um für den Fehlerfall gerüstet zu sein
• DBMS garantiert physische Datenintegrität
- Bei jedem Fehler (z. B. Ausfall des Rechners, Crash des Betriebssystems
oder des DBMS, Fehlerhaftigkeit einzelner Transaktionsprogramme) wird
eine „korrekte“ Datenbank rekonstruiert
- Nach einem (Teil-)Crash ist immer der jüngste transaktionskonsistente
Zustand der DB zu rekonstruieren, in dem alle Änderungen von
Transaktionen enthalten sind, die vor dem Zeitpunkt des Fehlers
erfolgreich beendet waren (T1 bis T4) und sonst keine
- automatische Wiederherstellung bei Restart (Wiederanlauf) des Systems
• Maßnahmen beim Wiederanlauf (siehe auch Beispiel)
- Ermittlung der beim Crash aktiven Transaktionen (T5, T6, T7)
- Wiederholen (REDO) der Änderungen von abgeschlossenen Transaktionen,
die vor dem Crash nicht in die Datenbank zurückgeschrieben waren (A → A‘)
6.
7.
Härder, T., Reuter, A.: Principles of Transaction Oriented Database Recovery,
in: ACM Computing Surveys 15:4, Dec. 1983, 287-317.
Kommerzielle Anwendungen auf Großrechnern sind durch ihre Zuverlässigkeit gekennzeichnet.
Nicht selten besteht der Code bis zu 90% aus (erprobten) Recovery-Routinen (W. G. Spruth).
6 - 29
- Rücksetzen (UNDO) der Änderungen der aktiven Transaktionen in der Datenbank (B‘ → B)
6 - 30
Schnittstelle zwischen AP und DBS –
transaktionsbezogene Aspekte
Zusammenfassung
• Transaktionsparadigma
Aktionen auf Seite
des AP
Aktionen auf Seite
des DBS
- Verarbeitungsklammer für die Einhaltung der Constraints des DB-Schemas
- Verdeckung der Nebenläufigkeit (concurrency isolation)
➥ Synchronisation
Sicherstellen der Rücksetzbarkeit von Änderungsoperationen
BOT
•
•
•
➥ Logging und Recovery
• Beim ungeschützten und konkurrierenden Zugriff von Lesern und
Befehle
Op
i
Ausführen von DML-Befehlen
(Überprüfen der unverzögerten
Integritätsbedingungen)
•
•
•
Schreibern auf gemeinsame Daten können Anomalien auftreten
• Theorie der Serialisierbarkeit
- Konfliktoperationen:
EOT
(Überprüfen der verzögerten
Integritätsbedingungen)
C
O
2PC
- Verdeckung von (erwarteten) Fehlerfällen (failure isolation)
Phase 1
Sicherstellen der Wiederholbarkeit
aller Änderungen
M
Freigabe der Betriebsmittel
M
Phase 2
(Sperren)
I
Kritisch sind Operationen verschiedener Transaktionen auf denselben
DB-Daten, wenn diese Operationen nicht reihenfolgeunabhängig sind!
- Serialisierbarkeitstheorem:
Eine Historie H ist genau dann serialisierbar, wenn der zugehörige
Konfliktgraph G(H) azyklisch ist
• Realisierung der Synchronisation durch Sperrverfahren
- Sperren stellen während des laufenden Betriebs sicher, dass die
resultierende Historie serialisierbar bleibt
- Bei einer Konfliktoperation blockieren sie den Zugriff auf das Objekt
(Deadlock-Problem ist inhärent)
➥ Sperrverfahren sind pessimistisch und universell einsetzbar
T
Bestätigung über erfolgreiches
Ende an das AP
Weiterarbeit
im AP
• Logging und Recovery
- Automatische Behandlung von Fehlern
- Fehlerarten: Transaktions-, System-, Gerätefehler und Katastrophen
6 - 31
6 - 32