Architektur von Datenbanksystemen - fbi.h

KAPITEL 6
TRANSAKTIONSVERWALTUNG UND
RECOVERY
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
1
Einordnung in die 5-Schichten-Architektur
Mengenorientierte Schnittstelle
Datensystem
Transaktionsverwaltung
Recovery
Satzorientierte Schnittstelle
Zugriffssystem
Interne Satzschnittstelle
Speichersystem
Systempufferschnittstelle
Pufferverwaltung
Dateischnittstelle
Betriebssystem
Geräteschnittstelle
Externspeicher
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
2
Transaktionsverwaltung und Recovery
Inhalte des Kapitels
• Transaktionsverwaltung
– Transaktionsbegriff (ACID)
Wiederholung DB (Bachelor)
– Synchronisation und Sperren
– Isolation Level in SQL
– MVCC
– Hierarchische Sperren
– Isolation Level und Sperren in relationalen DBMS
• Recovery
– Fehlerklassen
– Recovery-Strategien
Lernziele
• Verständnis für Synchronisationsbegriff
• Kenntnis verschiedener Sperrverfahren
• Kenntnis der Fehlerklassen und der unterschiedlichen Recovery-Strategien
• Verständnis der Auswirkungen der Recovery-Anforderungen auf den Puffer-Manager
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
3
Wiederholung
DB (Bachelor)
Transaktionsbegriff
Transaktionen
• Eine Transaktion ist eine Folge von Operationen (Aktionen), welche die
Datenbank von einem konsistenten Zustand in einen konsistenten,
eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip
eingehalten werden muss.
• Aspekte:
– Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach
Ende der Transaktion
– Ablaufintegrität: Fehler durch „gleichzeitigen“ Zugriff mehrerer
Benutzer auf dieselben Daten vermeiden
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
4
Wiederholung
DB (Bachelor)
ACID-Eigenschaften
• Atomicity (Atomarität):
– Transaktion wird entweder ganz oder gar nicht ausgeführt
 Mechanismen zur Fehlerbehandlung notwendig.
• Consistency (Konsistenz oder auch Integritätserhaltung):
– Datenbank ist vor Beginn und nach Beendigung einer Transaktion
jeweils in einem konsistenten Zustand
 Mechanismen zur Konsistenzsicherung und Fehlerbehandlung
notwendig.
• Isolation (Isolation):
– Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck
haben, dass er mit dieser Datenbank alleine arbeitet
 Mechanismen zur Mehrbenutzersynchronisation notwendig.
