Transaktion

3.6 Transaktionsverwaltung
§ Transaktionen erlauben „Bündelung“ von Operationen
und gelten als wichtigster Beitrag des Bereichs
Datenbanken zur Informatik; sie werden heute auch
außerhalb von Datenbanksystemen z.B. in
Betriebssystemen eingesetzt
§ Jim Gray hat 1998 u.a. für seine Beiträge
zur Transaktionsverwaltung den
A. M. Turing Award gewonnen
Quelle: http://research.microsoft.com
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
223
3.6.1 Transaktionsbegriff
§ Transaktion ist eine logisch zusammenhängende Folge
von Operationen, die ohne Einflüsse anderer zeitgleich
verarbeiteter Transaktionen und ohne Fehler
ausgeführt werden soll
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
224
Banküberweisung als Beispiel
§ Beispiel: Überweisung von 50€ von Konto A nach Konto B
1
2
3
UPDATE Konten
SET KontoStand = KontoStand - 50
WHERE KontoName = ’A ’
4
5
6
7
UPDATE Konten
SET KontoStand = KontoStand + 50
WHERE KontoName = ’B ’
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
225
Banküberweisung als Beispiel
§ Beispiel: Überweisung von 50€ von Konto A nach Konto B
1) a = read(A) Lese Kontostand von Konto A in Variable a
2) a = a – 50 Reduziere den Wert von a um 50
3) write(A,a) Schreibe neuen Kontostand von A
4) b = read(B) Lese Kontostand von Konto B in Variable b
5) b = b + 50 Erhöhe den Wert von b um 50
6) write(B,b) Schreibe neuen Kontostand von B
§ Was passiert, wenn der Strom ausfällt?
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
226
Transaktionsanfang und Transaktionsende
§ Wie können wir mehrere Operationen zusammenfassen?
§ begin of transaction (bot)
markiert den Anfang einer Transaktion
§ commit
markiert das Ende einer erfolgreichen Transaktion,
deren Änderungen festgeschrieben werden sollen
§ rollback
markiert das Ende einer erfolglosen Transaktion,
deren Änderungen rückgängig zu machen sind
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
227
Banküberweisung als Beispiel
§ Beispiel: Überweisung von 50€ von Konto A nach Konto B
1) begin of transaction
2) a = read(A) Lese Kontostand von Konto A in Variable a
3) a = a – 50 Reduziere den Wert von a um 50
4) write(A,a) Schreibe neuen Kontostand von A
5) b = read(B) Lese Kontostand von Konto B in Variable b
6) b = b + 50 Erhöhe den Wert von b um 50
7) write(B,b) Schreibe neuen Kontostand von B
8) commit
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
228
Eigenschaften von Transaktionen
§ Transaktionen sollen die folgenden Eigenschaften haben
§ Atomicity (Atomarität)
§ Consistency (Konsistenz/Integrität)
§ Isolation (Isolation)
§ Durability (Dauerhaftigkeit)
§ Datenbanksysteme müssen so implementiert werden,
dass diese sogenannten ACID-Eigenschaften
sichergestellt werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
229
Eigenschaften von Transaktionen
§ Atomicity (Atomarität): Entweder werden alle Änderungen
der Transaktion in der Datenbank festgeschrieben
oder gar keine („ganz oder gar nicht“)
§ Beispiel: Werden die 50€ von Konto A abgebucht, so
müssen sie auch Konto B gutgeschrieben werden;
ein „Verlust“ der 50€ ist ausgeschlossen. Fällt bspw. der
Strom zwischen den beiden Buchungsvorgängen aus, so
muss bei Wiederanlauf des RDBMS die Abbuchung von
Konto A automatisch rückgängig gemacht werden.
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
230
Eigenschaften von Transaktionen
§ Consistency (Konsistenz): Die Transaktion hinterlässt die
Datenbank in einem konsistenten Zustand gemäß der
definierten Integritätsbedingungen; andernfalls muss
die Transaktion zurückgesetzt werden
§ Beispiel: Eine Integritätsbedingung könnte sein, dass kein
Konto seinen Kreditrahmen überschreiten darf; wird diese
Konsistenzbedingung für A verletzt, darf die Überweisung
nicht durchgeführt werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
231
Eigenschaften von Transaktionen
§ Isolation (Isolation): Die Transaktion muss so auf der
Datenbank ausgeführt werden, als wäre sie die einzige
Transaktion, d.h. es darf keine Wechselwirkungen mit
anderen zeitgleich ausgeführten Transaktionen geben
§ Beispiel: Kontostand von Konto A darf nicht geschrieben
werden, wenn er zwischenzeitlich durch eine andere
Transaktion verändert wurde
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
232
Eigenschaften von Transaktionen
§ Durability (Dauerhaftigkeit): Wird eine Transaktion
erfolgreich abgeschlossen, so müssen ihre
Änderungen dauerhaft in der Datenbank
festgeschrieben sein, d.h. auch nach
einem Fehler noch vorhanden sein
§ Beispiel: Fällt der Strom in der Bank aus, kurz nachdem
unsere Überweisung durchgeführt wurde, müssen
sich die 50€ noch immer auf Konto B befinden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
233
Fehlerarten
§ Datenbanksystem muss ACID-Eigenschaften bei
verschiedenen Arten von Fehlern sicherstellen
§ Fehler ohne Primärspeicherverlust
(z.B. durch Fehler in der Anwendung)
§ Fehler mit Primärspeicherverlust
(z.B. durch Stromausfall)
§ Fehler mit Sekundärspeicherverlust
(z.B. durch technischen Defekt der Festplatte)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
234
Fehlerbehandlung
T1
T2
Zeit
Fehler
§ Fehlerbehandlung muss sicherstellen, dass die Wirkungen
§ der erfolgreich abgeschlossenen Transaktion T1
dauerhaft in übernommen sind
§ der erfolglosen Transaktion T2
rückgängig gemacht werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
235
Fehlerbehandlung
§ Fehlerbehandlung (recovery) stellt einen konsistenten
Zustand der Datenbank nach einem Fehler wieder her
§ Fehler ohne Primärspeicherverlust
können relativ einfach behoben werden
§ Fehler mit Primärspeicherverlust
erfordern die Wiederherstellung eines konsistenten Zustands
aus den gespeicherten Daten und dem Verlaufsprotokoll
§ Fehler mit Hintergrundspeicherverlust
erfordern die Wiederherstellung eines konsistenten Zustands
aus Archivkopie der Daten und dem Verlaufsprotokoll
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
236
Mehrbenutzerbetrieb
§ Datenbankoperationen greifen meist auf langsame
Ressourcen (z.B. Sekundärspeicher) zu
§ Parallele Ausführung mehrerer Transaktionen führt zu
besserer Auslastung schneller Ressourcen (z.B. CPU)
und insgesamt höherer Leistung des Datenbanksystems
T1
T2
Zeit
Zeit
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
237
Mehrbenutzerbetrieb
§ Mehrbenutzerbetrieb, d.h. parallele Ausführung mehrerer
Transaktionen, ist wünschenswert, um die Leistung
zu steigern, führt aber zu Problemen:
§ Abhängigkeit von nicht festgeschriebenen Änderungen
z.B. von anderen nebenläufigen Transaktionen
(dirty read)
§ Verlust von Änderungen an den Daten
(lost update)
§ Gelesene Daten zwischenzeitlich verändert
(non-repeatable read & phantom read)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
238
Dirty Read
§ Abhängigkeit von nicht festgeschriebenen Änderungen
§ Überweisung von 30€ von Konto A nach Konto B
§ Verzinsung von Konto A mit 1%
T1
1
2
3
4
5
6
7
8
a1 = read(A)
a1 = a1 ≠ 30
write(A, a1 )
b1 = read(B)
rollback
T2
a2 = read(A)
a2 = a2 ú 1.01
write(A, a2 )
§ T2 liest geänderten („dreckigen“) Kontostand von A
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
239
Lost Update
§ Verlust von Änderungen an den Daten
§ Überweisung von 30€ von Konto A nach Konto B
§ Verzinsung von Konto A mit 1%
T1
1
2
3
4
5
6
7
8
9
a1 = read(A)
a1 = a1 ≠ 30
write(A, a1 )
b1 = read(B)
b1 = b + 30
write(B, b1 )
T2
a2 = read(A)
a2 = a2 ú 1.01
write(A, a2 )
§ T1 überschreibt zwischenzeitliche Änderung durch T2
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
240
Non-Repeatable Read
§ Nichtwiederholbares Lesen von Zeilen
§ Kontostand von Konto A
§ Überweisung von Lottogewinn auf Konto A
§ Kontostand von Konto A (zwischenzeitlich verändert)
T1
1
2
3
SELECT * FROM Konten
WHERE Konto = ’A’
SELECT * FROM Konten
WHERE Konto = ’A’
T2
UPDATE Konten
SET KontoStand = KontoStand + 100.000
WHERE Konto = ’A’
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
241
Phantom Read
§ Nichtwiederholbares Ergebnis (d.h. Zeilenmenge)
durch (eingefügte/gelöschte) Phantomdaten
§ Liste aller überzogenen Konten (Konto A sei überzogen)
§ Konto A wird überzogen
§ Liste aller überzogenen Konten (enthält A nicht mehr)
T1
1
2
3
SELECT * FROM Konten
WHERE KontoStand < 0
SELECT * FROM Konten
WHERE KontoStand < 0
T2
UPDATE Konten
SET KontoStand = KontoStand - 100.000
WHERE Konto = ’A’
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
242
Synchronisation
§ Datenbanksysteme stellen Isolation von Transaktionen im
Mehrbenutzerbetrieb durch Sperrmechanismen sicher
§ Unterschiedliche Arten von Sperren (z.B. Lesesperre)
und Sperrgranulaten (z.B. Datensatz oder Tabelle)
§ Transaktionen werden derart verschachtelt, dass dies
nicht von serieller Ausführung zu unterscheiden ist
§ RDBMSs unterstützten verschiedene Isolationsstufen
zur Auflockerung der Anforderungen bzgl. Isolation
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
243
3.6.2 Transaktionen in SQL
§ Transaction Control Language (TCL) als Bestandteil
von SQL stellt Kommandos für Transaktionen bereit
§ BEGIN TRANSACTION <Name der Transaktion>
markiert den Anfang einer benannten Transaktion
(Benennung wird eher selten verwendet)
§ COMMIT <Name der Transaktion>
schreibt die Änderung der Transaktion fest
§ ROLLBACK <Name der Transaktion>
macht Änderungen der Transaktion rückgängig
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
244
Transaktionen in SQL
§ Transaktionen in SQL enden entweder erfolgreich mit
einem COMMIT oder erfolglos mit einem ROLLBACK
§ Transaktionsanfang ist meist implizit, d.h. eine
Transaktion beginnt mit dem ersten Kommando bzw. dem
ersten Kommando nach einem COMMIT oder ROLLBACK
§ RDBMSs unterstützen AUTOCOMMIT (ON/OFF),
dann wird jedes Kommando als eigene
Transaktion behandelt
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
245
Savepoints
§ Einige RDBMSs (z.B. MS SQL Server) erlauben zusätzlich
die Markierung sogenannter Savepoints
innerhalb einer Transaktion mittels
1
SAVE TRANSACTION < Name des Savepoints >
§ Transaktion kann dann bis zu einem definierten Savepoint
mittels ROLLBACK zurückgefahren werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
246
3.6.3 Fehlerbehandlung
§ Fehlerbehandlung (recovery) stellt die Atomarität,
Integrität und Dauerhaftigkeit von Transaktionen sicher,
wenn Fehler mit/ohne Primärspeicherverlust auftreten
§ Verlaufsprotokoll (log) protokolliert Änderungen der
Daten, bevor diese an Daten selbst vorgenommen werden
§ Verlaufsprotokoll erlaubt Rekonstruktion eines
konsistenten Zustands der Datenbank sowie
Rücksetzen der Änderungen durch eine
einzelne Transaktion (ROLLBACK)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
247
Pufferverwaltung
§ RDBMSs verwenden Seitenersetzungsstrategie, um bei
vollem Puffer zu entscheiden, welche Seite verdrängt wird
§ Seiten können von RDBMS im Puffer festgehalten
werden (fix) und dürfen dann nicht verdrängt werden
§ Seiten dürfen verdrängt werden, auch wenn sie durch
nicht abgeschlossene Transaktion geändert wurden
§ Seiten dürfen im Puffer bleiben, auch wenn sie durch
eine abgeschlossene Transaktion geändert wurden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
248
Wiederherstellen und Rückgängigmachen
§ Bei Fehler mit Primärspeicherverlust (z.B. Stromausfall)
muss das DBMS sicherstellen, dass
§ Änderungen durch nicht abgeschlossene Transaktionen,
die bereits im Sekundärspeicher materialisiert wurden,
rückgängig gemacht werden (undo)
§ Änderungen durch abgeschlossene Transaktionen,
die noch nicht im Sekundärspeicher materialisiert sind,
wiederholt werden (redo)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
249
Verlaufsprotokoll
§ RDBMSs verwenden ein Verlaufsprotokoll (log), um
Datenänderungen zu protokollieren und diese bei Bedarf
wiederholen oder rückgängig machen zu können
§ Verlaufsprotokoll wird auf Sekundärspeicher und
Tertiärspeicher geschrieben
§ Jeder Eintrag im Verlaufsprotokoll entspricht genau
einer Änderung der Daten einer Seite
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
250
Verlaufsprotokoll
§ Einträge des Verlaufsprotokoll haben folgende Struktur
§ LSN (log sequence number) – durchlaufende Nummer
§ TA - Transaktionskennung
§ PID – Seitennummer, auf der geänderte Daten stehen
§ REDO-Information und UNDO-Information
§ PrevLSN – Verweis auf vorigen Eintrag des
Verlaufsprotokolls, der zur gleichen Transaktion gehört
§ Seiten vermerken zudem die LSN der letzten Änderung,
an den darin enthaltenen Daten
25
P1
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
251
Verlaufsprotokoll
§ Beispiel: Überweisung von 30€ von Konto A nach B
1
2
3
4
5
6
7
8
T1
Verlaufsprotokoll
(LSN, TA, PID, REDO, UNDO, PrevLSN)
bot
a = read(A)
a = a ≠ 30
write(A, a1 )
b = read(B)
b = b + 30
write(B, b)
commit
(#1, T1 , , bot, , )
(#2, T1 , PA , A≠ = 30, A+ = 30, #1)
(#3, T1 , PB , B+ = 30, B≠ = 30, #2)
(#4, T1 , , commit, , #3)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
252
WAL-Prinzip
§ Verlaufsprotokoll wird mittels Ringpuffer implementiert,
um Ausschreiben auf Sekundärspeicher
effizienter zu machen
§ Wiederherstellen und Rückgängigmachen funktionieren
nur, wenn das Write-Ahead-Log-Prinzip verwendet wird
§ bevor eine Transaktion festgeschrieben wird, müssen alle
zu ihr gehörenden Log-Einträge ausgeschrieben werden
§ bevor eine geänderte Seite aus dem Puffer verdrängt wird,
müssen alle Log-Einträge, die sich auf sie beziehen,
ausgeschrieben werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
253
Wiederanlauf nach einem Fehler
§ Bei Fehler mit Primärspeicherverlust, lässt sich ein
konsistenter Zustand aus Daten und Verlaufsprotokoll
in drei Schritten wiederherstellen
1) Bestimme Gewinner (winner) und Verlierer (looser), deren
Änderungen wiederholt bzw. rückgängig gemacht werden
2) Wiederherstellen aller Änderungen (REDO-Einträge)
mittels chronologischem Durchlauf des Verlaufsprotokolls
3) Rückgängigmachen der Änderungen von Verlierern
(UNDO-Einträge) mittels umgekehrt chronologischem
Durchlauf des Verlaufsprotokolls
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
254
Gewinner und Verlierer
§ Gewinner (winner) und Verlierer (looser) unter den
Transaktionen werden durch Analyse des
Verlaufsprotokolls ermittelt
§ Eine Transaktion wird zum Gewinner, wenn das
Verlaufsprotokoll sowohl einen bot-Eintrag
als auch einen commit-Eintrag für sie enthält
§ Eine Transaktion wird zum Verlierer, wenn das
Verlaufsprotokoll nur einen bot-Eintrag
jedoch keinen commit-Eintrag für sie enthält
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
255
Wiederherstellen aller Änderungen
§ Verlaufsprotokoll wird in chronologischer Reihenfolge
durchlaufen und für jeden Eintrag
§ betroffene Seite vom Sekundärspeicher in den
Puffer geholt, sofern sie noch nicht dort ist
§ LSN des Log-Eintrags mit in der Seite gespeicherter
LSN der letzten Änderung verglichen
§ REDO-Operation auf die Seite angewandt, sofern
LSN des Log-Eintrags größer (d.h. neuer) als
LSN der letzten Änderung ist
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
256
Rückgängigmachen von Änderungen
§ Verlaufsprotokoll wird in umgekehrt chronologischer
Reihenfolge durchlaufen und für jeden Eintrag
§ überprüft, ob er zu einer Verlierer-Transaktion gehört
und sofern dies der Fall ist die Änderung mittels der
UNDO-Operation rückgängig gemacht
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
257
Zurücksetzen einer Transaktion
§ Verlaufsprotokoll unterstützt auch das Zurücksetzen einer
Transaktion mittels ROLLBACK, indem
§ die zur Transaktion gehörenden Log-Einträge rückwärts
entlang ihrer PrevLSN-Einträge durchlaufen werden
§ für jeden Log-Eintrag die darin vermerkte
UNDO-Operation ausgeführt wird
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
258
3.6.4 Mehrbenutzerbetrieb
§ Bei nebenläufiger Ausführung mehrerer Transaktionen
muss deren Isolation sichergestellt werden
§ Man kann mittels Serialisierbarkeitsgraph feststellen, ob
eine verschachtelte Ausführung mehrerer Transaktionen
zu einer seriellen Ausführung äquivalent ist
§ RDBMSs erreichen Synchronisation durch Sperren, die
einer Transaktion exklusiven Lese-/Schreibzugriff
z.B. auf einer Seite sichern
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
259
Serialisierbarkeit
§ Historie bezeichnet eine verschachtelte Ausführung von
elementare Operationen mehrerer Transaktionen
§ ri(A)
Transaktion i liest den Wert von A
§ wi(A)
Transaktion i schreibt den Wert von A
§ ai
Transaktion i wird abgebrochen
§ ci
Transaktion i wird festgeschrieben
§ Historie erfasst die Reihenfolge der elementaren
Operationen innerhalb einer Transaktion
r1(A) ⟶ w1(A) ⟶ c1
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
260
Serialisierbarkeit
§ Stehen elementare Operationen verschiedener
Transaktionen in Konflikt, muss die Historie
zusätzlich deren Reihenfolge festlegen, z.B.
§ ri(A) und wj(A) da je nach Reihenfolge
die Transaktion i den neuen oder alten Wert von A liest
§ wi(A) und wj(A) da je nach Reihenfolge
der von Transaktion i oder
der von Transaktion j geänderte Wert von A bestehen bleibt
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
261
Serialisierbarkeit
§ Beispiel: Verschachtelte Ausführung dreier Transaktionen
⟶
r3(A) ⟶ w3(C) ⟶ c3
⟶
r2(B) ⟶ w2(B) ⟶ w2(A) ⟶ w2(D) ⟶ c2
r1(A) ⟶ w1(A) ⟶ c1
§ Historie legt Reihenfolge w1(A) vor w2(A) vor r3(A)
für die in Konflikt stehenden Operationen fest
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
262
Serialisierbarkeitsgraph
§ Serialisierbarkeitsgraph lässt sich aus Historie ableiten
§ je Transaktion Ti gibt es einen Knoten
§ die Kante (Ti, Tj) ist vorhanden, wenn in der Historie eine
Operation von Ti vor einer Operation von Tj liegt
§ Beispiel:
⟶
r2(B) ⟶ w2(B) ⟶ w2(A) ⟶ w2(D) ⟶ c2
r1(A) ⟶ w1(A) ⟶ c1
⟶
T2
⟶
⟶
r3(A) ⟶ w3(C) ⟶ c3
T3
T1
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
263
Serialisierbarkeitsgraph
§ Historie ist genau dann serialisierbar (d.h. äquivalent zu
einer seriellen Ausführung der Transaktionen), wenn der
Serialisierbarkeitsgraph azyklisch ist
§ Beispiel: Historie ist äquivalent zur seriellen Ausführung
der Transaktionen T1, T2 und T3
⟶
r2(B) ⟶ w2(B) ⟶ w2(A) ⟶ w2(D) ⟶ c2
r1(A) ⟶ w1(A) ⟶ c1
⟶
T2
⟶
⟶
r3(A) ⟶ w3(C) ⟶ c3
T3
T1
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
264
Sperrbasierte Synchronisation
§ RDBMSs verwenden Sperren, um sicherzustellen, dass
verschachtelte Ausführung von Transaktionen
äquivalent zu einer seriellen Ausführung ist
§ Lesesperre (shared lock, read lock) S auf A erlaubt
Transaktion Ti die Operation ri(A) auszuführen;
mehrere Transaktionen können aufgrund einer
Lesesperre lesend auf A zugreifen
§ Schreibsperre (exclusive lock, write lock) X auf A erlaubt
Transaktion Ti die Operation wi(A) auszuführen;
nur eine Transaktion kann bei einer Schreibsperre
lesend oder schreibend auf A zugreifen
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
265
Verträglichkeit von Sperren
§ Es gelten folgende Verträglichkeiten zwischen Sperren
gesetzte Sperre
keine
S
X
Anforderung von S
Anforderung von X
ja
ja
ja
nein
nein
nein
§ Besteht z.B. bereits eine Lesesperre auf einem Objekt,
kann eine weitere Lesesperre, jedoch keine
Schreibsperre angefordert werden
§ Die anfordernde Transaktion muss dann warten, bis die
bestehenden Lesesperren freigegeben werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
266
2-Phasen Sperrprotokoll
§ Serialisierbarkeit der Historie wird mittels des 2-PhasenSperrprotokolls (two phase locking, 2PL) sichergestellt
§ jedes in einer Transaktion benutzte Objekt wird gesperrt
§ jede Transaktion durchläuft zwei Phasen
§ Wachstumsphase, in der zusätzliche Sperren angefordert,
aber keine bereits erworbenen freigegeben werden
§ Schrumpfungsphase, in der bereits erworbene Sperren
freigegeben, aber keine neuen angefordert werden
§ zum Transaktionsende müssen alle Sperren freigegeben sein
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
267
2-Phasen Sperrprotokoll
§ Wachstumsphase und Schrumpfungsphase im 2PL
# Sperren
Zeit
Wachstum
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
Schrumpfung
268
2-Phasen Sperrprotokoll
§ Beispiel: Verschachtelung gemäß 2-Phasen Sperrprotokoll
T2
Erläuterung
lockS(A)
T2 muss warten
a2 = read(A)
lockS(B)
T2 wecken
T2 muss warten
T1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
lockX(A)
a1 = read(A)
write(A)
lockX(B)
read(B)
unlockX(A)
write(B)
unlockX(B)
commit
b1 = read(B)
T2 wecken
unlockS(A)
unlockS(B)
commit
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
269
Verklemmungen (deadlocks)
§ Sperren können zu Verklemmungen (deadlocks) führen,
d.h. Transaktionen warten gegenseitig aufeinander
T1
1
2
3
4
5
6
7
lockX(A)
a1 = read(A)
write(A)
lockX(B)
T2
Erläuterung
lockX(B)
b2 = read(B)
lockS(A)
T1 wartet auf T2
T2 wartet auf T1
§ RDBMS erkennt Verklemmungen (z.B. mittels
Überwachung des Fortschritts) und löst sie auf,
indem es eine der Transaktionen abbricht
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
270
Isolationsstufen
§ SQL-92 definiert vier Isolationsstufen (isolation levels),
die Lockerung der Anforderung Isolation ermöglichen
§ Serializable
§ Repeatable Read
phantom read erlaubt
§ Read Committed
non-repeatable read und phantom read erlaubt
§ Read Uncommitted
dirty read, non-repeatable read und phantom read erlaubt
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
271
Isolationsstufen
§ Niedrigere Isolationsstufe
§ erlaubt eine stärkere Verschachtelung von Transaktionen
§ reduziert die Anzahl benötigter Sperren
§ verringert zur Ausführung der Transaktionen benötigte Zeit,
was beim Mehrbenutzerbetrieb sehr wichtig sein kann
§ nimmt hierzu Inkonsistenzen der Daten in Kauf
§ Isolationsstufe für aktuelle und kommende Transaktionen
lässt sich mittels folgenden SQL-Kommandos festlegen
1
SET TRANSACTION ISOLATION LEVEL < Isolationsstufe >
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
272
Zusammenfassung
§ Transaktionen als logisch zusammenhängende Folge von
Operationen, die ganz oder gar nicht ausgeführt wird
§ ACID-Eigenschaften von Transaktionen
§ Atomicity (Atomarität)
§ Consistency (Integrität/Konsistenz)
§ Isolation (Isolation)
§ Durability (Dauerhaftigkeit)
§ Fehlerbehandlung & Synchronisation zur Wahrung der
ACID-Eigenschaften bei Fehlern und Mehrbenutzerbetrieb
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
273
Literatur
[1]
A. Kemper und A. Eickler: Datenbanksysteme – Eine
Einführung, De Gruyter Oldenbourg, 2015 (Kapitel 9)
[2]
G. Saake, K.-U. Sattler und A. Heuer:
Datenbanken - Konzepte und Sprachen,
mitp Professional, 2013 (Kapitel 12)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
274