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 225
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 226
Banküberweisung als Beispiel Beispiel: Überweisung von 50 von Konto A nach Konto B 1 UPDATE Konten 2 SET KontoStand = KontoStand - 50 3 WHERE KontoName = A 4 5 UPDATE Konten 6 SET KontoStand = KontoStand + 50 7 WHERE KontoName = B 227
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? 228
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 229
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 230
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 231
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. 232
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 233
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 234
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 235
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) 236
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 237
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 238
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 239
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) 240
Dirty Read Abhängigkeit von nicht festgeschriebenen Änderungen Überweisung von 30 von Konto A nach Konto B Verzinsung von Konto A mit 1% T 1 T 2 1 a 1 = read(a) 2 a 1 = a 1 30 3 write(a, a 1 ) 4 a 2 = read(a) 5 a 2 = a 2 ú 1.01 6 write(a, a 2 ) 7 b 1 = read(b) 8 rollback T 2 liest geänderten ( dreckigen ) Kontostand von A 241
Lost Update Verlust von Änderungen an den Daten Überweisung von 30 von Konto A nach Konto B Verzinsung von Konto A mit 1% T 1 T 2 1 a 1 = read(a) 2 a 1 = a 1 30 3 a 2 = read(a) 4 a 2 = a 2 ú 1.01 5 write(a, a 2 ) 6 write(a, a 1 ) 7 b 1 = read(b) 8 b 1 = b + 30 9 write(b,b 1 ) T 1 überschreibt zwischenzeitliche Änderung durch T 2 242
Non-Repeatable Read Nichtwiederholbares Lesen von Daten Liste der überzogenen Konten (soll Konto A beinhalten) Überweisung von Lottogewinn auf Konto A Liste der überzogenen Konten (enthält Konto A nicht mehr) T 1 T 2 1 SELECT * FROM Konten WHERE KontoStand < 0 2 UPDATE Konten SET KontoStand = KontoStand + 100.000 WHERE Konto = A 3 SELECT * FROM Konten WHERE KontoStand < 0 Konto A wurde zwischenzeitlich verändert und ist nun nicht mehr im Ergebnis enthalten 243
Phantom Read Nichtwiederholbares Ergebnis durch Phantomdaten Gesamtguthaben über alle Konten Konto C wird eröffnet und 1000 in bar werden eingezahlt Gesamtguthaben über alle Konten T 1 T 2 1 SELECT SUM(KontoStand) FROM Konten 2 INSERT INTO Konten ( C, 1000) 3 SELECT SUM(KontoStand) FROM Konten Ergebnis der Anfrage von T 1 ändert sich, da zwischenzeitlich andere Daten hinzugefügt wurden 244
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 245
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 246
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 247
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 248
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) 249
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 250
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) 251
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 252
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 253
Verlaufsprotokoll Beispiel: Überweisung von 30 von Konto A nach B T 1 Verlaufsprotokoll (LSN, TA, PID, REDO, UNDO, PrevLSN) 1 bot (#1, T 1,, bot,, ) 2 a = read(a) 3 a = a 30 4 write(a, a 1 ) (#2, T 1, P A, A = 30, A+ =30, #1) 5 b = read(b) 6 b = b + 30 7 write(b,b) (#3, T 1, P B, B+ =30, B = 30, #2) 8 commit (#4, T 1,, commit,, #3) 254
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 255
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 256
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 257
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 258
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 259
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 260
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 261
Serialisierbarkeit Historie bezeichnet eine verschachtelte Ausführung von elementare Operationen mehrerer Transaktionen r i (A) Transaktion i liest den Wert von A w i (A) Transaktion i schreibt den Wert von A a i Transaktion i wird abgebrochen c i Transaktion i wird festgeschrieben Historie erfasst die Reihenfolge der elementaren Operationen innerhalb einer Transaktion r 1 (A) w 1 (A) c 1 262
Serialisierbarkeit Stehen elementare Operationen verschiedener Transaktionen in Konflikt, muss die Historie zusätzlich deren Reihenfolge festlegen, z.b. r i (A) und w j (A) da je nach Reihenfolge die Transaktion i den neuen oder alten Wert von A liest w i (A) und w j (A) da je nach Reihenfolge der von Transaktion i oder der von Transaktion j geänderte Wert von A bestehen bleibt 263
Serialisierbarkeit Beispiel: Verschachtelte Ausführung dreier Transaktionen r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 Historie legt Reihenfolge w 1 (A) vor w 2 (A) vor r 3 (A) für die in Konflikt stehenden Operationen fest 264
Serialisierbarkeitsgraph Serialisierbarkeitsgraph lässt sich aus Historie ableiten je Transaktion T i gibt es einen Knoten die Kante (T i, T j ) ist vorhanden, wenn in der Historie eine Operation von T i vor einer Operation von T j liegt Beispiel: T 3 r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 T 2 T 1 265
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 T 1, T 2 und T 3 T 3 r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 T 2 T 1 266
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 T i die Operation r i (A) auszuführen; mehrere Transaktionen können aufgrund einer Lesesperre lesend auf A zugreifen Schreibsperre (exclusive lock, write lock) X auf A erlaubt Transaktion T i die Operation w i (A) auszuführen; nur eine Transaktion kann bei einer Schreibsperre lesend oder schreibend auf A zugreifen 267
Verträglichkeit von Sperren Es gelten folgende Verträglichkeiten zwischen Sperren gesetzte Sperre keine S X Anforderung von S ja ja nein Anforderung von X ja 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 268
2-Phasen Sperrprotokoll Serialisierbarkeit der Historie wird mittels des 2-Phasen- Sperrprotokolls (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 269
2-Phasen Sperrprotokoll Wachstumsphase und Schrumpfungsphase im 2PL # Sperren Wachstum Schrumpfung Zeit 270
2-Phasen Sperrprotokoll Beispiel: Verschachtelung gemäß 2-Phasen Sperrprotokoll T 1 T 2 Erläuterung 1 lockx(a) 2 a 1 = read(a) 3 write(a) 4 locks(a) T 2 muss warten 5 lockx(b) 6 read(b) 7 unlockx(a) 8 a 2 = read(a) T 2 wecken 9 locks(b) T 2 muss warten 10 write(b) 11 unlockx(b) T 2 wecken 12 b 1 = read(b) 13 commit 14 unlocks(a) 15 unlocks(b) 16 commit 271
Verklemmungen (deadlocks) Sperren können zu Verklemmungen (deadlocks) führen, d.h. Transaktionen warten gegenseitig aufeinander T 1 T 2 Erläuterung 1 lockx(a) 2 lockx(b) 3 b 2 = read(b) 4 a 1 = read(a) 5 write(a) 6 lockx(b) T 1 wartet auf T 2 7 locks(a) T 2 wartet auf T 1 RDBMS erkennt Verklemmungen (z.b. mittels Überwachung des Fortschritts) und löst sie auf, indem es eine der Transaktionen abbricht 272
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 273
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> 274
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 275
Literatur [1] A. Kemper und A. Eickler: Datenbanksysteme Eine Einführung, De Gruyter Oldenbourg, 2013 (Kapitel 9) [2] G. Saake, K.-U. Sattler und A. Heuer: Datenbanken - Konzepte und Sprachen, mitp Professional, 2013 (Kapitel 12) 276