• Durability (Dauerhaftigkeit / Persistenz):
– nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis
dieser Transaktion „dauerhaft“ in der Datenbank gespeichert
werden
 Mechanismen zur Fehlerbehandlung notwendig.
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
5
Wiederholung
DB (Bachelor)
Mehrbenutzerbetrieb
• Probleme im (unkontrolliertem) Mehrbenutzerbetrieb
– Verlorengegangenes Ändern (lost update)
– Abhängigkeiten von nicht freigegebenen Daten (dirty read)
– Inkonsistentes Lesen (non repeatable read)
– Phantom-Problem
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
6
Wiederholung
DB (Bachelor)
•
Verlorengegangene Änderungen
(lost update)
Zwei Programme („Überweisung“ und „Zinsgutschrift“) arbeiten
gleichzeitig auf der Datenbank:
Zeit Transaktion 1
1
2
3
4
5
6
7
8
9
10
11
Transaktion 2
read (A,a1)
a1 := a1 - 50
read (A,a2)
a2 = a2 * 1.03
write (A, a2)
commit
write (A,a1)
read (B,b1)
b1 := b1 + 50
write (B,b1)
commit
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Zustand von A
auf der Datenbank
1000
…
…
…
1030
…
950
…
…
…
950
Kapitel 6: Transaktionsverwaltung und Recovery
7
Wiederholung
DB (Bachelor)
Abhängigkeit von nicht
freigegebenen Änderungen (dirty read)
• Der neue Mitarbeiter B soll 10% mehr als Mitarbeiter A verdienen.
• Mitarbeiter A erhält eine Gehaltserhöhung um 100 Euro.
Diese Transaktion wird abgebrochen, da am Ende der Transaktion die
Verletzung einer Integritätsbedingung festgestellt wird (z.B. Maximalgrenze für
Gehalt einer bestimmten Tarifgruppe verletzt).
Zeit Transaktion 1
1
2
3
4
5
6
7
9
Transaktion 2
read (A,a1)
a1 := a1 + 100
write (A,a1)
read (A,a2)
b1 = a2 * 1.1
write (B, b1)
commit
abort
A
B
2500
2500
2600
…
…
…
2600
2500
2860
2860
2860
• Problem?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
8
Inkonsistente Analyse
(non repeatable read)
Wiederholung
DB (Bachelor)
• Die Summe der Gehälter aller Mitarbeiter wird ermittelt.
• Parallel dazu werden die Gehälter der Mitarbeiter um jeweils 1.000 Euro
erhöht.
Zeit Transaktion 1
1
2
3
4
5
6
7
8
9
10
11
12
Transaktion 2
read (A, a1)
summe = summe + a1
read (A, a2)
a2 = a2 + 1000
write (A, a2)
read (B, b2)
b2 = b2 + 1000
write (B, b2)
commit
read (B, b1)
summe = summe + b1
commit
• Problem?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
9
Wiederholung
DB (Bachelor)
Phantom-Problem
• Ein Bonus von 100.000 Euro soll gleichmäßig auf alle Mitarbeiter der
Firma verteilt werden.
• Parallel dazu wird ein neuer Mitarbeiter eingefügt.
Zeit Transaktion 1
1
select count(*) into X
from Mitarbeiter;
2
3
4
5
Transaktion 2
insert into Mitarbeiter
values (Meier, 50.000, …);
commit;
update Mitarbeiter
set Gehalt = Gehalt + 100.000/X;
commit;
• Problem?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
10
Wiederholung
DB (Bachelor)
Synchronisation von
Transaktionen: Modell
Ziel der Synchronisation: Vermeidung aller Mehrbenutzeranomalien
Modell
• Wenn Transaktionen seriell ausgeführt werden, dann bleibt die
Konsistenz der DB erhalten.
• Transaktion: BOT, Folge von READ- und WRITE-Anweisungen, EOT
• Die Ablauffolge von Transaktionen mit ihren Operationen kann durch
einen Schedule beschrieben werden
(BOT ist implizit, EOT wird durch ci (commit) oder ai (abort) dargestellt):
– Beispiel:
r1(x), r2(x), r3(y), w1(x), w3(y), r1(y), c1, r3(x), w2(x), a2, w3(x), c3, ...
– Beispiel eines seriellen Schedules :
r1(x), w1(x), r1(y), c1, r3(y), w3(y), r3(x), c3, r2(x), w2(x), c2,...
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
11
Wiederholung
DB (Bachelor)
Korrektheitskriterium der
Synchronisation: Serialisierbarkeit – 1(2)
• Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h.
Vermeidung aller Mehrbenutzeranomalien
• Gleichbedeutend mit formalem Korrektheitskriterium der
Serialisierbarkeit:
– Die parallele Ausführung einer Menge von n Transaktionen ist
serialisierbar, wenn es eine serielle Ausführung derselben
Transaktionen gibt, die den gleichen DB-Zustand und die gleichen
Ausgabewerte wie die ursprüngliche Ausführung erzielt.
• Hintergrund:
– serielle Ablaufpläne sind korrekt
– jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist
akzeptierbar
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
12
Wiederholung
DB (Bachelor)
Korrektheitskriterium der
Synchronisation: Serialisierbarkeit – 2(2)
Transaktion 1
Transaktion 2
T1 - 1
T1 - 2
T1 - 3
Transaktion 3
T2 - 1
T2 - 2
T2 - 3
T3 - 1
T3 - 2
(Quasi-) parallele Ausführung …
T1 - 1
T2 - 1
T3 - 1
T1 - 2
T1 - 3
T2 - 2
T2 - 3
T3 - 2
h_da Prof. Dr. Uta Störl
Die parallele Ausführung einer Menge von n
Transaktionen ist serialisierbar, wenn es eine
serielle Ausführung derselben Transaktionen
gibt, die den gleichen DB-Zustand und die
gleichen Ausgabewerte wie die ursprüngliche
Ausführung erzielt.
Architektur von DBMS WS 2015/16
T2 - 1
T2 - 2
T2 - 3
T3 - 1
T3 - 2
T1 - 1
T1 - 2
T1 - 3
Kapitel 6: Transaktionsverwaltung und Recovery
13
Wiederholung
DB (Bachelor)
Nachweis der Serialisierbarkeit – 1(2)
• Ansatz: Führen von zeitlichen Abhängigkeiten zwischen Transaktionen
in einem Abhängigkeitsgraphen (Konfliktgraphen)
• Abhängigkeit (Konflikt) besteht, wenn zwei Transaktionen auf dasselbe
Objekt mit nicht reihenfolgeunabhängigen Operationen zugreifen.
• Konfliktarten:
– Schreib-/Lese-Konflikt
w(x) r(x)
– Lese-/Schreib-Konflikt
r(x) w(x)
– Schreib-/Schreib-Konflikt w(x) w(x)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
14
Wiederholung
DB (Bachelor)
Nachweis der Serialisierbarkeit – 2(2)
r (x)
w (y)
T1
r (y)
T2
w (x) ?
T2
w (x)
T3
T1
T3
• Serialisierbarkeit liegt vor, wenn der Abhängigkeitsgraph keine Zyklen
enthält
• Abhängigkeitsgraph beschreibt partielle Ordnung zwischen
Transaktionen, die sich zu einer vollständigen erweitern lässt
(Serialisierungsreihenfolge)
im Beispiel: T3 → T1 → T2
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
15
Wiederholung
DB (Bachelor)
Sperren
• Berechnung des Abhängigkeitsgraphen ist für den
Korrektheitsnachweis von Synchronisationsverfahren interessant, aber
weniger für den direkten Einsatz im DBMS geeignet
(Ausnahme: optimistische Sperrverfahren)
 Praktische Umsetzung in DBMS: Sperren
