Anomalie - Datenbanksysteme Tübingen

Organisatorisches
Termine
• 2. März: letzte Vorlesung
• 8. März: Klausurvorbereitung
(Durchgehen Klausurähnlicher Aufgaben, Fragestunde)
• 9. März: Besprechungstermin Übungsblatt 6 (Punkte bisher: siehe Aushang)
HiWi Job / Werkvertrag
• Aufsetzen einer MS Access DB für das Qatna-Projekt (Archäologie)
• Projekt mit hoher Sichtbarkeit, siehe z.B.
http://www.spiegel.de/spiegel/0,1518,650267,00.html
Bachelor- / Master- / Studien- / Diplomarbeiten
• Diverse Themen im DB-Bereich an unserem Lehrstuhl
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
2
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
3
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Überblick
Architektur eines DBMS
Figure inspired by Ramakrishnan/Gehrke: “Database Management Systems”, McGraw-Hill 2003.
Web Forms
Applications
SQL Interface
SQL Commands
Executor
Operator Evaluator
Transaction
Manager
Lock Manager
Parser
!
Optimizer
File and Access Methods
Buffer Manager
Disk Space Manager
!
data, files, indices, ...
!
!
!
!
Recovery
Manager
DBMS
Database
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
4
Einführung
Das “Hello World” des Transaktionsmanagement
• Meine Bank hat mir eine EC-Karte ausgestellt.
• Mit dieser Karte kann ich z.B. an Bankautomaten Bargeld abheben.
• Der Geldautomat führt eine Transaktion durch, die sicherstellt, dass mein
Kontostand korrekt aktualisiert wird.
kontostand := leseKontostand(kontonum);
kontostand := Kontostand - 100;
schreibeKontostand(kontonum, kontostand)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
5
Einführung
Nebenläufiger Zugriff (Concurrent Access)
• Das Problem ist: mein Mann hat ebenfalls eine EC-Karte für das selbe Konto.
• Es könnte sein, dass wir zur gleichen Zeit von verschiedenen Geldautomaten aus
Geld abheben möchten. Dies bezeichnen wir als nebenläufigen Zugriff.
ich
(Transaktion 1)
mein Mann
(Transaktion 2)
kontostand :=
leseKontostand(num)
Kontostand
(DB Status)
1200
kontostand :=
leseKontostand(num)
kontostand :=
kontostand - 100
1200
1200
kontostand :=
kontostand - 200
schreibeKontostand
(num, kontostand)
1200
1100
schreibeKontostand
(num, kontostand)
1000
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
6
Einführung
Unterbrochene Transaktionen
• Nehmen wir nun an, dass ich Geld von einem Konto auf ein anderes Konto
überweisen möchte.
giroKontostand := leseKontostand(giro);
giroKontostand := kontostand - 500;
schreibeKontostand(giro, giroKontostand)
sparKontostand := leseKontostand(spar);
sparKontostand := sparKontostand + 500;
Übertragung abgebrochen
• Durch die unterbrochene Transaktion (Stromausfall, Platten-Crash, SoftwareBug, ...) wurde mein Geld verloren.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
7
Einführung
Die ACID Eigenschaften
Um diese (und andere) Effekte zu vermeiden muss ein DBMS folgende
Transaktionseigenschaften gewährleisten:
1.Atomicity (A)
Entweder alle oder keine der Updates, die eine Transaktion durchführt
werden auf der Datenbank angewandt.
2.Consistency (C)
Jede Transaktion bringt die Datenbank von einem konsistenten Zustand in
einen anderen konsistenten Zustan (während der Ausführung der Transaktion
kann die Datenbank zeitweise inkonsistent sein).
3.Isolation (I)
Eine Transaktion darf keine Effekte nebenläufiger Transaktionen beobachten.
Aus Sicht der Transaktion greift sie alleine auf die Datenbank zu.
4.Durability (D)
Die Effekte einer erfolgreichen Transaktion werden persistent gespeichert
und können nicht durch Systemprobleme rückgängig gemacht werden.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
8
Einführung
Transaktionen
• Aus Sicht des DBMS ist eine Transaktion eine Sequenz von Aktionen.
• Eine Aktion wird über ein Datenbankobjekt O durchgeführt. Ein Objekt entspricht z.B.
einem Attribut, einem Tupel, oder einer gesamten Tabelle. In unserer Diskussion
beschränken wir uns auf Objekte, die Attributen entsprechen.
• Mögliche Aktionen einer Transaktion T über ein Datenbankobjekt O:
• Lesen " RT(O)
• Schreiben " WT(O)
• Eine Transaktion muss mit einer der folgenden Aktionen beendet werden:
• Die Transaktion wurde “erfolgreich” durchgeführt " CommitT
• Die Transaktion wurde “nicht erfolgreich” durchgeführt " AbortT
• Zwei wichtige Anahmen:
• Transaktionen interagieren ausschließlich über Lese- und Schreiboperationen auf
der Datenbank miteinander (keine direkten Nachrichten zwischen Transaktionen)
• Eine Datenbank ist eine statische Menge von Datenbankobjekten. Werden Objekte
eingefügt oder gelöscht entstehen weitere Probleme die wir hier nicht betrachten.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
9
Einführung
Schedules
• Ein Schedule ist eine Liste von Aktionen aus
einer Menge von Transaktionen.
• Die Reihenfolge von Aktionen einer bestimmten Zeitachse
Transaktion T innerhalb des Schedules stimmt
mit der Reihenfolge dieser Aktionen in T überein.
• Ein Schedule beschreibt eine
Ausführungssequenz von Aktionen.
• Enthält ein Schedule alle Aktionen (und nichts
anderes) einer Menge von Transaktionen, so
sprechen wir von einem vollständigen
Schedule.
• Sind alle Aktionen jeder Transaktion im Schedule
zusammenhängend, so sprechen wir von einem
seriellen Schedule.
Transaktion T1 Transaktion T2
R(A)
W(A)
R(B)
R(C)
W(C)
W(B)
Commit
Commit
vollständiger Schedule
(Annahme: keine weiteren
Aktionen Teil von T1 und T2)
Transaktion T1 Transaktion T2
R(A)
W(A)
R(C)
W(C)
R(B)
W(B)
serieller Schedule
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
10
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
11
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Anomalien
• Annahmen:
• 2 Transaktionen, die die Konsistenz (consistency) der Datenbank gewährleisten.
• Ein vollständiger Schedule, der diese beiden Transaktionen beinhaltet.
• Eine Datenbank, die vor Ausführung des Schedules in einem konsistenten
Zustand ist.
• Führen wir nun den Schedule aus, so beobachten wir eine Anomalie, wenn die
Datenbank nach der Durchführung aller Aktionen des Schedules einen
inkonsistenen Zustand aufweist.
konsistenter
DB Zustand
Transaktion T1
konsistenter
DB Zustand
konsistenter
DB Zustand
Transaktion T2
konsistenter
DB Zustand
konsistenter
DB Zustand
vollständiger Schedule mit T1 und T2
inkonsistenter
DB Zustand
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
Anomalie
12
Anomalien
• Ein Konflikt tritt zwischen zwei Transaktionen T1 und T2 innerhalb eines Schedules S
auf, wenn
• beide auf das gleiche Datenbankobjekt O zugreigen und
• mindestens einer dieser Zugriffe eine Schreiboperation W(O) durchführt.
• 3 Konflikttypen, die zu Anomalien führen:
1.Write-Write (WW) Konflikt (T1, W, O) ≺S (T2, W, O):
• Der Schedule enthält [..., WT1(O), ..., WT2(O), ...]
" Lost-Update Anomalie
2.Write-Read (WR) Konflikt (T1, W, O) ≺S (T2, R, O):
• Der Schedule enthält [..., WT1(O), ..., RT2(O), ...]
" Dirty-Read Anomalie
3.Read-Write (RW) Konflikt (T1, R, O) ≺S (T2, W, O):
• Der Schedule enthält [..., RT1(O), ..., WT2(O), ...]
" Unrepeatable-Read Anomalie
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
13
Anomalien
Lost-Update Anomalie
• Wir haben bereits ein Beispiel für eine Lost-Update Anomlie auf Folie 4 gesehen
(Schedule unten nochmals wiederholt).
• Der Effekt einer Transaktion geht verloren, weil die zweite Transaktion die Änderung
unkontrolliert überschreibt.
ich
(Transaktion 1)
mein Mann
(Transaktion 2)
kontostand :=
leseKontostand(num)
Kontostand
(DB Status)
1200
kontostand :=
leseKontostand(num)
kontostand :=
kontostand - 100
1200
1200
kontostand :=
kontostand - 200
schreibeKontostand
(num, kontostand)
1200
1100
schreibeKontostand
(num, kontostand)
1000
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
14
Anomalien
Dirty-Read Anomalie
• Eine Transaktion liest Daten, die von der anderen Transaktion geschrieben, aber
noch nicht committed wurden.
• Nehmen wir z.B. an, dass mein Mann und ich fast zeitgleich Geld von unserem
Konto abheben, meine Transaktion aber abgebrochen wird.
ich
(Transaktion 1)
mein Mann
(Transaktion 2)
kontostand :=
leseKontostand(num);
kontostand :=
kontostand - 100;
schreibeKontostand
(num, kontostand);
1200
1200
1100
kontostand :=
leseKontostand(num);
kontostand :=
kontostand - 200;
schreibeKontostand
(num, kontostand);
abort;
Kontostand
(DB Status)
1100
1100
900
900
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
15
Anomalien
Unrepeatable-Read Anomalie
• Eine Transaktion liest einen temporären, nicht konsistenten Zustand der Datenbank,
da die andere Transaktion die für einen konsistenten Zustand nötigen
Schreiboperationen noch nicht durchgeführt und committed hat.
• Betrachten wir nochmals das Überweisungsbeispiel von Folie 5 und nehmen wir
eine zweite Transaktion an, die das Gesamtguthaben über alle Konten abfragt.
Gesamtguthaben (Transaktion 1)
Überweisung (Transaktion 2)
giroKontostand := leseKontostand(giro);
giroKontostand := kontostand - 500;
schreibeKontostand(giro, giroKontostand)
giroGuthaben := leseKontostand(giro);
sparGuthaben := leseKontostand(spar);
guthaben := giroGuthaben + sparGuthaben;
sparKontostand := leseKontostand(spar);
sparKontostand := sparKontostand + 500;
schreibeKontostand(spar, sparKontostand)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
16
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
17
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Serialisierbarkeit
Scheduler
• Der Scheduler entscheidet über die nebenläufige Ausführung von Transaktionen.
• Dazu legt er einen Schedule für diese Transaktionen an.
Client 1
Client 2
3
Client 3
3
2
2
1
1
2
1
Scheduler
...
1
2
1
1
Acces & Storage Layer
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
18
Serialisierbarkeit
Keine Anomalien bei seriellen Schedules
Client 1
• Ein serieller Schedule (siehe Folie 8)
entspricht einer sequentiellen Ausführung der
3
Transaktionen.
• Dadurch wird die Nebenläufigkeit von
Transaktionen vermieden.
• Anomalien treten nur bei nebenläufigen
Transaktionen auf.
• Somit garantiert ein serieller Schedule, dass
keine Anomalien auftreten und damit ist die
Ausführung eines seriellen Schedules immer
korrekt.
Client 2
Client 3
2
2
1
1
1
2
3
Scheduler
3
2
1
2
1
3
2
1
Acces & Storage Layer
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
19
Serialisierbarkeit
Definition
• Keine Nebenläufigkeit zuzulassen (und somit Anomalien zu vermeiden) ist nicht praktikabel.
" Wir erlauben Nebenläufigkeit, wenn garantiert werden kann, dass
der Effekt der Anwendung des nicht-seriellen Schedules,
für jeden möglichen konsistenten Datenbankzustand,
mit dem Effekt eines beliebigen seriellen Schedules der selben Transaktionen
übereinstimmt.
• Es ist möglich, Aktionen in einem Schedule S umzusortieren.
• Die Reihenfolge von Aktionen der selben Transaktion muss dabei beibehalten werden.
• Das Ergebnis des umsortierten Schedules muss dem Ergebnis des initialen Schedules S
entsprechen.
• Existieren Konflikte (siehe Folie 11) zwischen Aktionen verschiedener Transaktionen, so
ist deren relative Reihenfolge wichtig und diese darf demnach nicht geändert werden.
• Kann ein Schedule S mit obigen Regeln in einen Schedule S’ umgewandelt werden, so sagen
wir, dass S konfliktäquivalent zu S’ ist.
• Ein Schedule S ist genau dann konfliktserialisierbar, im folgenden auch nur serialisierbar
genannt, wenn S konfliktäquivalent zu einem beliebigen seriellen Schedule S’ ist.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
20
Serialisierbarkeit
Beispiel
Drei Schedules über Transaktionen T1 und T2 (S2 entspricht seriellem Schedule)
Konfliktrelationen in S1
(T1, R, A) ≺S1 (T2, W, A), (T1, R, B) ≺S1 (T2, W, B),
(T1, W, A) ≺S1 (T2, R, A), (T1, W, B) ≺S1 (T2, R, B),
(T1, W, A) ≺S1 (T2, W, A), (T1, W, B) ≺S1 (T2, W, B)
Konfliktrelationen in S2 (serieller Schedule)
identisch mit Konfliktrelationen von S1
Schedule S1
T1
T2
Schedule S2
T1
T2
Schedule S3
T1
R(A)
R(A)
R(A)
W(A)
W(A)
W(A)
T2
R(A)
R(B)
R(A)
W(A)
W(B)
W(A)
R(B)
R(A)
R(B)
W(B)
W(A)
W(B)
R(B)
R(B)
R(B)
W(B)
W(B)
W(B)
Konfliktrelationen in S3
(T1, R, A) ≺S3 (T2, W, A), (T2, R, B) ≺S3 (T1, W, B),
(T1, W, A) ≺S3 (T2, R, A), (T2, W, B) ≺S3 (T1, R, B),
(T1, W, A) ≺S3 (T2, W, A), (T2, W, B) ≺S3 (T1, W, B)
" S1 ist serialisierbar
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
21
Serialisierbarkeit
Der Konfliktgraph
• Indem wir einen Konfliktgraph G(S) (auch serialization graph genannt) verwenden, können wir
die Korrektheit einer Schedules S überprüfen.
• Ein Knoten von G(S) entspricht einer committeten Transaktion in S.
• Eine gerichtete Kante zwischen zwei Transaktionsknoten Ti ⟶ Tj existiert genau dann
wenn S zwei Aktionen A und A’auf einem Objekt O enthält, so dass (Ti, A, O) ≺S (Tj, A’, O)
(mindestens eine Aktion entspricht einer Schreiboperation).
• S ist genau dann konfliktserialisierbar, wenn G(S) azyklisch ist.
• Ein äquivalenter serieller Schedule kann in diesem Fall direkt durch eine topologische
Sortierung von G(S) identifiziert werden.
Konfliktgraph für S1 und S3 (siehe Folie 19)
Konfliktgraph für S1
T1
T2
azyklischer Graph " serialisierbar
Konfliktgraph für S3
T1
T2
Graph enthält einen Zyklus " nicht serialisierbar
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
22
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
23
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Locking
• Ideal wäre es, wenn der Scheduler stets serialisierbare Schedules produzieren würde.
• Die Idee, um diese Eigenschaft zu gewährleisten basiert auf der Verwendung von Sperren
(Locks).
• Jede Transaktion muss ein Lock zugewiesen bekommen, bevor es auf ein Objekt O zugreift.
• Ein solches Lock garantiert exklusiven Zugriff auf ein Objekt.
• Erst wenn die Transaktion das Objekt wieder freigibt können andere Transaktionen wieder
auf das Objekt zugreifen.
lock(O);
.... Zugriff auf O...;
unlock(O);
• Auf diese Weise wird nebenläufiger Zugriff auf O vermieden.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
24
Locking
• Kann ein Lock nicht an eine Transaktion T vergeben werden (z.B. weil eine andere Transaktion T’
schon ein Lock auf das gewünschte Objekt hat) so wird T blockiert.
• Der Scheduler suspendiert die weitere Ausführung der blockierten Transaktion T.
• Wird der Lock durch T’ wieder freigegeben so kann es T zugewiesen werden. In diesem Fall
wird die Ausführung von T fortgesetzt.
• Da andere Transaktionen fortgesetzt werden können während T pausiert können Locks dazu
verwendet werden, die relative Reihenfolge von Aktionen zu kontrollieren.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
25
Locking
Beispiel für Locking und Scheduling
Zwei Transaktionen
Zwei Schedules, die Lock- und
Unlock-Aufrufe berücksichtigen
Schedule S1
Schedule S2
T1
T1
T2
T1
Lock(A)
Lock(A)
Lock(A)
Lock(A)
W(A)
W(A)
Lock(B)
Lock(B)
Unlock(A)
W(B)
W(A)
Lock(B)
Unlock(A)
W(B)
W(A)
Unlock(B)
Unlock(A)
W(A)
Lock(B)
W(B)
W(A)
Unlock(A)
Write(B)
Unlock(B)
T2
Lock(A)
W(A)
W(B)
Unlock(B)
T2
Lock(A)
W(A)
Lock(B)
W(B)
W(A)
Unlock(A)
Write(B)
Unlock(B)
Write(B)
Unlock(B)
Lock(B)
Unlock(A)
W(B)
Unlock(B)
In diesem Beispiel sind sowohl S1 also auch S2 serlialisierbar. Ist das verallgemeinerbar?
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
26
Locking
Beispiel, das zeigt, dass Locking noch keine Serialisierbarkeit garantiert.
Selbst wenn wir dem lock/unlock Schema folgen, sehen wir an folgendem Schedule, dass wir immer
noch nicht-serialisierbare Schedules erhalten können:
T1
T2
Lock(A)
Lock(C)
W(A)
W(C)
Wie sieht der Konfliktgraph in diesem Bsp. aus?
Unlock(A)
Lock(A)
W(A)
Lock(B)
Unlock(A)
W(B)
Unlock(B)
Unlock(C)
Lock(B)
W(B)
Unlock(B)
Lock(C)
W(C)
Unlock(C)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
27
Locking
Beispiel, das zeigt, dass Locking noch keine Serialisierbarkeit garantiert (Fortsetzung Bsp. Folie 12).
Transaktion 1
Transaktion 2
Lock(num)
DB Status
1200
R(num)
Unlock(num)
Lock(num)
R(num)
Unlock(num)
Lock(num)
W(num)
1100
Unlock(num)
Lock(num)
W(num)
Unlock(num)
1000
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
28
Zwei-Phasen-Sperr-Protokoll
Auch Two-Phase Locking, 2PL genannt
• Das Zwei-Phasen-Sperr-Protokoll führt eine weitere Beschränkung auf die allgemeine Struktur
einer Transaktion ein:
Wenn eine Transaktion erstmal ein Lock freigegeben hat (d.h., hat sie das erste Unlock
aufgerufen), so kann sie keine weiteren Locks mehr bekommen (d.h. kein Lock-Aufruf mehr
danach).
# of locks held
time
lock phase
release phase
lock point
• Das Zwei-Phasen-Sperr-Protokoll ist das Protokoll für die Kontrolle nebenläufiger Transaktionen,
das in Datenbanksystemen heutzutage verwendet wird.
• Intuitiv werden Aktionen, zwischen denen Konflikte auftreten in serieller Reihenfolge ausgeführt.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
29
Zwei-Phasen-Sperr-Protokoll
Auch Two-Phase Locking, 2PL genannt
Ein Schedule, der 2PL nicht einhält.
Transaktion 1
Transaktion 2
Lock(num)
Erster UnlockAufruf von T1
DB Status
1200
R(num)
Unlock(num)
Lock(num)
R(num)
Erneute LockAnforderung
von T1
Lock(num)
W(num)
#
Erster UnlockAufruf von T2
Unlock(num)
1100
Unlock(num)
Lock(num)
W(num)
Unlock(num)
Erneute LockAnforderung
von T2
#
1000
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
30
Zwei-Phasen-Sperr-Protokoll
Auch Two-Phase Locking, 2PL genannt
Ein Schedule, der 2PL einhält.
Transaktion 1
Transaktion 2
Lock(num)
DB Status
1200
R(num)
Lock(num)
W(num)
Unlock(num)
1100
T2 blockiert
Lock(num)
R(num)
W(num)
900
Unlock(num)
In diesem Beispiel entspricht der Schedule dem seriellen Schedule. Dies ist im Allgemeinen
allerdings nicht zwangsläufig der Fall (siehe nächste Folie).
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
31
Zwei-Phasen-Sperr-Protokoll
Auch Two-Phase Locking, 2PL genannt
Ein Schedule, der 2PL einhält und keinem seriellen Schedule entspricht
Transaktion 1 Transaktion 2
Lock(A)
R(A)
Lock(B)
W(B)
Unlock(B)
Lock(B)
W(B)
Unlock(A)
Unlock(B)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
32
Zwei-Phasen-Sperr-Protokoll
Auch Two-Phase Locking, 2PL genannt
• Das Zwei-Phasen-Sperr-Protokoll gibt nicht genau vor, wann
Locks gesetzt und wieder freigegeben werden.
locks
held
time
• 2 mögliche Varianten:
“lock phase”
Preclaiming 2PL
• Preclaiming 2PL: alle Locks werden zu Anfang der Transaktion
gesetzt und nach und nach wieder freigegeben.
• Strict 2PL: Locks werden nach und nach von Transaktion T
gesetzt und erst bei Beendigung von T wieder freigegeben. Bei
Strict PL kann zudem eine andere Transaktion T’ erst wieder
auf von T gesperrte Objekte zugreifen, wenn T committed bzw.
abgebrochen wurde (duch commit bzw. abort Aktion).
release phase
locks
held
time
lock phase
“release phase”
Strict 2PL
Motivation für die ein oder andere Variante?
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
33
Zwei-Phasen-Sperr-Protokoll
Cascading Rollbacks
• Betrachten wir drei Transaktionen, von denen T1 abbricht.
T1
w(x)
r(x)
T2
T3
r(x)
t1 t2
abort ;
�
time
• Wenn T1 abbricht, haben T2 und T3 bereits von T1 geschriebene Daten gelesen (siehe dirty read, Folie
13).
• In diesem Fall muss nicht nur T1 mittles eines Rollback rückgängig gemacht werden, sonder auch T2
und T3 (cascading rollback).
• Das bedeutet letztendlich, dass T2 und T3 nicht committed werden können, bevor T1 nicht committed
wurde.
• Durch die Anwendung von Strict PL wird cascading rollback komplett vermieden, da Locks (insb. Lock
auf X) erst bei Commit von T1 (bzw. nach Abort + Rollback) wieder freigegeben werden.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
34
Lock-Typen
• Ein Konflikt tritt nur dann auf, wenn eine Schreiboperation involviert ist.
• Solange Daten nur gelesen werden, muss ein Datenbankobjekt nicht exklusiv durch eine
Transaktion gelockt sein.
" DBMS verwenden üblicherweise verschiedene Lock-Typen (lock modes) um nebenläufige
Leseoperationen zu erlauben.
• Read-Locks oder Shared-Locks: Lock_S(O)
• Write-Locks oder Exclusive-Locks: Lock_X(O)
• Während des 2PL kann versucht werden, einen Shared-Lock in einen Exclusive-Lock umzuwandeln
(lock upgrade). Dies ermöglicht eine stärkere Nebenläufigkeit.
• Locks sind nur dann zueinander im Konflikt wenn mindestens ein Lock ein Exclusive-Lock ist und
somit das Objekt für alle Transaktionen sperrt (siehe Kompatibilitätsmatrix).
Locks in T2
Locks
in T1
shared
exclusive
shared
exclusive
!
#
#
#
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
35
Lock-Typen
Verwendung von Shared-Locks und Exclusive-Locks
Transaktion 1 Transaktion 2
Lock_S(A)
R(A)
Lock_S(A)
R(A)
Lock_X(B)
R(B)
W(B)
Unlock(A)
Unlock(B)
Commit
Lock_X(C)
R(C)
W(C)
Unlock(A)
Unlock(B)
Commit
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
36
Deadlocks
• Wie bei vielen lock-basierten Protokollen kann es unter Verwendung des 2PL zu Deadlocks
kommen.
• Im Fall eines Deadlocks würden Transaktionen unbegrenzt lange aufeinander warten.
Verwendung von Shared-Locks und Exclusive-Locks
Transaktion 1 Transaktion 2
Lock_X(A)
R(A)
Lock_X(B)
W(B)
Lock_X(B)
Lock_X(A)
...
...
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
37
Deadlocks
Erkennen von Deadlocks
Basierend auf Abhängigkeitsgraphen
• Lock Manager speichert einen Wartet-Auf-Graphen.
• Knoten entsprechen Transaktionen.
• Eine gerichtete Kante von Ti $ Tj existiert genau dann, wenn Ti durch einen Lock, den Tj hält, blockiert
ist.
• Dieser Graph wird regelmäßig auf Zyklen untersucht, da ein Zyklus einem Deadlock entspricht.
• Wird ein Zyklus entdeckt, so wird der Deadlock aufgelöst, indem eine oder mehrere Transaktionen
abgebrochen werden.
• Wahl der abzubrechenden Transaktion(en) ist komplex:
• Junge Transaktionen bevorzugt zu beenden kann dazu führen, dass diese stets neu gestartet und wieder
abgebrochen werden.
• Alte Transaktionen abzubrechen kann dazu führen, dass tendentiell komplexere, und daher langwierige
Berechnungen verworfen werden (was die Kosten der Undo-Operation, die die bisherigen Schritte
rückgängig macht teuer machen kann).
Basierend auf Timeouts
• Eine Transaktion T wir nur solange blockiert, weil sie auf ein Lock wartet, bis ein Timeout stattfindet (wenn
maximale Wartezeit überschritten).
• In Fall eines Timeouts wird die Transaktion T abgebrochen.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
38
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
39
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Spezialisierte Locking Techniken
Dynamische Datenbanken und das Phantom Problem
• Bisher haben wir angenommen, dass keine Daten hinzugefügt bzw. gelöscht werden.
• Lassen wir diese Operationen zu, müssen wir mit sogenannten Phantom-Objekten umgehen.
• Phantom-Objekte entstehen, wenn eine Transaktion T1 eine Menge von Daten sperrt und annimmt, diese sei
vollständig und unveränderbar.
• Währenddessen verändert eine Transaktion T2 die Menge relevanter Daten von T1, indem Sie Objekte
hinzufügt oder löscht, die zur gesperrten Menge von Daten gehören sollten.
Nebenläufiger Zugriff auf B+ Bäume
• Wenden wir 2PL auf B+ und ISAM Bäume an, so haben wir das Problem, dass der Wurzelknoten, der den
Einstiegspunkt in den Baum darstellt, einen Engpass bildet.
• Spezialisierte Locking-Protokolle, die die hierarchische Struktur betrachten erlauben effizientere
Lösungen.
Locking verschiedener Granularität
• Bisher haben wir die Diskussion auf das Locking von Attributen beschränkt.
• Hier betrachten wir nun den Fall, wo weitere Objekte gesperrt werden können. Sperrbare Objekte bilden
dabei eine Teilmengenrelation (z.B. Attribut Teil eines Tupels, Tupel Teil einer Relation, Relation Teil eines
Schemas, usw. )
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
40
Dynamische Datenbanken
Das Phantom-Problem
Beispiel von Phantom-Tupeln
Transaktion T1
SELECT rating, max(age) AS MaxAge
FROM Sailors
GROUP BY rating
HAVING rating = 1 OR rating = 2
Transaktion T2
INSERT INTO Sailors VALUES(..., 1, ..., 96);
DELETE FROM Sailors WHERE Rating = 2 AND Age > 70;
Transaktion T1
Transaktion T2
Sperre alle Tupel mit Rating = 1;
Scan der Menge gesperrter Tupel, um max(age) zu bestimmen;
Sperre freien Speicher, um neues Tupel zu speichern;
Schreibe neues Tupel mit Rating = 1 und Age = 96;
Sperre alle Tupel mit Rating = 2 UND Age > 70;
Entferne gesperrte Tupel (beinhaltet ältesten Sailor mit Rating=2);
Gebe alle Sperren wieder frei;
Sperre alle Tupel mit Rating = 2;
Scan der Menge gesperrter Tupel, um max(age) zu bestimmen;
Gebe alle Sperren wieder frei;
Ergebnis des obigen Schedules
Ergebnis des seriellen Schedules {T1, T2}
Ergebnis des seriellen Schedules {T2, T1}
Rating
MaxAge
Rating
MaxAge
Rating
MaxAge
1
2
80
63
1
2
80
75
1
2
96
63
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
41
Dynamische Datenbanken
Das Phantom-Problem
• Ist eine Datenbank nicht statisch, so ist Konfliktserialisierbarkeit keine Garantie mehr für Serialisierbarkeit!
• Dieses Problem entsteht dadurch, dass T1 annimmt, stets über die korrekte Menge von Tupeln, die relevant
sind zu verfügen.
• Die Menge von Tupeln, die für T1 relevant sind kann sich nun jedoch über die Zeit durch Einfügen bzw.
Löschen sogenannter Phantom-Tupel durch T2 ändern.
" Die Annahme von T1 ist obsolet.
• Die Lösung des Problems besteht darin, die Annahme von T1 sicherzustellen. Zwei Alternativen:
• Bereichs-Locking
• Ohne Index: Die ganze Datei wird von T1 gesperrt, so dass keine Daten in dieser Datei durch eine
andere Transaktion hinzugefügt bzw. entfernt werden können.
• Mit Index über einschänkendes Attribut: Alle Seiten, die Dateneinträge aus dem relevanten Bereich
enthalten können (z.B. Rating = 1) werden im Index gesperrt. Wenn T1 versucht, die Menge der Tupel
dieses Bereichs zu ändern, so muss T2 auch den Index modifizieren, was durch gezieltes Sperren der
Indexseiten verhindert wird.
• Predikat-Locking
• Es ist möglich, implizit alle Records zu sperren, die einem beliebigen Prädikat entsprechen.
• Dieser allgemeiner Ansatz ist allerdings aufwendig in der Implementierung und wird daher nur selten
verwendet.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
42
Nebenläufiger Zugriff auf Baum-Indizes
Beispiel
• Eine Transaktion Tw fügt Daten auf der Blatt-Ebene eines B+ Baums ein, was zu einem Split führt.
1. Das Einfügen führt zu einem Split von Knoten 2 " Knoten 2’ wird hinzugefügt.
• Der Split wird zu Knoten 9 propagiert. Das bedeutet, dass wir einen neuen Separator in Knoten 9 einfügen.
• Wir nehmen an, dass Knoten 9 noch nicht voll ist und somit den Separator aufnehmen kann.
2. Bevor wir den Separator in Knoten 9 einfügen, versucht eine Transaktion TR Daten des ehemaligen Knoten 2 zu
finden, die durch den Split auf 2’ wiederverteilt wurden.
3. Der “alte” Knoten 9 leitet die Anfrage auf Knoten 2 um, obwohl die gesuchten Daten dort nicht mehr existieren.
4. TR glaubt somit fälschlicherweise, dass es keine der Suche entsprechenden Daten mehr gibt.
14
TR
2
" Nebenläufigkeit in B+ Bäumen
muss unterstützt werden.
TW
12
13
8
9
1
11
#
3
1
10
2
2’
3
4
5
6
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
7
43
Nebenläufiger Zugriff auf Baum-Indizes
Verwendung des 2PL
Suche in B+ Bäumen
•
•
Wir traversieren den Baum von oben nach unten (top-down) entlang eines Pfads P.
Basierend auf dem Inhalt eines Knoten entscheiden wir, welchen Kind-Knoten wir im nächsten Schritt
besuchen.
Einfügen in B+ Bäumen
•
•
•
Führe Suche aus.
Füge Daten in den richtigen Blattknoten ein (und in die Daten-Datei, hier nicht betrachtet).
Abhängig vom Füllgrad der Knoten auf dem Pfad P werden dort Splits von unten nach oben
(bottom-up) propagiert.
Nebenläufigkeit mittels 2PL
•
•
•
Shared Read-Locks auf alle Seiten auf Pfad P.
Exclusive Write-Locks beim Einfügen von Daten auf alle Seiten auf Pfad P.
Alle Locks werden erst wieder freigegeben, wenn die Transaktion beendet ist.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
44
Nebenläufiger Zugriff auf Baum-Indizes
Verwendung des 2PL
• Durch die naive Strategie, einfach 2PL zu verwenden, wird die Nebenläufigkeit stark
reduziert:
• Alle Transaktionen müssen den Wurzelknoten sperren, der somit zum Flaschenhals wird.
• Effektiv wird duch Locks auf dem Wurzelknoten eine serielle Ausführung aller (Schreib-)
Transaktionen durchgeführt.
"2PL ist keine praktikable Locking-Strategie für B+ Bäume.
• Verbesserung durch zwei wesentliche Beobachtungen:
1. Die inneren Knoten des Baumes werden bei der Suche nur zum Weiterleiten der Suche
an das nächste Kind verwendet. Die Suche wandert niemals aufwärts, sondern immer nur
abwärts.
2. Ein Lock auf einen Knoten n ist bei einer Schreiboperation nur dann nötig, wenn ein Split
bis zu diesem Knoten hochpropagiert werden kann.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
45
Nebenläufiger Zugriff auf Baum-Indizes
Locking-Strategie bei Suchoperationen
• Suchoperationen benötigen nur Shared-Locks auf Seiten des Suchpfads P.
• Da garantiert ist, dass ein Knoten nie wieder angefasst wird, sobald sein Kindknoten
betrachtet wird, können wir folgende Locking-Strategie einsetzen:
• Ein Lock auf Knoten n kann freigegeben werden, sobald ein Lock auf Kindknoten n’
gesetzt wurde " lock coupling.
Transaktion TR
14
TR
Lock_S(14)
Lock_S(12)
12
Unlock(14)
13
Lock_S(9)
8
Unlock(12)
9
10
11
Lock_S(2)
Unlock(9)
Unlock(2)
1
2
3
4
5
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
6
7
46
Nebenläufiger Zugriff auf Baum-Indizes
Locking-Strategie bei Schreiboperationen
• Auch bei Schreiboperationen folgen wir im Baum genau einem Pfad P.
• Ein Insert kann zu einem Split auf der Blattebene führen, der sich entlang P von unten
nach oben fortsetzen kann.
• Daher benötigen wir Exclusive-Locks im Fall einer Schreiboperation.
• Ein Knoten n wird nur dann gesplittet, wenn sein Kindknoten n’ auf P bereits vollständig
gefüllt ist. Ansonsten kann n’ den neuen Separator aufnehmen und n bleibt unverändert.
• In diesem Fall blockiert n’ das Propagieren von Splits überhalb von n’ und wir
bezeichnen n’ als sicheren (safe) Knoten.
• Daraus folgt, dass wir auf P erst ab Knoten n’ abwärts den Pfad P sperren.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
47
Nebenläufiger Zugriff auf Baum-Indizes
Locking-Strategie bei Schreiboperationen
• Wir nehmen an, dass Knoten 2 voll ist, was dazu führt, dass Knoten 2 gesplittet wird.
• Dieser Split muss in Knoten 9 reflektiert werden.
• Wir nehmen an, Knoten 9 ist noch nicht voll. Somit ist Knoten 9 ein sicherer Knoten.
• Das bedeutet, dass Knoten 12 vom Split nicht mehr betroffen sein kann.
• Effektiv müssen wir in diesem Beispiel nur Knoten 9 und Knoten 2 Sperren.
Transaktion TW
14
Lock_X(14)
TW
Lock_X(12)
12
Lock_X(9)
13
Unlock(12)
8
Unlock(14)
9
10
11
Lock_X(2)
Unlock(2)
Unlock(9)
1
2
3
4
5
6
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
7
48
Nebenläufiger Zugriff auf Baum-Indizes
Algorithmen
Lock-Coupling Protokoll für Lese-Transaktionen
root := Wurzelknoten;
Setze Shared-Lock auf root;
current := root;
while current ist kein Blattknoten do
begin
child := Kind von current, das durch Suche als nächstes betrachtet wird;
Setze Shared-Lock auf child;
Gebe Shared-Lock auf current wieder frei;
current := child;
end
Lock-Coupling Protokoll für Schreib-Transaktionen
root := Wurzelknoten;
Setze Shared-Lock auf root;
current := root;
while current ist kein Blattknoten do
begin
child := Kind von current, das durch Suche als nächstes betrachtet wird;
Setze Exclusive-Lock auf child;
current := child;
if current ist ein sicherer Knoten then
Gebe alle Locks über Vorfahren von current wieder frei;
end
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
49
Nebenläufiger Zugriff auf Baum-Indizes
Nebenläufigkeit über Lock-Coupling hinaus verbessern
• Selbst unter Verwendung von Lock-Coupling werden zahlreiche Sperren auf innere
Knoten gesetzt " verringert die Nebenläufigkeit.
• Die Wahrscheinlichkeit, dass ein innerer Knoten tatsächlich von einem Update betroffen
ist, ist sehr gering.
• Sei z.B. der Grad eines B+ Baumes d = 50. Dann verursacht im Schnitt nur jede 50ste
Einfügeoperation einen Split, was 2% der Einfügeoperationen entspricht.
"Eine Insert-Transaktion kann optimistisch annehmen, dass es zu keinem Split kommt.
• Es werden wie bei der Suche nur Shared-Locks auf innere Knoten gesetzt + ExclusiveLock auf betroffenen Blattknoten.
• Erweist sich die Annahme als falsch und ein Split ist doch erforderlich, wird der Baum
ein zweites Mal traversiert, wobei die nötigen Exclusive-Locks gesetzt werden.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
50
Locking Verschiedener Granularität
geringe Nebenläufigkeit & wenig Overhead
Datenbank
Tablespace
Tabelle
Seite
Vergrösserung
der
Granularität
=
Erhöhung der
Nebenläufigkeit &
des Overheads
Tupel
Attribut
hohe Nebenläufigkeit & hoher Overhead
" Locking mit verschiedener Granularität
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
51
Locking Verschiedener Granularität
• Wir können für jede Transaktion entscheiden, welche Granularität Sperren haben (abhängig
von den Eigenschaften der Transaktion).
Beispiel eines Tupel-Locks
Beispiel eines Tabellen-Locks
SELECT *
FROM SAILORS
WHERE SID = 42
SELECT *
FROM SAILORS
(SID ist Schlüsselattribut)
• Wie kann man bei Locks verschiedener Granularität feststellen, ob ein Objekt bereits
gesperrt ist?
• Z.B. sollte die linke Anfrage ein Tupel nur sperren können, wenn die Gesamttabelle nicht
gesperrt ist.
• Das Erkennen solcher Abhängigkeiten muss effizient gelöst sein.
" Ausnutzen der hierarchischen Beziehung der sperrbaren Objekte (n Tupel ⊆ 1 Relation,
n Relationen ⊆ 1 Schema, ...)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
52
Locking Verschiedener Granularität
Intention-Locks
• Intuitiv werden, wenn ein Objekt O gesperrt wird, sowohl O als auch alle Kinder von O in der
Objekthierarchie gesperrt.
• Zusätzlich wird eine neue Art Lock eingeführt, das sogenannte Intention-Lock, das beim
Sperren von O verwendet wird, um dessen Vorfahren in der Objekthierarchie zu sperren.
• Intention-Share-Lock (IS) für Vorfahren eines in Shared-Modus gesperrten Objekts.
• Intention-Exclusive-Lock (IX)
für Vorfahren eines in Exclusive-Modus gesperrten Objekts.
S
S
X
#
IS
IX
#
X
#
#
#
#
IS
#
IX
#
#
Erweiterte Konfliktmatrix
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
53
Locking Verschiedener Granularität
Intention-Locks
Locking-Prrotokoll für Locks verschiedener Granularität
1. Bevor ein Objekt O durch ein Lock in Modus M ∈ {S, X} gesperrt
werden kann, muss die Transaktion ein IM-Lock auf alle Objekte
“groberer” Granularität erhalten, die O beinhalten.
2. Wenn alle Intention-Locks gewährt wurden, kann die Transaktion
Objekt O in Modus M sperren.
Beispiel
Anfrage 1
SELECT *
FROM SAILORS
WHERE SID = 42
(SID ist Schlüsselattribut)
Anfrage 2
SELECT *
FROM SAILORS
Anfrage 1 erhält z.B.
• IS-Lock auf die Sailors-Tabelle (und auf den Tablespace und die Datenbank, die die Sailors-Tabelle enthalten).
• S-Lock auf das Tupel mit SID = 42.
Anfrage 2 erhält z.B.
• S-Lock auf die Sailors-Tabelle (und auf enthaltenden Tablespace und die Datenbank), da dieser S-Lock nicht in
Konflikt zu den IS-Locks von Anfrage 1 steht.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
54
Locking Verschiedener Granularität
Intention-Locks
Beispiel
Anfrage 1
SELECT *
FROM SAILORS
WHERE SID = 42
(SID ist Schlüsselattribut)
Anfrage 2
SELECT *
FROM SAILORS
Anfrage 3
UPDATE SAILORS
SET SNAME = ‘John Smith’
WHERE SID = 17
Anfrage 3 versucht, folgene Locks zu erhalten:
• IX-Lock auf die Sailors-Tabelle (und auf “gröbere” Objekte)
• X-Lock auf das Tupel mit SID = 17
Somit ist Anfrage 3
• Kompatibel mit Anfrage 1, da kein Konflikt zwischen IX und IS auf der Tabellen-Ebene entsteht.
• Inkompatibel mit Anfrage 2, da S-Lock auf Sailors-Tabelle der Anfrage 2 in Konflikt mit dem IX-Lock von
Anfrage 3 steht.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
55
Transaktionscharakteristiken in SQL92
Isolationslevel
• SERIALIZABLE: Implementiert Strict-2PL für dynamische DB
• Locks werden vor Lese- und Schreiboperationen angefordert, inkl. Locks für Mengen von
Daten, die unverändert bleiben müssen (um Phantom Problem zu vermeiden, siehe Folie 40).
• Locks werden bis zur Beendigung der Transaktion gehalten.
• Andere Transaktionen können erst auf Objekte zugreifen, wenn Transaktion committet bzw.
abbricht.
• REPEATABLE READ: Implementiert Strict-2PL für statische DB
• Locks auf einzelne Objekte (nicht auf Objektmengen) werden vor Lese- und
Schreiboperationen angefordert.
• Locks werden bis zur Beendigung der Transaktion gehalten.
• Andere Transaktionen können erst auf Objekte zugreifen, wenn Transaktion committet bzw.
abbricht.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
56
Transaktionscharakteristiken in SQL92
Isolationslevel
• READ COMMITTED: Implementiert Strict PL für Schreiboperationen und statische DB
• Exclusive-Locks werden vor Schreiboperation angefordert und diese werden bis zur Beendigung
der Transaktion gehalten. Weitere Transaktionen können erst nach commit bzw. abort+rollback
wieder auf gesperrte Objekte zugreifen.
• Shared-Locks werden vor Leseoperationen angefordert und so schnell wie möglich wieder
freigegeben. Diese Locks garantieren lediglich, dass die gelesenen Daten von einer commiteten
Transaktion stammen.
• READ UNCOMMITTED: Für Read-Only Transaktionen
• Es werden keine (Shared-)Locks für Leseoperationen beantragt.
• Schreiboperationen sind nicht zugelassen.
" Transaktion ohne Locks und ohne Schreiboperationen
Level
Dirty Read
READ UNCOMMITTED
!
READ COMMITTED
#
#
#
REPEATABLE READ
SERIALIZABLE
Unrepeatable Read
Phantom
!
!
#
#
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
!
!
!
#
57
Kapitel 10
Transaktionsmanagement
• Einführung
• Anomalien
• Serialisierbarkeit
• Zwei-Phasen-Sperr-Protokoll
• Spezialisierte Locking
Techniken
• Nebenläufigkeit ohne Locking
58
Architektur und Implementierung von Datenbanksystemen | WS 2009/10
Melanie Herschel | Universität Tübingen
Optimistic Concurrency Control
• Bisher war unser Ansatz, Nebenläufigkeit zu regulieren, pessimistisch:
• Wir gehen dabei davon aus, dass Transaktionen in Konflikt zueinander stehen.
• Wir vermeiden Anomalien, die durch Konflikte entstehen, durch Sperren und
Sperrprotokolle.
• Im Gegensatz dazu steht der optimistische Ansatz, genannt optimistic concurrency control.
• Hier gehen wir vom besten Fall aus und führen Lese- und Schreiboperationen ohne
Sperren durch.
• Bevor die Änderungen einer Transaktion commitet werden wird jedoch überprüft, ob
tatsächlich keine Konflikte entstanden sind.
• Grundannahme des optimistic concurrency control ist, dass Konflikte nur selten auftreten und
dass der Overhead, den Sperren und Sperrprotokolle mit sich bringen eingespart werden
kann, indem man einen Mehraufwand nur in den seltenen Fällen, wo Konflikte auftreten
betreibt.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
59
Optimistic Concurrency Control
Unter optimistic concurrency control folgen Transaktionen drei Phasen:
1. Lesephase: Die Transaktion wird ausgeführt, indem Daten aus der DB gelesen werden
und in einen privaten Workspace geschrieben werden.
2. Validierungsphase: Wenn die Transaktion committen möchte, wird überprüft, ob die
Ausführung korrekt ist (also keine Konflikte aufgetreten sind). Ist dies nicht der Fall, wird
die Transaktion mit abort abgebrochen.
3. Schreibphase: Wird in Phase 2 kein Konflikt festgestellt, werden die Änderungen, die im
privaten Workspace der Transaktion gespeichert sind, in die Datenbank übernommen.
• Phasen 2 und 3 müssen in einer nicht-unterbrechbaren critical section ausgeführt werden
(auch Val-Write-Phase genannt).
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
60
Multiversion Concurrency Control
• Nehmen wir folgenden Schedule an:
t
RT1(x), WT1(x), RT2(x), WT2(y), RT1(y), WT1(y)
Ist dieser Schedule serialisierbar?
• Nehmen wir nun an, dass zu dem Zeitpunkt, wo T1 Objekt y lesen möchte, immer noch eine
Kopie des “alten” Werts von y existiert, der zum Zeitpunkt t (vor widersprüchlichem WT2(y))
galt.
• Somit könnten wir einen Schedule verwenden, der äquivalent zu folgendem serialisierbaren
Schedule wäre:
RT1(x), WT1(x), RT2(x), RT1(y), WT2(y), RT1(y), WT1(y)
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
62
Multiversion Concurrency Control
•Speichern wir alte Versionen überschriebener Objekte, so müssen Leseoperationen nicht mehr
blockiert werden.
•In diesem Fall können Leseoperation zwar veraltete Daten lesen, aber diese Daten
entsprechen einem konsistenten Zustand.
•Problematisch bei multiversion concurrency control ist der Verwaltungsmehraufwand und der
Speicherbedarf, die durch Versionierung nötig ist.
•Einige kommerzielle DBMS implementieren diese Technik, z.B., Oracle, SQL Server,
PostgreSQL.
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
63
Zusammenfassung
Nebenläufige Transaktionen
• Transaktionen erfüllen die ACID-Eigenschaften.
• Transaktionen werden durch Scheduler in einen Schedule zusammengefasst.
• Es können im allgemeinen Anomalien auftreten.
2-Phasen-Sperr-Protokoll (2PL)
• Wichtige Konzepte: Serialisierbarkeit und Sperren verschiedener Art (Shared, Exclusive)
• 2PL, insb. Strict-2PL ist das am weitesten verbreitete Protokoll für nebenläufige Transaktionen.
Spezialisierte / erweiterte Locking Techniken
• Für dynamische Datenbanken
• Für Baum-Indizes
• Für Objekte verschiedener Granularität
Nebenläufigkeit ohne Sperren
• Optimistischer Ansatz
• Versionierung
Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen
64