3.4 Transaktionen 3.4 Transaktionen 3.4.1 Anforderungen 3.4.1

3.4 Transaktionen
3.4.1 Anforderungen
Definition
Themen in diesem Abschnitt
Eine Transaktion ist eine logische Einheit von
Datenbankoperationen, die einen konsistenten
Zustand in einen konsistenten Zustand überführt.
• Probleme bei der Transaktionsverarbeitung
I
Error Recovery
Fehlerbehandlung schon beim Einbenutzerbetrieb wichtig
I
Concurrency Control
Nebenläufigkeit von Transaktionen mehrere Benutzer
I
Backup/Restore
Online Backup bei laufenden Transaktionen
Bemerkungen
• in SQL wird eine Transaktion begonnen mit
begin [work|transaction] und beendet mit
commit oder rollback
• Anforderungen an Transaktionsverarbeitung
• Transaktionsbegriff unabhängig vom Datenmodell
I
(relational, hierarchisch, objektorientiert, ...)
I
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -1-
University of Applied Sciences
Atomicity, Consitency, Isolation, Durability (ACID)
Isolationsgrad (Transaction Isolation Level)
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4 Transaktionen
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -3-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.1 Anforderungen
Einfaches Modell einer Datenbank
Error Recovery
• Sammlung benannter Datenobjekte
I
I
Banküberweisung
Betrag y
alle folgenden Betrachtungen sind unabhängig von der
Größe eines Datenobjekts (Granularität)
Granularität kann z.B. Feld, Tupel, Plattenblock sein
inkonsistenter
Zustand
• zwei grundlegende Operationen
I read(X) liest Objekt X der Datenbank in Programmvariable
I write(X) schreibt Wert Programmvariable in Objekt X
Zeit
x1 :
x2 :
Stand Konto 1
Stand Konto 2
read ( x2 )
x2 := x2 + y
write ( x2 )
• Wie kann auf logischen Fehler innerhalb Transaktion reagiert
Bemerkung
werden? Nötig: Möglichkeit zum Rollback
• ein SQL-Kommando beinhaltet i.allg. mehrere grundlegende
• Was ist bei Systemabsturz im inkonsistenten Zustand?
Operationen
• Beispiel: update produkt set preis=preis+1 where pnr=’P1’;
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -2-
read ( x1 )
x1 := x1 − y
write ( x1 )
University of Applied Sciences
• Was ist bei Systemabsturz nach Beendigung Transaktion?
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -4-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.1 Anforderungen
3.4.1 Anforderungen
Concurrency Control (1)
Concurrency Control (3)
Transaktion T1
Zeit
Transaktion T2
Transaktion T1
read ( x1 )
x1 := x1 − y
write ( x1 )
Zeit
read ( x1 )
read ( x1 )
x1 := x1 − y
write ( x1)
read (x1)
x1 := x1 − z
write ( x1 )
read ( x2 )
Abbruch wg. Fehler
• T2 liest Daten, die nie committed werden (dirty data)
• Update von T1 geht verloren (Lost Update)
⇒ Überweisung T2 führt zu falschem Kontostand
⇒ falscher Kontostand nach Abschluss beider Transaktionen
• Phänomen wird als Dirty Read bezeichnet
• tritt in Tateinheit mit Nonrepeatable Read auf (Warum?)
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -5-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -7-
3.4.1 Anforderungen
3.4.1 Anforderungen
Concurrency Control (2)
Concurrency Control (4)
Transaktion T1
Zeit
Transaktion T2
Transaktion T1
Transaktion T2
Zeit
read ( x1 )
read ( x1 )
x1 := x1 − y
write ( x1 )
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Transaktion T2
select from
produkt
insert into
produkt
read (x1)
select from
produkt
• T2 liest mehrmals hintereinander verschiedene Werte
• T1 sieht beim zweiten Select zusätzliche Tupel
desselben Datensatzes, ohne ihn zu verändert zu haben
die beim ersten Select nicht da waren (Phantomtupel)
• Phänomen wird als Nonrepeatable Read bezeichnet
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -6-
University of Applied Sciences
• Unterschied zum Nonrepeatable Read: alle Daten unverändert
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -8-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.1 Anforderungen
3.4.1 Anforderungen
Backup/Recovery
Gelegentlich macht man Abstriche bzgl. Isolation
• vollständige Isolation (Serialisierbarkeit) verringert
T3
Durchsatz nebenläufiger Transaktionen
T2
• für manche Transaktionen (z.B. nur lesendes Backup)
T1
Zeit
T4
Start Backup
keine vollständige Isolation erforderlich
Ende Backup
SQL2 definiert vier Isolationsgrade
• Offline Backup unproblematisch: alle Transaktionen beendet
• read uncommited, read committed, repeatable read, serializable
• nur serializable garantiert tatsächliche Transaktionsisolation
• Online Backup problematisch: Backup muss konsistente
Momentaufnahme (Snapshot) der Datenbank sichern
⇒ Backupoperation muss selber Transaktion sein, in der
kein Nonrepeatable Read und keine Phantomtupel auftreten
• nicht alle DBS implementieren alle Isolationsgrade
(PostgreSQL: read committed, serializable)
• kann gesetzt werden nach Transaktionsbeginn mit
set transaction isolation level <isolationsgrad>;
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -9-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.1 Anforderungen
Elektrotechnik
und Informatik
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -11-
Faculty of Electrical Engineering
and Computer Science
3.4.1 Anforderungen
Wünschenswerte ACID-Eigenschaften
Wie die Isolationsgrade die Isolation verletzen:
• Atomicity
Isolationsgrad
Transaktion wird entweder ganz oder gar nicht ausgeführt
READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE
• Consistency
Transaktion überführt konsistenten Zustand in konsistenten
Zustand. Innerhalb Transaktion Inkonsistenz möglich.
Nonrepeatable Read
Phantomtupel
J
N
N
N
J
J
N
N
J
J
J
N
Bemerkung:
• Isolation
Änderungen in einer Transaktion sind bis zum Abschluss
unsichtbar für andere Transaktionen.
• DBS, das Levels ungleich serializable unterstützt, muss
zusätzliche Kontrollmechanismen anbieten
• solche Mechanismen sind aber nicht in SQL2 spezifiziert
• Durability
• typischerweise sind das die zwei Befehle
Nach Abschluss Transaktion bleiben Änderungen bestehen,
auch im Fall eines folgenden Systemabsturzes
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -10-
Dirty Read
University of Applied Sciences
LOCK TABLE
SELECT FOR UPDATE
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -12-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
3.4.2 Serialisierbarkeit
Ziel:
ideale Isolation bei serieller Ausführung:
jede Transaktion hat Datenbank für sich alleine
Isolation von Transaktionen, d.h. Transaktionen
sollen nichts voneinander merken
serielle Ausführungspläne
Zeit
Fragestellungen:
• Wie können wir Isolation formal definieren?
(Begriffe Ausführungsplan, Serialisierbarkeit)
r T2 ( x1 )
w T2 ( x1 )
r T1 ( x1 )
w T1 ( x1 )
r T1 ( x1 )
w T1 ( x1 )
r T2 ( x1 )
w T2 ( x1 )
Nachteil:
• Wie können wir fehlende Isolation erkennen?
(Algorithmus auf Basis unserer Definition)
• Transaktionen müssen aufeinander warten
⇒ keine Nebenläufigkeit
⇒ geringer Durchsatz an Transaktionen
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -13-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Zeit
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Ausführungsplan (Schedule)
= zeitliche Abfolge elementarer Operationen
Transaktion T1
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -15-
Transaktion T2
read ( x1 )
read ( x1 )
write ( x1 )
write ( x1 )
Serielle Ausführung eigentlich nicht nötig
• es muss für jede Transaktion nur so aussehen
Ausführungsplan
als wäre sie isoliert
• dazu reicht Existenz eines äquivalenten seriellen
r T2 ( x1 )
r T1 ( x1 )
w T1 ( x1 )
w T2 ( x1 )
Ausführungsplans
Solcher Ausführungsplan heißt serialisierbar.
Bemerkungen
Bemerkung:
• Annahme: elementare Operationen können nicht
• Serialisierbarkeit ist abhängig von Definition der Äquivalenz“
von Ausführungsplänen (siehe weiter unten)
gleichzeitig durchgeführt werden
• verschiedene Definitionen der Schedule-Äquivalenz möglich.
• irreführende Bezeichnung plan“: nicht DBS bestimmt
”
Schedule, sondern Clientanwendungen bzw. Anwender
M.a.W. am Ausführungsplan“ ist nichts geplant“!
”
”
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -14-
University of Applied Sciences
”
Anschaulich: Schedules haben dieselben Auswirkungen in DB
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -16-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
3.4.2 Serialisierbarkeit
Beispiel für (nicht) serialisierbaren Schedule:
Transaktion T1
Transaktion T2
read ( x1 )
Zeit
read ( x1 )
x1 := x1 − 500
write ( x1 )
Konfliktäquivalenz (2)
Transaktion T1
Transaktion T2
read ( x1 )
x1 := x1 − 500
write ( x1 )
Beispiel:
read ( x2 )
x1 := x1 * 1.02
write ( x1 )
read ( x2 )
x2 := x2 + 500
write ( x2 )
nicht serialisierbar
Zwei Schedules heißen konfliktäquivalent, wenn die Reihenfolge
in Konflikt stehender Operationen in beiden Schedules gleich ist.
read ( x1 )
x2 := x2 + 500
write ( x2 )
x1 := x1 * 1.02
write ( x1 )
serialisierbar
Schedule 1 r T1 ( x1 )
r T1 ( x2 )
r T2 ( x1 )
Konflikt−
Operatio−
w T2 ( x1 )
nen
w T1 ( x1 )
w T1 ( x2 )
Schedule 2 r T2 ( x1 )
r T1 ( x1 )
r T1 ( x2 )
w T2 ( x1 )
w T1 ( x1 )
w T1 ( x2 )
Schedule 3 r T1 ( x1 )
r T1 ( x2 )
r T2 ( x1 )
w T1 ( x1 )
w T2 ( x1 )
w T1 ( x2 )
• Schedule 1 und 2 sind konfliktäquivalent
• Schedule 1 und 3 (und auch 2 und 3) nicht
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -17-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -19-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Konfliktäquivalenz (1)
Anwendung Konfliktäquivalenz auf Serialisierbarkeit:
Schedule ist (konflikt-) serialisierbar, wenn er ohne
Vertauschung von Konflikt-Operationen in einen
seriellen Schedule umgeformt werden kann.
• suche hinreichendes Kriterium für Äquivalenz
von Ausführungsplänen
• Frage: welche Operationen dürfen gefahrlos, d.h. ohne
Beispiel
Auswirkung auf Endergebnis vertauscht werden?
I
Operationen auf verschiedenen Objekten immer vertauschbar
I
zwei read-Operationen desselben Objekts auch vertauschbar
I
ist bei zwei Operationen auf demselben Objekt eine
write-Operation dabei, so kann Vertauschung das Endergebnis
verändern (Beispiel: obiger nicht serialisierbarer Schedule)
Solche Operationen stehen im Konflikt zueinander
Vertauschen
zulässig
r T1 ( x1 )
r T1 ( x2 )
r T2 ( x1 )
w T2 ( x1 )
w T1 ( x1 )
w T1 ( x2 )
Vertauschen
unzulässig
Übung:
Kriterium überprüfen an vorhergehenden Schedules
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -18-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -20-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
3.4.2 Serialisierbarkeit
Prüfung auf Serialisierbarkeit
Beispiel mit drei Transaktionen:
• bei zwei nebenläufigen Transaktionen können wir leicht
auf Konfliktäquivalenz mit den zwei möglichen seriellen
Ausführungsplänen prüfen
Transaktion 1 Transaktion 2
• Was ist aber bei n nebenläufigen Transaktionen?
read ( x )
write ( x )
n! mögliche serielle Schedules ⇒ Durchprobieren ineffizient
Frage:
T1
x,y
write ( y )
write ( z )
T2
read ( z )
read ( y )
write ( y )
• Können wir einfacher auf Serialisierbarkeit prüfen?
Transaktion 3
read ( y )
read ( z )
read ( y )
write ( y )
read ( x )
write ( x )
Antwort:
y
y,z
T3
• Ja! Suche nach Zyklen im Präzedenzgraphen“.
”
Elektrotechnik
und Informatik
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -21-
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
University of Applied Sciences
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Anschauliche Bedeutung Präzedenzgraph
Präzedenzgraph (precedence graph)
• Konfliktoperationen dürfen nicht vertauscht werden
• Idee:
I stelle Reihenfolge der Konfliktoperationen durch Kanten
in gerichtetem Graphen dar
⇒ Kante Ti → Tj bedeutet, dass Transaktion Ti im
äquivalenten seriellen Ausführungsplan vor Tj kommen muss
• Graph gibt also Präzedenz (Rangfolge) der Transaktionen
• Konstruktion:
I jede Transaktion ist ein Knoten
I für jeden Konflikt zwischen zwei Transaktionen wird eine
Kante zwischen den Transaktionsknoten gezeichnet.
Die Kante geht von der früheren zur späteren Operation
Transaktion T1
Elektrotechnik
und Informatik
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -23-
im äquivalenten seriellen Schedule an
Präzedenzgraph
Transaktion T2
äquivalente serielle
Ausführungspläne
T1
T2
T3
T3
T1
T2
T1
T2
T3
T3
T3
T1
T2
T2
T1
read ( x )
read ( x )
T1
T2
write ( x )
write ( y )
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -22-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -24-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
3.4.2 Serialisierbarkeit
Frage:
Probleme bei Anwendung Serialisierbarkeitstest:
• Wann kann Reihenfolge nicht angegeben werden?
• Transkationen beginnen und enden permanent
⇒ Wo beginnt und endet Ausführungsplan?
Antwort:
• Was, wenn Schedule nicht serialisierbar?
• Wenn Präzedenzgraph Zyklen hat
⇒ Rollback aller beteiligten Transaktionen
T1
T2
T3
Bessere Ansätze für die Praxis:
Präzedenzgraph mit Zyklus
• lasse nur serialisierbare Schedules zu
einzelne Operation müssen dann ggf. warten
Theorem
• treten Konflikte auf, dann setze nur wenige der beteiligten
Ein Ausführungsplan ist (konflikt-) serialisierbar
⇐⇒ Sein Präzedenzgraph hat keine Zyklen
Transaktionen zurück
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -25-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.2 Serialisierbarkeit
Zeit
Transaktion T2
read ( x1 )
read ( x1 )
x1 := x1 − 500
write ( x1 )
read ( x2 )
x2 := x2 + 500
write ( x2 )
Transaktion T1
Transaktion T2
Faculty of Electrical Engineering
and Computer Science
• pessimistische Verfahren
I
read ( x1 )
x1 := x1 − 500
write ( x1 )
I
I
verhindern von vorneherein nichtserialisierbare Schedules
Beispiel: Zwei-Phasen Sperrprotokoll
Nachteile:
- Transaktionen müssen warten ⇒ geringere Parallelität
- Möglichkeit von Deadlocks (gegenseitiges Warten aufeinander)
read ( x1 )
x2 := x2 + 500
write ( x2 )
• optimistische Verfahren
x1 := x1 * 1.02
write ( x1 )
I
I
I
• Wie sehen die Präzedenzgraphen aus?
Hochschule Niederrhein
University of Applied Sciences
lassen zunächst beliebige Schedules zu, beim Auftreten
von Konflikten wird eine Transaktion zurückgesetzt
Beispiel: Multi Version Concurrency Control (MVCC)
Nachteil:
- bei Abbruch wegen Konflikt muss ganze Transaktion
wiederholt werden
• Was sagt unser Theorem über Serialisierbarkeit?
Dalitz: Datenbanksysteme Kap3.4. -26-
Elektrotechnik
und Informatik
Klassifikation Verfahren zur Transaktionsisolation:
read ( x2 )
x1 := x1 * 1.02
write ( x1 )
University of Applied Sciences
3.4.2 Serialisierbarkeit
Anwendung auf vorheriges Beispiel
Transaktion T1
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -27-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -28-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
3.4.3 Sperrverfahren
Binäre Sperren
Beispiel b)
• jedes Objekt hat zwei mögliche Zustände: gesperrt, ungesperrt
• zwei weitere elementare Operationen
I lock(X) setzt Zustand von Objekt X auf gesperrt
I unlock(X) setzt Zustand von Objekt X auf ungesperrt
Locking bewirkt nicht immer Serialisierbarkeit
Transaktion T1
Transaktion T2
read ( x1 )
Zeit
read ( x1 )
x1 := x1 − 500
write ( x1 )
• vor jedem Zugriff auf Objekt X muss lock(X) erfolgen
x1 := x1 * 1.02
write ( x1 )
• in Transaktion muss auf lock(X) irgendwann unlock(X) folgen
read ( x1 )
x1 := x1 + 300
write ( x1 )
Was macht lock(X), wenn X schon gesperrt ist?
Transaktion T1
lock ( x1 )
read ( x1 )
lock ( x1 )
x1 := x1 − 500
write ( x1 )
unlock ( x1 )
lock ( x1 )
read ( x1 )
x1 := x1 + 300
write ( x1 )
unlock ( x1 )
• lock wartet bis X wieder freigegeben ist
• Transaktionen die auf Freigabe von X warten,
Transaktion T2
read ( x1 )
x1 := x1 * 1.02
write ( x1 )
unlock ( x1 )
werden in eine Warteschlange eingereiht
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -29-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
Beispiel a)
Zwei-Phasen Sperrprotokoll (Two-Phase Locking, 2PL)
nicht serialisierbarer Schedule wird
durch binären Sperrmechanismus serialisierbar
Transaktion T1
Zeit
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -31-
read ( x1 )
Transaktion T2
read ( x1 )
x1 := x1 − 500
write ( x1 )
x1 := x1 * 1.02
write ( x1 )
read ( x2 )
x2 := x2 + 500
write ( x2 )
ohne Locking:
nicht serialisierbar
• jede Transaktion führt alle lock’s vor allen unlock’s aus.
M.a.W. nach dem ersten unlock darf kein lock mehr folgen
Transaktion T1
Transaktion T2
• Was sind die zwei Phasen”?
”
lock ( x1 )
read ( x1 )
I
lock ( x1 )
x1 := x1 − 500
write ( x1 )
unlock ( x1 )
I
Phase 1: Anforderung von Sperren
Phase 2: Freigabe von Sperren
wartet
read ( x1 )
x1 := x1 * 1.02
write ( x1 )
unlock ( x1 )
Sperren
Gesperrte Objekte
in einer Transaktion
mit Locking:
serialisierbar
Phase 1 Phase 2
Zeit
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -30-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -32-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
3.4.3 Sperrverfahren
Theorem
Beweis des 2PL Theorems
• konstruiere äquivalenten seriellen Schedule zu gegebenem
Wenn sich jede Transaktion an das 2PL hält, ist
der resultierende Schedule konfliktserialisierbar.
Schedule, der sich an 2PL hält
• im seriellen Schedule treten die Transaktionen in der
Anmerkung
Reihenfolge ihrer ersten Unlockoperation auf
• Umkehrung gilt nicht, d.h. es gibt konfliktserialisierbare
T3
Schedules, die sich nicht an das 2PL halten (siehe Beispiel a)
= erstes Unlock
T2
T1
• Sperren in Beispiel b) führen nicht zu serialisierbarem Schedule
⇒ 2PL muss irgendwo verletzt werden (Warum?)
resultierende Schedule serialisierbar sein
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -33-
Zeit
x1 := x1 − 500
write ( x1 )
unlock ( x1 )
lock ( x1 )
read ( x1 )
x1 := x1 + 300
write ( x1 )
unlock ( x1 )
Transaktion T2
lock ( x1 )
read ( x1 )
x1 := x1 * 1.02
write ( x1 )
unlock ( x1 )
Faculty of Electrical Engineering
and Computer Science
T2
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -35-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
Transaktion T1
Transaktion T2
lock ( x1 )
read ( x1 )
lock ( x1 )
x1 := x1 − 500
write ( x1 )
(x1 ist schon gesperrt)
read ( x1 )
x1 := x1 + 300
write ( x1 )
unlock ( x1 )
read ( x1 )
x1 := x1 * 1.02
write ( x1 )
unlock ( x1 )
Nachteil binärer Sperren
• auch die konfliktfreien read/read Operationen sperren einander
Lösung: mehrere Sperrmodi
• read lock, shared lock
lässt zu dass andere Transaktionen auch lesen (d.h. ebenfalls
read lock anfordern), aber nicht schreiben
• write lock, exclusive lock
lässt keine Zugriffe anderer Transaktionen zu
• führt zu drei Objektzuständen und damit zu drei elementaren
Sperr-Operationen: slock, xlock, unlock
Kompatibilitätsmatrix
der Sperroperationen
• links: T1 verletzt 2PL (Wo?)
• rechts: Schedule wird serialisierbar durch 2PL
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -34-
T3
• Beweis durch vollst. Induktion über Anzahl Transaktionen:
Elektrotechnik
und Informatik
3.4.3 Sperrverfahren
lock ( x1 )
read ( x1 )
T1
Garcia-Molina, Ullman, Widom: Database Systems - The
Complete Book. Prentice Hall (2002), Abschnitt 18.3.4
• Wenn Beispiel b) auf 2PL umgestellt wird, müsste der
Transaktion T1
äquivalenter serieller Schedule:
Zeit
Anwendung Theorem auf Beispiel b)
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
angeforderte
gehal−
Sperre
tene Sperre
S
X
S
Ja
Nein
X
Nein
Nein
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -36-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
3.4.3 Sperrverfahren
Beispiel für Erhöhung Nebenläufigkeit durch mehrere Lockmodi:
Transaktion T1
Zeit
Transaktion T2
xlock ( x2 )
write ( x2 )
unlock ( x1 )
unlock ( x2 )
Transaktion T1
lock ( x1 )
read ( x1 )
slock ( x1 )
read ( x1 )
slock ( x1 )
read ( x1 )
xlock ( x3 )
write ( x3 )
Transaktion T2
wartet
read ( x1 )
lock ( x3 )
write ( x3 )
unlock ( x1 )
unlock ( x3 )
unlock ( x1 )
unlock ( x3 )
binäre Sperren
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -37-
Faculty of Electrical Engineering
and Computer Science
Zeit
read ( x1 )
write ( x1 )
read ( x2 )
read ( x2 )
write ( x2 )
read ( x1 )
• verhindernde Protokolle
I Abbruch oder Neustart von Transaktionen, wenn ein lock()
zu Verklemmung führen wird
I Nachteil: brechen oft Transaktionen ab, die nie zu
Verklemmung geführt hätten
Hochschule Niederrhein
University of Applied Sciences
Dalitz: Datenbanksysteme Kap3.4. -39-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
Grundsätzliches Problem bei Sperrverfahren:
Transaktion T2
• Timeouts
I definiere obere Grenze für Wartezeit; wenn überschritten,
wird Transaktion abgebrochen
I einfach zu realisieren ⇒ in vielen DBS’en implementiert
Elektrotechnik
und Informatik
3.4.3 Sperrverfahren
Transaktion T1
• Deadlock Erkennung
I Suche nach Zyklen im Wartegraphen (⇒ Deadlock)
I Setze eine am Deadlock beteiligte Transaktion zurück
lock ( x1 )
lock ( x2 )
write ( x2 )
unlock ( x1 )
unlock ( x2 )
mehrere Sperrmodi
Ansätze zur Deadlockbehandlung
Der Wartegraph (wait-for graph)
Transaktion T1
lock ( x1)
read ( x1 )
write ( x1 )
lock ( x2 )
write ( x2 )
Transaktion T2
• gerichteter Graph mit Transaktionen als Knoten
• Kante Ti → Tj bedeutet, dass Transaktion Ti versucht Objekt
lock ( x2 )
read ( x2 )
zu sperren, das schon von Transaktion Tj gesperrt ist
write ( x2 )
lock ( x1)
write ( x1 )
Transaktion T1 Transaktion T2
lock ( x )
read ( x )
lock ( x )
T1
T2
Zeitpunkt
Frage:
• Transaktionen blockieren sich gegenseitig:
jede wartet auf Freigabe einer Sperre der anderen Transaktion
• Phänomen heißt Deadlock (Verklemmung)
• Woran erkennt man Deadlock?
Antwort:
• Zyklus im Wartegraphen.
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -38-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -40-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
3.4.3 Sperrverfahren
Beispiel mit drei Transaktionen:
Protokolle zur Deadlock-Vermeidung
T1
Transaktion 1 Transaktion 2
lock ( x )
• für Beispiele siehe Elmasri, Navathe: Kap. 20.1.3
und Literaturhinweise am Ende Kap. 20
T3
lock ( y )
lock ( y )
T2
Transaktion 3
Graph 1
lock ( z )
T1
T2
lock ( y ) Graph 1
• ein einfaches Protokoll ist z.B. Cautious Waiting“:
”
I lock(x) darf nur warten, wenn x nicht von einer selber
wartenden Transaktion gesperrt ist
I andernfalls wirft lock(x) einen Fehler
lock ( z )
T3
Graph 2
Graph 2
• Zyklus in Wartegraph 2 zeigt Verklemmung
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -41-
University of Applied Sciences
• werden in der Praxis selten eingesetzt
I z.B. führt Cautious Waiting“ auch zu Abbrüchen
”
in Nicht-Verklemmungssituationen
⇒ ggf. Schaden größer als Nutzen
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.3 Sperrverfahren
University of Applied Sciences
Faculty of Electrical Engineering
and Computer Science
3.4.4 MVCC
Probleme bei der Deadlockerkennung:
Multi Version Concurrency Control
• Opferauswahl
I welche Transaktion soll abgebrochen werden?
I wünschenswert:
• Idee:
I write(x) überschreibt nicht, sondern erzeugt neue Version von x
I Transaktion arbeitet mit Snapshot der committed Daten
zu geeignetem Zeitpunkt (z.B. erstes DML-Statement)
- wenig fortgeschrittene Transaktionen bevorzugt abbrechen
- Opferauswahl sollte nicht unfair sein
(mehrmals dieselbe Transaktion treffen)
• Wann prüfen?
I naheliegender Ansatz (z.B. in PostgreSQL realisiert):
starte Algorithmus wenn eine Transaktion bestimmte Zeit wartet
• Vorteil:
I höhere Parallelität von Transaktionen
Transaktion T1
Zeit
Primitive Alternative: Timeouts
• schlägt auch zu, wenn kein Deadlock vorhanden
Hochschule Niederrhein
University of Applied Sciences
write ( x1 )
read ( x2 )
write ( x2 )
• setze Transaktion zurück, die länger als Timeout wartet
Dalitz: Datenbanksysteme Kap3.4. -42-
Elektrotechnik
und Informatik
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -43-
Transaktion T2
read ( x1 )
xlock ( x1 )
write ( x1 )
write ( x3 )
slock ( x2 )
read ( x2 )
parallel bei MVCC
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Transaktion T1
Transaktion T2
slock ( x1 )
wartet
nicht parallel bei Sperren
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -44-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.4 MVCC
3.4.4 MVCC
Speichern mehrerer Objektversionen:
Was passiert bei nicht serialisierbarem Schedule?
• Transaktionen bekommen fortlaufende ID (Zeitstempel)
• jede Objektversion bekommt zwei Zeitstempel:
I read ts: Zeitstempel der letzten lesenden Transaktion
I write ts: Zeitstempel der letzten schreibenden Transaktion
Transaktion id1
Zeit
Transaktion id2
Version write_ts read_ts
read ( x )
read ( x )
• beim Lesen Objektversion wird read ts entsprechend angepasst
Versionen von x
1 id0 id1
1 id0 id2
• Daten der Objektversionen werden nie verändert;
write ( x )
statt dessen wird eine neue Version des Objekts mit
read ts = write ts angelegt
write ( x )
1 id0 id2
2 id2 id2
Abbruch, da in Version 1
(Snapshot−Version)
read_ts > id1
Bemerkung:
• je nach MVCC Verfahren werden ggf. auch andere Zeitstempel
problematische Transaktionen werden automatisch abgebrochen
bei den einzelnen Objektversionen protokolliert
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -45-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.4 MVCC
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -47-
University of Applied Sciences
Faculty of Electrical Engineering
and Computer Science
3.4.5 Concurrency in SQL
Regeln für Serialisierbarkeit:
PostgreSQL und Oracle unterstützen die
Isolationsgrade read committed und serializable
• read(x) von Transaktion mit ID trans ts
I liefert Version von x mit maximalem write ts ≤ trans ts
I read ts der Version wird auf max{trans ts, read ts} gesetzt
• Auswahl
I für Transaktion: set transaction isolation level <level>;
I für Session: set default transaction isolation to <level>;
• write(x) von Transaktion mit ID trans ts
I untersuche Version von x mit maximalem write ts ≤ trans ts:
hat sie read ts > trans ts, wird Transaktion abgebrochen
Denn: dann wurde Snapshot von weiterer, später gestarteter
Transaktion gelesen (⇒ möglicher Konflikt)
I andernfalls wird neue Version von x angelegt
• unterschiedliches Verhalten beim Update
I Im read committed Modus wird Änderung auf Basis
zuletzt committeter Werte durchgeführt.
I Im serializable Modus kann es zum Abbruch mit
can’t serialize“ Fehler kommen
”
Bemerkung:
read committed Modus erfordert explizites Locking:
• bei Sperrverfahren konnte auch ein read zum Abbruch
• Tupel-Ebene: select ... from ... for update;
führen (warum?); bei MVCC klappt read dagegen immer
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -46-
Elektrotechnik
und Informatik
University of Applied Sciences
• Tabellen-Ebene: lock table;
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -48-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.5 Concurrency in SQL
Rückblick
Zwei mögliche Programmierstrategien:
Was haben wir gelernt?
• arbeite im read committed Modus und sperre alle
zu ändernden Sätze mit select for update
BEGIN;
SELECT betrag FROM konto WHERE ... FOR UPDATE;
UPDATE konto SET betrag = ’...’ WHERE ...;
COMMIT;
• arbeite im serializable Modus und fange bei Abbrüchen
• welche Features relationales DBS bereitstellt
I Datenobjekte und Integritätsbedingungen
I Transaktionsverwaltung
• wie man Daten vernünftig“ modelliert
”
I Qualitätsmerkmal Normalformen“
”
I Modellierung über das anschauliche ER-Modell
wieder von vorne an (Retry Loop)
• wie man DBS’e programmiert
I SQL
I clientseitige Programmierschnittstellen
I serverseitige Programmierung
BEGIN;
SELECT betrag FROM konto WHERE ...;
UPDATE konto SET betrag = ’...’ WHERE ...;
if (no error) COMMIT;
else
ROLLBACK;
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -49-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
3.4.5 Concurrency in SQL
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -51-
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Ausblick
Retry-Loop tatsächlich in beiden Fällen nötig:
Was könnten wir noch lernen?
• bei select for update können Lese- und Schreiboperationen
• Objektorientierte Ansätze
I objektorientierte Datenbanken
I objekt-relationale Datenbanken
fehlschlagen wegen Deadlock
• bei serializable können nur Schreiboperationen fehlschlagen
• verteilte Datenbanken
Was ist besser?
• Transaktionen
I Error Recovery
• select for update (pessimistisches Verfahren) wenn viele
Konflikte, denn serializable führt dann häufig zum Abbruch
• serializable (optimistisches Verfahren) wenn wenig Konflikte
Gute Einführung:
http://conferences.oreillynet.com/cs/os2002/view/e sess/2681
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -50-
University of Applied Sciences
University of Applied Sciences
• Implementierung von DBS’en
I Speicherstrukturen und Indizes
I Abfrageoptimierung
I allgemeine Architektur eines DBS
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science
Hochschule Niederrhein
Dalitz: Datenbanksysteme Kap3.4. -52-
University of Applied Sciences
Elektrotechnik
und Informatik
Faculty of Electrical Engineering
and Computer Science