– Zwei Arten von Sperren
• rl(x) Lesesperre (read lock bzw. shared lock) auf Objekt x
• wl(x) Schreibsperre (write lock bzw. exclusive lock)
– Kompatibilitätsmatrix
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
16
Wiederholung
DB (Bachelor)
Zwei-Phasen-Sperrprotokolle
(2 Phase Locking, 2PL)
Einhaltung folgender Regeln gewährleistet Serialisierbarkeit:
1. Vor jedem Objektzugriff muss Sperre mit ausreichendem Modus
angefordert werden
– Schreibzugriff w(x) nur nach Setzen einer Schreibsperre wl(x)
möglich
– Lesezugriffe r(x) nur nach rl(x) oder wl(x) erlaubt
2. Gesetzte Sperren anderer Transaktionen sind zu beachten
– Nur Lesesperren sind „verträglich“
3. Zweiphasigkeit:
– Anfordern von Sperren erfolgt in einer Wachstumsphase
– Freigabe der Sperren in Schrumpfungsphase
– Sperrfreigabe kann erst beginnen, wenn alle Sperren gehalten
werden
4. Spätestens bei EOT sind alle Sperren freizugeben
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
17
Wiederholung
DB (Bachelor)
Zwei-Phasen-Sperrprotokoll (2PL)
• 2PL garantiert Serialisierbarkeit in einer fehlerfreien Umgebung
• aber: Fehler während Schrumpfungsphase können zu dirty read führen!
• Lösungsalternativen
– Lesen schmutziger Daten und Abhängigkeiten bei commit überprüfen
(Problem: kaskadierende Rollbacks).
– Besser: Strikte Zwei-Phasen-Sperrverfahren mit Sperrfreigabe nach commit.
#Sperren
2PL
BOT
h_da Prof. Dr. Uta Störl
Wachstum
Architektur von DBMS WS 2015/16
Schrumpfung EOT Zeit
Kapitel 6: Transaktionsverwaltung und Recovery
18
Wiederholung
DB (Bachelor)
Striktes Zwei-Phasen-Sperrprotokoll (S2PL)
• alle Sperren werden bis EOT gehalten
 damit ist kaskadierendes Rücksetzen ausgeschlossen
• Nachteil?
#Sperren
S2PL
EOT
BOT
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Zeit
Kapitel 6: Transaktionsverwaltung und Recovery
19
Wiederholung
DB (Bachelor)
Verklemmungen (deadlocks)
T1
T2
Bemerkung
wl(x)
wl(y)
wl(y)
wl(x)
T1 muss auf T2 warten
T2 muss auf T1 warten
 deadlock
 DBMS muss deadlock erkennen und eine der beiden Transaktionen
abrechen – verschiedene Strategien:
– ältere Transaktion oder jüngere Transaktion
– Analyse des Wartegraphens (minimale Auswirkungen berechnen)
– Timeout-Verfahren
– ...
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
20
Wiederholung
DB (Bachelor)
Konservative Sperrprotokolle
(C2PL, C2PL)
• Alternative Variante: Preclaiming in Verbindung mit dem strikten 2PL
oder S2PL  C2PL bzw. CS2PL
• Problem?
#Sperren
CS2PL
BOT
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
EOT
Zeit
Kapitel 6: Transaktionsverwaltung und Recovery
21
Wiederholung
DB (Bachelor)
Phantom-Problem:
Sperren als Lösung?
• Ein Bonus von 100.000 Euro soll gleichmäßig auf alle Mitarbeiter der Firma
verteilt werden.
• Parallel dazu wird ein neuer Mitarbeiter eingefügt.
Zeit
1
T1
select count(*) into X
from Mitarbeiter;
2
3
4
5
T2
insert into Mitarbeiter
values (Meier, 50.000, …);
commit;
update Mitarbeiter
set Gehalt = Gehalt + 100.000/X;
commit;
• Sperren?
• Lösung?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
22
Wiederholung
DB (Bachelor)
Phantom-Problem: Lösung
• Zusätzlich zu den Tupeln muss auch der Zugriffweg, auf dem man zu
den Objekten gelangt ist, gesperrt werden.
• Beispiel:
– select count(*) into X from Mitarbeiter;
 alle Mitarbeiter (bzw. deren Primärschlüssel-Index) müssen mit
einer RL-Sperre belegt werden
 beim Einfügen eines neuen Mitarbeiter wird dies erkannt und T2
muss warten
• Sperre kann ggf. auch selektiver sein – z.B.:
– select count(*) into X from Mitarbeiter
where PNr between 1000 and 2000
 nur die Mitarbeiter mit der entsprechenden PNr müssen gesperrt
werden (z.B. Index-Bereich von PNr[1000,2000])
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
23
Wiederholung
DB (Bachelor)
Isolation Level in SQL
set transaction
[ { read only | read write } , ]
[ isolation level
{ read uncommitted |
read committed
|
repeatable read |
serializable } ]
• Beispiel (erstes Statement innerhalb der Transaktion)
set transaction read only, isolation level read committed;
select ...;
commit;
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
24
Wiederholung
DB (Bachelor)
Bedeutung der Isolationsstufen
• read uncommitted
– schwächste Stufe: Zugriff auf nicht geschriebene Daten,
nur für read only Transaktionen (sonst wäre lost update möglich!)
– 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
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
25
Wiederholung
DB (Bachelor)
Auswirkung der Isolationsstufen
Konsistenzebene
Anomalie
dirty read
non repeatable read
Phantome
read uncommitted
+
+
+
read committed
-
+
+
repeatable read
-
-
+
serializable
-
-
-
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
26
Transaktionsverwaltung und Recovery
• Transaktionsverwaltung
 Transaktionsbegriff
 Synchronisation und Sperren
 Isolation Level in SQL
– MVCC
– Hierarchische Sperren
– Isolation Level und Sperren in relationalen DBMS
• Recovery
– Fehlerklassen
– Recovery-Strategien
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
27
MVCC: Motivation
• Vorbetrachtung
– T1 liest x ( r1(x) c1 )
– T2 schreibt x ( w2 (x) c2 )
– T1 und T2 werden „gleichzeitig“ gestartet
– Was kann passieren?
• Komplexeres Beispiel: r1(x) w1(x) r2(x) w2(y) r1(y) w1(z) c1 c2
 nicht konfliktserialisierbar …
… aber: wenn r1(y) eine alte Version von y lesen könnte …
äquivalent zu r1(x) w1(x) r1(y) r2(x) w2(y) w1(z) c1 c2
konfliktserialisierbar!
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
28
MVCC: Idee
 Multiversionen-Synchronisation
(Multiversion Concurrency Control, MVCC)
– Prinzip: jede Änderungsoperation w erzeugt eine neue Version des
geänderten Datenbankobjekts
– Leseoperationen können nun auf passender („alter“) Version lesen
– realisiert z.B. in Oracle, PostgreSQL, MS SQL Server (seit V 2005),
IBM DB2 (seit V 9.7 2009), diversen analytischen DBMS und
verschiedenen NoSQL-DBMS
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
29
MVCC: Vorteile
• Vorteile
– MVCC führt zur Entkopplung von Lese- und Änderungsoperationen
– Eine Lesetransaktion hat eine Sicht auf die Datenbank, als ob alle Daten
am Beginn der Transaktion atomar gelesen werden
– Keine Synchronisation gegen Lesetransaktionen notwendig  Reduktion
der Konfliktwahrscheinlichkeit
• Beispiel:
T1
T2
BOT
w(x0 → x1)
w(y0 → y1)
commit
TR
BOT
r(y0)
BOT
w(x1 → x2)
commit
≡ TR T1 T2
h_da Prof. Dr. Uta Störl
r(x0)
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
30
MVCC: Realisierung
• Änderungsoperationen müssen wie bisher synchronisiert werden
• Für jede Transaktion muss die (korrekte) zu lesende Version des Objekts
bestimmt werden:
– globaler Transaktionszähler (transaction number count, TNC)
– für jede Transaktion: BOT-Zeitstempel bts (= aktueller TNC) und commitZeitstempel (dann gültiger TNC + 1)
– Schreibzeitstempel wts für jede Version eines geänderten Objekts (wird
beim commit auf commit-Zeitstempel der Transaktion gesetzt)
– Lesetransaktion TR hat Zugriff auf die jüngste Version von x für die gilt:
wts (x) < bts (TR)
also die letztgültige Version des Objektes vor Beginn der Transaktion
• Effiziente Versionenverwaltung notwendig
– z.B. Verwaltung der Versionen der Objekte in einem Ringpuffer
– garbage collection (wts(xi) < wts(xj) < bts_min  xi kann gelöscht werden)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
31
Transaktionsverwaltung und Recovery
• Transaktionsverwaltung
 Transaktionsbegriff
 Synchronisation und Sperren
 Isolation Level in SQL
 MVCC
– Hierarchische Sperren
– Isolation Level und Sperren in relationalen DBMS
• Recovery
– Fehlerklassen
– Recovery-Strategien
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
32
Hierarchisches Sperren: Motivation
Motivation
• Welche Probleme können bei sehr feingranularen Sperren und sehr
vielen gleichzeitig aktiven Transaktionen auftreten?
• Sperrgranulate in relationalen DBMS:
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
33
Hierarchisches Sperren: Prinzip
Hierarchisches Sperren (multi granularity locking, MGL)
• 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) und
– iwl (intentionale Schreibsperre)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
34
Hierarchisches Sperren: Ablauf
1. Sperren werden auf einem Pfad in der Reihenfolge von der Wurzel zum
Zielobjekt gesetzt
2. Datenobjekt, auf dem gearbeitet werden soll, wird gesperrt: Schreiboder 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 ein rl kann zum wl
werden, ein irl zum rl und ein irl zum iwl, falls keine Konflikte zu
anderen Transaktionen vorhanden sind.
5. Freigabe erfolgt in umgekehrter Reihenfolge
Kompatibilitätsmatrix
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
35
Hierarchisches Sperren: Beispiel – 1(2)
T1: Durchschnittspreis aller Produkte
T2: Update MinMenge für Produkt „New York Espresso“
1
1
= 2 explizite Sperren für T1
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Quelle: Saake/Heuer/Sattler:2005
Kapitel 6: Transaktionsverwaltung und Recovery
36
Hierarchisches Sperren: Beispiel – 2(2)
T1: Durchschnittspreis aller Produkte
T2: Update MinMenge für Produkt „New York Espresso“
1
Produkt
1
n
n
= 2n + 2 explizite Sperren für T1 (mit n = Anzahl Tupel in Relation Produkt)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Quelle: Saake/Heuer/Sattler:2005
Kapitel 6: Transaktionsverwaltung und Recovery
37
Hierarchische Sperren: (De-)Escalation
Lock Escalation
• Falls Transaktion sehr viele Sperren benötigt  dynamisches
Umschalten auf gröberes Granulat
– Beispiel: nach 1000 Satzsperren auf einer Tabelle 
1 Tabellensperre erwerben
– Schranke ist typischer Tuning-Parameter
Manchmal kann auch Lock De-Escalation sinnvoll sein
• Erwerbe grob-granulare Sperre (z.B. für Tabelle)
• vermerke referenzierte Objekte auf fein-granularer Ebene (z.B. Sätze)
• bei Konflikt(en): Umschalten auf feine Sperren
Anmerkung: In DBMS i.a. auch explizites Sperren von Tabellen durch
Benutzer / Anwendungsprogramm möglich
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
38
Transaktionsverwaltung und Recovery
• Transaktionsverwaltung
 Transaktionsbegriff
 Synchronisation und Sperren
 Isolation Level in SQL
 MVCC
 Hierarchische Sperren
– Isolation Level und Sperren in relationalen DBMS
• Recovery
– Fehlerklassen
– Recovery-Strategien
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
39
Isolation Level und Sperren in Oracle
• MVCC  Unterstützung der IL read committed und serializable
SQL
Oracle
set transaction
set transaction
[ { read only | read write } ]
[ { read only | read write } ]
[ isolation level
[ isolation level
{ read uncommitted |
{ read committed |
read committed |
repeatable read |
serializable } ]
serializable } ]
• Isolationsebenen für eine Menge von Transaktionen
alter session set isolation_level <isolation_level>
• Hierarchische Sperren
– Tabellen und Zeilen
– Für Tabellen explizites Sperren möglich (5 verschiedene Lock-Modi)
lock table <table_name> <lock_mode>
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
40
Isolation Level und Sperren in IBM DB2
• Unterstützung aller SQL-Isolationsebenen (leider mit anderen Namen)
SQL
DB2
set transaction
change isolation to
[ { read only | read write } ]
[ isolation level
{ read uncommitted |
[ { UR
Uncommitted Read
read committed |
CS
Cursor Stability
repeatable read |
RS
Read Stability
serializable } ]
RR } ]
Repeatable Read
• Seit 9.7 Standardverhalten im Isolation Level CS (Cursor Stability) MVCC:
currently committed semantics (implementiert mit Hilfe des Transaktionslogs)
– kann deaktiviert werden: update db cfg using CUR_COMMIT DISABLED
• Hierarchische Sperren
– Tabellen und Zeilen
– Für Tabellen explizites Sperren möglich (2 verschiedene Lock-Modi)
lock table <table-name > in { SHARE MODE | EXCLUSIVE MODE }
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
41
Weitere Isolationsverfahren
• Nicht-sperrende Verfahren
– Zeitstempelverfahren
– Optimistische Sperrverfahren
• Hier nicht betrachtet: Sperren in Indexstrukturen
• Alternative Konsistenzmodelle (BASE)  siehe Kapitel Verteilte
Datenbankarchitekturen
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
42
Zusammenfassung Transaktionsverwaltung
• Transaktionsbegriff
• Notwendigkeit der Synchronisation
• Serialisierbarkeitstheorie
• Sperrmodelle
• Transaktionen in SQL
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
43
Transaktionsverwaltung und Recovery
• Transaktionsverwaltung
 Transaktionsbegriff
 Synchronisation und Sperren
 Isolation Level in SQL
 MVCC
 Hierarchische Sperren
 Isolation Level und Sperren in relationalen DBMS
• Recovery
– Fehlerklassen
– Recovery-Strategien
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
44
Fehlerklassifikation
Fehlerklassifikation
1. Transaktionsfehler
2. Systemfehler
3. Externspeicherfehler
 unterschiedliche Recovery-Maßnahmen je nach Fehlerart
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
45
Transaction-Recovery: Beispiel
• Szenario:
T1
B  B‘ commit
A  A‘
T2
C  C‘
abort
Zeitachse
• Transaction-Recovery
– C‘ muss wieder auf C zurückgesetzt werden (UNDO).
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
46
Transaktionsfehler ( Transaction-Recovery)
• Typische Transaktionsfehler
– Fehler im Anwendungsprogramm
– Transaktionsabbruch explizit durch den Benutzer
– Transaktionsabbruch durch das System
• Charakteristika
– Abbruch einer einzelnen(!) Transaktion
– kein Einfluss auf den Rest des Systems  auch: lokaler Fehler
• Behandlung (Transaction-Recovery)
– „Isoliertes“ Zurücksetzen aller Änderungen der abgebrochenen
Transaktionen = lokales UNDO bzw. R1-Recovery
– Wichtig: von dieser Transaktion veränderte Blöcke können sich
sowohl im Datenbank-Puffer als auch bereits in der materialisierten
Datenbank (also auf dem Externspeicher) befinden!
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
47
Protokollierung von Änderungsinformation
• Durchgeführte Änderungen werden von den meisten DBMS in einem Log bzw.
Log-Dateien protokolliert.
• Ein Log besteht aus Einträgen der Form:
{ LSN, TA, PageID, Undo, Redo PrevLSN }
– LSN:
–
–
–
–
–
Log-Sequence Number = eindeutige und aufsteigende
Nummerierung der Log-Einträge
TA:
Transaktionskennung (Nummer)
PageID: Seitennummer
Undo:
UNDO-Information
Redo:
REDO-Information
PrevLSN: LSN des letzten Eintrags der selben Transaktion
• Außerdem wird Beginn und Ende einer Transaktion vermerkt
(BOT, commit, abort)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
48
Log-Einträge: Beispiel
LSN
TA
PageID
Undo
Redo
PrevLSN
#1
T1
BOT
#2
T1
27
#3
T2
BOT
#4
T2
40
[. C .]
[. C‘.]
#3
#5
T1
70
[. B .]
[. B‘.]
#2
#6
T1
commit
0
[. A .]
[. A‘.]
#1
0
#5
• Physische vs. logische Protokollierung
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
49
Transaction-Recovery: Beispiel (Forts.)
Transaction-Recovery
• alle Log-Einträge von T2 werden in umgekehrter Reihenfolge ihrer
ursprünglichen Ausführung gelesen und rückgängig gemacht, d.h. die UndoInformation (alter Zustand der Seite) in die Datenbank eingebracht.
LSN
TA
PageID
#1
T1
BOT
#2
T1
27
#3
T2
BOT
#4
T2
40
[. C .]
[. C‘.]
#3
#5
T1
70
[. B .]
[. B‘.]
#2
#6
T1
commit
#5
#7
T2
abort
#4
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Undo
Redo
PrevLSN
0
[. A .]
[. A‘.]
#1
0
Kapitel 6: Transaktionsverwaltung und Recovery
50
Systemfehler ( Crash Recovery)
• Typische Systemfehler
– DBMS-Fehler
– Betriebssystemfehler
– Hardware-Fehler
• Charakteristika
– die im DB-Puffer befindlichen Daten sind zerstört
– die auf dem Externspeicher befindlichen Daten (also die
„materialisierte“ Datenbank) ist jedoch unversehrt!
• Behandlung (Crash Recovery)
– Nachvollziehen der von abgeschlossenen Transaktionen nicht in die
DB eingebrachten Änderungen = partielles REDO bzw. R2-Recovery
– Zurücksetzen der von nicht beendeten Transaktionen in die DB
eingebrachten Änderungen = globales UNDO bzw. R3-Recovery
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
51
Crash-Recovery: Beispiel – 1(2)
Szenario:
Systemfehler
T1
B  B‘ commit
A  A‘
C  C‘
T2
T3
D  D‘
E  E‘ commit
Zeitachse
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
52
Crash-Recovery: Beispiel – 2(2)
Situation im Puffer bzw. der Datenbank
•
•
•
T1 (committed)
T2 (offen)
T3 (committed)
: A‘ wurde bereits zurück geschrieben; B‘ nicht(!)
: C‘ wurde bereits zurück geschrieben(!), D‘ noch nicht
: E‘ wurde bereits zurück geschrieben
DB-Puffer
Datenbank
C‘
A‘
D
...
B
h_da Prof. Dr. Uta Störl
E‘
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
53
Crash-Recovery
3 Phasen
1. Analyse
Das Log wird von Anfang bis zum Ende gelesen und ermittelt, welche
Transaktionen erfolgreich beendet (committed) wurden und welche zum
Fehlerzeitpunkt offen waren.
2. Wiederholung der Historie (REDO)
Es werden alle(!) protokollierten Änderungen in der Reihenfolge ihrer
Ausführung in die Datenbank eingebracht.
3. UNDO
Die Änderungsoperationen der zum Fehlerzeitpunkt offenen Transaktionen
werden rückgängig gemacht.
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
54
Crash-Recovery: Phase 1
Analyse
• Ermittlung aller abgeschlossenen Transaktionen (T1 und T3 ) und
offenen Transaktionen (T2)
LSN
TA
PageID
#1
T1
BOT
#2
T1
27
#3
T2
BOT
#4
T2
40
[. C .]
[. C‘.]
#3
#5
T3
44
[. E .]
[. E‘.]
0
#6
T3
commit
#7
T1
70
#8
T1
commit
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Undo
Redo
PrevLSN
0
[. A .]
[. A‘.]
#1
0
#5
[. B .]
[. B‘.]
#2
#7
Kapitel 6: Transaktionsverwaltung und Recovery
55
Crash-Recovery: Phase 2 und 3
Phase 2
Wiederholung der
Historie (REDO)
C‘
A‘
C‘
A‘
D
B
E‘
Phase 3
UNDO der offenen
Transaktionen
C
A‘
D
B‘
E‘
D
B‘
E‘
Datenbankzustand nach
dem Systemfehler
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
56
Write-Ahead-Log-Prinzip (WAL)
• Wir haben in den Beispielen vorausgesetzt, dass die für die Recovery
benötigte Information im Log steht (trotz Verlust der Hauptspeicherinformation) – ist das gewährleistet?
 Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr
gehörenden Log-Einträge ausgeschrieben werden (für das REDO im Fehlerfall).
 Bevor eine veränderte Seite in die Datenbank eingebracht wird, müssen alle
diese Seite betreffenden Log-Einträge ausgeschrieben werden (für das UNDO
im Fehlerfall).
• Diese beiden Forderungen werden als Write-Ahead-Log-Prinzip (WAL)
bezeichnet.
• Anmerkung: Natürlich werden dabei nicht einzelne Log-Einträge, sondern alle
Log-Einträg bis zum betroffenen sequentiell ausgeschrieben.
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
57
Checkpoints
• Problem: wenn auf der Datenbank viele Operationen ausgeführt
wurden, ist das im Fehlerfall zu verarbeitende Log sehr umfangreich …
 Optimierung: Schreiben von Checkpoints (Sicherungspunkte):
– Bei einem Checkpoint alle veränderten Datenbankseiten aus dem
Puffer in die Datenbank schreiben und dies im Log vermerkt:
{ #5, CKPT }
 Log muss im Fehlerfall nur ab dem letzten Checkpoint analysiert
werden.
• Checkpoint-Häufigkeit kann konfiguriert werden und ist kritisch für die
Performance des Systems
• Häufiges Schreiben von Checkpoints:
– reduziert die Zeit für eine Crash-Recovery, aber
– kann Performance im laufenden Betrieb beeinträchtigen!
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
58
Checkpoints in Oracle – 1(2)
• Parameter zur Beeinflussung der REDO-Dauer:
• FAST_START_MTTR_TARGET
spezifiziert Erwartungswert für mittlere Recovery-Zeit (mean time to
recover)
• früher andere Parameter (inzwischen deprecated):
– FAST_START_IO_TARGET
spezifiziert maximale Anzahl DB-Seiten (Obergrenze) die im
Recovery-Fall angewendet werden müssen oder
– LOG_CHECKPOINT_TIMEOUT
Zeitabstand in s zwischen aktuellem Log-Ende und letztem
Checkpoint oder
– LOG_CHECKPOINT_INTERVAL
max. Anzahl von Log-Einträgen seit letztem Checkpoint
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
59
Checkpoints in Oracle – 2(2)
• Messergebnisse
– OLTP (Online Transaction Processing), d.h. viele parallele, relativ
kurze Transaktionen
– 200.000 Puffer-Seiten a 4 Kb
FAST_START_IO_TARGET
Durchsatz
(Transaktionen pro Minute)
Crash-Recovery-Zeit
disabled
805
4 min 34 s
30.000
804
1 min 20 s
20.000
798
1 min 10 s
10.000
798
49 s
1.000
797
21 s
 Einstellung der Parameter muss anwendungsspezifisch (abhängig von
Transaktionsprofil und Anforderungen an Recovery) gewählt werden.
Quelle: T. Lahiri et al.: Fast-Start: Quick Fault Recovery in Oracle. Proc. ACM SIGMOD Conf., May 2001
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
60
Externspeicherfehler ( Media-Recovery)
• Typische Externspeicherfehler
– Hardware-Fehler: „Head-Crashes“, Controller-Fehler etc.
– Naturgewalten wie Feuer oder Erdbeben
– Viren
• Charakteristika
– Die Daten der materialisierten Datenbank sind zerstört oder
unbrauchbar
• Behandlung (Media-Recovery)
– Die Datenbank muss mit Hilfe einer Sicherungskopie (Backup)
wiederhergestellt werden.
– Danach muss der letzte transaktionskonsistente Zustand
wiederhergestellt werden, d.h. es alle seit der Erstellung des Backup
erfolgreich beendeten Transaktionen nachvollzogen werden.
 Konsequenz: Die Log-Dateien müssen auf einem anderen Medium
gesichert werden (z.B. anderer Rechner, Magnetband o.ä.)!
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
61
Media-Recovery
• Wichtige Unterscheidung: In welchem Zustand ist die Datenbank bei der
Sicherung?
• Variante 1: Es sind keine Transaktionen auf der Datenbank während der
Sicherung aktiv = Offline-Backup (consistent backup)
– Vorteil: Datenbankkopie ist in transaktionskonsistentem Zustand!
– Nachteil: Während der Sicherung darf keine (Schreib-)Transaktion auf der
Datenbank aktiv sein! (vielfach nicht akzeptabel, z.B. 24h Betrieb im
Internet bzw. bei weltweit agierenden Unternehmen)
• Variante 2: Es können Transaktionen auf der Datenbank während der
Sicherung aktiv sein = Online-Backup (inconsistent backup)
– Vorteil: Datenbankbetrieb wird nicht (oder kaum) beeinträchtigt
– Nachteil: Datenbankkopie ist nicht in transaktionskonsistentem Zustand –
Wiederherstellung (Recovery) aufwändiger
• Kommerzielle DBMS unterstützen heute meist(!) beide Varianten.
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
62
Media-Recovery: Grundprinzip – 1(2)
• Gesicherte Daten (Offline-Backup):
OfflineBackup x-1
Log-Datei n-4
Log-Datei n-3
OfflineBackup x
Log-Datei n-2
Log-Datei n-1
Log-Datei n
• Media-Recovery
– Letzte Sicherungskopie der Datenbank wird eingespielt
– Nach der letzten Sicherung erstellte Log-Dateien werden analysiert und
die Änderungen erfolgreich beendeter Transaktionen nachvollzogen
(REDO)
(Bemerkung: aus Performance-Gründen kann auch eine Vorgehensweise
analog zur Crash-Recovery gewählt werden: komplette Historie
wiederholen und danach Undo der Änderungen offener Transaktionen.)
OfflineBackup x
Log-Datei n-2
Log-Datei n-1
Zeit
Log-Datei n
Zeit
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
63
Media-Recovery: Grundprinzip – 2(2)
• Gesicherte Daten (Online-Backup):
OnlineBackup x-1
Log-Datei n-4
Log-Datei n-3
OnlineBackup x
Log-Datei n-2
Log-Datei n-1
Log-Datei n
• Media-Recovery
– Letzte Sicherungskopie der Datenbank wird eingespielt
– Es müssen auch Log-Dateien vor dem letzten Backup betrachtet werden,
da die Sicherungskopie u.U. Änderungen von später nicht erfolgreich
beendeten Transaktionen enthält. Die Undo-Information dieser
Transaktionen wird benötigt.
 Recovery zeitaufwändiger und Administration (Aufbewahren der LogDateien) aufwändiger
Log-Datei n-4
Log-Datei n-3
OnlineBackup x
Log-Datei n-2
Log-Datei n-1
Zeit
Log-Datei n
Zeit
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
64
Inkrementelles Backup
• Bei großen Datenbanken ist eine Komplettsicherung sehr(!) zeitaufwändig
 Sicherung der veränderten Datenbankseiten = inkrementelles Backup
• Bei der Wiederherstellung wird
– das letzte Full Backup und alle danach erstellten inkrementellen Backups
eingespielt und danach
– nur die Log-Dateien (Annahme: offline Backup) nach dem letzten
inkrementellen Backup angewandt:
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
65
Weitere Backup-Varianten
Die bereits aufgeführten Backup-Varianten
• Online vs. Offline Backup
• Komplettes Backup vs. inkrementelles Backup
können orthogonal mit weiteren Backup-Varianten kombiniert werden:
• Partielles Backup (Backup von Teilen der Datenbank z.B. Tablespaces)
• Paralleles Backup
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
66
Point-In-Time-Recovery
Szenario: Bestimmte Datensätze wurden versehentlich durch einen
Anwender oder Administrator gelöscht (und die Transaktion
committed!).
• Wie kann dieses Löschen (oder falsches Verändern o.ä.) rückgängig
gemacht werden?
– Ansatz 1: Undo-Information der entsprechenden Transaktion
anwenden. Probleme?
– Ansatz 2: Wiederherstellung der Datenbank bis zu einem
definierten Zeitpunkt vor dem Fehler („Simulation“ eines
Systemfehlers zu diesem Zeitpunkt) = Point-In-Time-Recovery
Probleme?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
67
Backup und Recovery
• Backup- und Recovery-Kommandos in Datenbanksystemen sind nicht
standardisiert.
• Es gibt eine Vielzahl von Parameter (Ausgabekanäle, Parameter für
Größe von Log-Dateien und Häufigkeit der Sicherung, CheckpointParameter etc.)
• Die Wahl dieser Parameter und der Sicherungsstrategie hat
erhebliche(!) Auswirkungen sowohl auf die Performance im laufenden
Betrieb als auch auf die Wiederherstellungszeit im Fehlerfall.
• Wichtig: Spiegelung bzw. RAID-Systeme sind kein ausreichender Ersatz
für regelmäßige Backups! Warum?
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
68
Backup und Recovery in Oracle
Log-Dateien (Oracle: Redo-Log-Dateien)
• mehrere Redo-Log-Gruppen die zirkular beschrieben werden
– Parameter MAXLOGFILES (Anzahl Gruppen) und MAXLOGMEMBERS
(Anzahl Log-Dateien pro Gruppe)
• Archivierung möglich (notwendig für Media Recovery)
• Wiederverwendung (überschreiben), sobald die Inhalte nicht mehr für Crash
Recovery gebraucht werden und sobald Log-Datei archiviert
Backup
• komplett und inkrementell (full vs. incremental)
• offline und online (consistent vs. inconsistent)
• partielles Backup (einzelner Tablespace oder einzelne Datei)
Recovery
• komplette oder partielle Recovery (analog zum Backup)
• Point-In-Time-Recovery (incomplete recovery) für ganze Datenbank oder
einzelnen Tablespace
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
69
Backup und Recovery in IBM DB2
Log-Dateien
• Log-Dateien werden entweder zirkular überschrieben oder sequentiell erzeugt
und gefüllt: logarchmeth1 = off [logretain]
– Parameter zum Archivieren der Log-Dateien:
userexit, disk, tsm, vendor
Backup
• komplett und inkrementell
• offline und online
• partielles Backup (Tablespace)
Recovery
• Wiedereinspielen eines Backup (restore)
• Anwenden der Log-Dateien (rollforward) bis zu einem bestimmten Zeitpunkt
( Point-In-Time-Recovery) oder bis zum Ende
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
70
Zusammenfassung Recovery
• Fehlerklassen
• Recovery-Strategien
• Protokollierung und Sicherungspunkte (Checkpoints)
• Backup-Varianten
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
71
Architektur von Datenbanksystemen
 Architektur von Datenbanksystemen
 Verwaltung des Hintergrundspeichers
 Dateiorganisation und Zugriffsstrukturen
 Basisalgorithmen für Datenbank-Operationen
 Anfrageoptimierung
 Transaktionsverwaltung und Recovery
• Verteilte Datenbankarchitekturen
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 6: Transaktionsverwaltung und Recovery
72