Datenbanken 1. Kapitel 7: Transaktionsmanagement 7-1. Datenbanken 1 (Bachelor)

Transkript

1 Datenbanken 1 Kapitel 7: Transaktionsmanagement 7-1

2 Transaktionsmanagement Inhalte des Kapitels Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien Lernziele Strategisches Verständnis für die ACID-Eigenschaften von Transaktionen Kenntnis der unterschiedlichen Kategorien von Concurrency-Konflikten Kenntnis der entsprechenden Isolationlevel Anwendung von Transaktionskonzepten im Rahmen von JDBC Kenntnis der Vorgänge beim Recovery Kenntnis unterschiedlicher Backupstragien 7-2

3 Transaktionsmanagement Ein einführendes Beispiel... while c%found loop if v_gehalt > then update angestellter set gehalt = gehalt * proz1 where current of c; else update angestellter end if; set gehalt = gehalt * proz2 where current of c; fetch c into v_gehalt; end loop; Was passiert, wenn während der Ausführung dieses PL/SQL-Programms das DBMS abstürzt / oder das Betriebssystem abstürzt / oder der Strom ausfällt oder? 7-3

4 Transaktionsmanagement und ein zweites Beispiel: -- Überweisung von 50 Euro von Konto A nach Konto B (1) Lese den Kontostand von A in die Variable a: read(a,a); (2) Reduziere den Kontostand um 50 Euro: a:=a 50; (3) Schreibe den neuen Kontostand in die Datenbasis: write(a,a); (4) Lese den Kontostand von B in die Variable b: read(b,b); (5) Erhöhe den Kontostand um 50 Euro: b:=b+50; (6) Schreibe den neuen Kontostand in die Datenbasis: write(b,b); Was passiert, wenn zwischen der Ausführung von Operation 3 und Operation 4 das DBMS abstürzt / oder das Betriebssystem abstürzt / oder der Strom ausfällt oder? 7-4

5 Transaktionsmanagement In diesem Kapitel werden Konzepte vorgestellt, wie die Integrität und Dauerhaftigkeit der Daten gewährleistet wird bei einer zusammen gehörenden Abfolge von Anweisungen, die entweder alle oder gar nicht ausgeführt werden dürfen, um die Konsistenz der Daten zu gewährleisten Transaktion Transaction, bei Zugriff auf die Daten von mehreren Usern gleichzeitig konkurrierende Zugriffe und Sperren Concurrency und Locking, zur Sicherstellung der Integrität nach dem Wiederanlauf eines Systems Wiederherstellung Recovery. 7-5

6 Das Transaktionskonzept Eine Transaktion ist eine Folge von Datenbankoperationen, die die Daten von einem konsistenten Zustand in einen neuen konsistenten Zustand überführt und entweder ganz oder gar nicht ausgeführt wird (man spricht auch von einer logischen atomaren Einheit / Unit of Work UOW). störungsfreie Ausführung Festschreiben von Zustand B (Commit) Zustand A Zustand B gestörte Ausführung: Zurücksetzen auf Zustand A (Rollback, Abort) Zum zweiten Beispiel: Eine Kontobewegung von Konto1 nach Konto 2 entspricht immer einem Update für das Haben auf Konto 1 und einem Update für das Soll auf Konto 2. Beide Datenbankoperationen müssen gemeinsam vollständig oder dürfen gar nicht ausgeführt werden, um die Integrität der Datenbank zu wahren. 7-6

7 Das ACID-Paradigma für Transaktionen A Atomicity (Atomarität) Transaktionen haben atomaren Charakter: Sie werden ganz oder gar nicht ausgeführt ( alles oder nichts ). Mechanismen zur Fehlerbehandlung sind notwendig. 7-7

8 Das ACID-Paradigma für Transaktionen C Consistency (Konsistenz) Transaktionen bewahren die Konsistenz der Datenbank. Die Datenbank wird durch eine Transaktion von einem konsistenten Zustand in den nächsten überführt. Mechanismen zur Konsistenzsicherung und Fehlerbehandlung sind notwendig. 7-8

9 Das ACID-Paradigma für Transaktionen I Isolation (Isolation) Transaktionen werden bei konkurrierendem Zugriff (concurrency) untereinander getrennt, d.h. jede Transaktion läuft in einem simulierten Single-User-Betrieb. Sperrkonzepte und Synchronisation mehrerer nebenläufigertransaktionen sind notwendig (Scheduling) 7-9

10 Das ACID-Paradigma für Transaktionen D Durability (Dauerhaftigkeit) Datenbank-Updates bleiben nach einem Commit dauerhaft erhalten, auch wenn nach diesem Commit ein Systemausfall stattgefunden haben sollte. Fehlerbehandlung, insbesondere Recovery-Management ist notwendig 7-10

11 Transaktionsmanagement: SQL-Anweisungen Ein DBMS, das das Transaktionskonzept unterstützt, besitzt als Komponente einen Transaktionsmanager, der über folgende SQL-Anweisungen gesteuert wird: BEGIN TRANSACTION expliziter oder impliziter Beginn einer Transaktion eine Transaktion beginnt implizit mit der ersten Anweisung nach Eröffnung einer Session bzw. mit der ersten Anweisung nach dem letzten commit. COMMIT TRANSACTION Transaktion wird als erfolgreich beendet gekennzeichnet. Alle zugehörigen Datenbankänderungen werden festgeschrieben ( Durability!). Syntax: commit [work]; 7-11

12 Transaktionsmanagement: SQL-Anweisungen ROLLBACK TRANSACTION Die Transaktion wird explizit (per Programm) oder implizit (z.b. durch Connection-Verlust) abgebrochen. Alle zugehörigen Datenbankänderungen werden rückgängig gemacht, auch die, die implizit z.b. durch Trigger entstanden sind. Es wird auf den letzten konsistenten Zustand des Systems zurückgesetzt ( Checkpoints / Savepoints). Syntax: rollback [work]; -- Transaktion T1 wird implizit geöffnet update Konto set balance = balance-50 where KontoID = 'A'; update Konto set balance = balance+50 where KontoID = 'B'; -- T1 wird beendet und die Ergebnisse festgeschrieben commit work; -- neue Transaktion T2 wird implizit geöffnet insert into Konto (KontoID, Name, balance) values ('C', 'Meyer', 0); 7-12

13 Transaktionsmanagement Oracle Bei Oracle beginnt eine Transaktion immer mit der ersten, auszuführenden SQL-Anweisung (also implizit) und wird erfolgreich beendet durch COMMIT oder COMMIT WORK. Bricht die Transaktion mit einer Fehlermeldung ab, so spricht man (grundsätzlich) von einem ABORT. Nach jeder einzelnen DDL-Anweisung erfolgt immer(!) ein implizites COMMIT. Innerhalb langer Transaktionen können Savepoints gesetzt werden, die die Transaktion in kleine, atomare Einheiten unterteilen. Im Fehlerfall kann auf jeden deklarierten Savepoint innerhalb der Transaktion zurückgesetzt werden. Syntax: savepoint S1; 7-13

14 Transaktionsmanagement Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien 7-14

15 Concurrency-Konflikte: Lost Update Beim Zugriff mehrerer Transaktionen auf die gleichen Daten (konkurrierende Zugriffe concurrency) können unterschiedliche Kategorien von Konflikten auftreten. Den folgenden Szenarien liegen die Daten eines Flugbuchungssystems zugrunde (x bezeichne jeweils den aktuellen Wert der Spalte AnzahlFreieSitzplätze) : Lost update Zeit T1: read x=100 T1: buche 1 Platz: x:=x-1=99 T1: update... set x = 99; Flugnr AnzahlFreieSitzplätze... LH ( 99 ) T2: read x=100 T2: buche 2 Plätze: x:=x-2=98 T2: update... set x = 98; Insgesamt wurden 3 Plätze gebucht, die Anzahl der vorhandenen Plätze hat sich jedoch nur um 2 reduziert! Wie kann diese Inkonsistenz vermieden werden? 7-15

16 Concurr.-Konflikte: Uncommited Dependency Uncommited Dependency Nicht freigegebene Änderungen Einer Transaktion T2 wird lesender Zugriff auf Daten erlaubt, die von einer Transaktion T1 verändert, aber noch nicht festgeschrieben wurden, also uncommited sind. Transaktion T2 ist somit von Transaktion T1 abhängig (dependent), es erfolgt u. U. ein so genanntes Dirty Read. Flugnr AnzahlFreieSitzplätze... LH ( ) Zeit T1: read x=100 T1: buche 1 Platz: x:=x-1=99 T1: update... set x = 99; T1: rollback T2: read x=99 T2: buche 2 Plätze: x:=x-2=97 T2: update... set x = 97; Welcher Konflikt ist nun entstanden? 7-16

17 Concurr.-Konflikte: Nonrepeatable Read Nonrepeatable Read nicht wiederholbares Lesen Eine Transaktion T1 erwartet in zwei aufeinander folgenden Leseoperationen auf dem gleichen Datum den gleichen Wert. T2 ändert oder löscht diesen zwischen den beiden lesenden Zugriffen: Flugnr AnzahlFreieSitzplätze... LH Zeit T1: read x=100 T1: read x=99 T2: read x=100 T2: buche 1 Platz: x:=x-1=99 T2: update... set x = 99; T2: commit; Innerhalb der selben Transaktion wurden für ein Feld, das von dieser Transaktion nicht verändert wurde(!), unterschiedliche Werte gelesen. Allerdings handelt es sich nicht um ein Dirty Read warum nicht? 7-17

18 Concurrency-Konflikte: Phantom Read Phantom Read das Problem des Phantoms (Inconsistent Analysis) Eine Transaktion T1 analysiert Daten auf einem Datenbestand, während von einer Transaktion T2 ein neuer Datensatz eingefügt wird, der von T1 eigentlich hätte mitberücksichtigt werden müssen. T1 zählt (auf der Variablen count) die Anzahl derjenigen Flüge, die noch nicht ausgebucht sind: T1: count(*) where AnzFreieSitzpl > 0; T1: Ergebnis = 2 T1: Wdh. count: Ergebnis = 3 Zeit Flugnr AnzahlFreieSitzplätze... LH AF KL BA T2: insert into... values ('AF 1018',150,...); T2: commit; 7-18

19 Sperrkonzepte (1) Um die geschilderten Probleme beim konkurrierenden Zugriff mehrerer Transaktionen auf die gleichen Daten zu verhindern, benutzen die meisten Datenbanksysteme Locking-Mechanismen (Sperr-Mechanismen), die es im Zusammenhang mit geeigneten Isolation-Leveln (s. u.) ermöglichen, die genannten Probleme zu vermeiden oder einzuschränken: Locks (Sperren) dienen dazu, anderen Transaktionen solange keinen lesenden und / oder schreibenden Zugriff auf die bearbeiteten Tupel einer aktuellen Transaktion zu ermöglichen, bis die aktuelle Transaktion ein commit oder rollback gegeben hat. Im allgemeinen unterscheidet man zwei Arten von Locks: S-Locks = shared-locks, auch read-locks genannt, und X-Locks = exclusive-locks, auch write-locks genannt. 7-19

20 Sperrkonzepte (2) S-Lock Besitzt eine Transaktion A einen S-Lock auf dem Tupel t, so bewirkt dies: Ein weiterer S-Lock für eine Transaktion B wird zugelassen, anschließend haben beide Transaktionen S-Locks auf t. Alle angeforderten X-Locks anderer Transaktionen werden zurückgewiesen, bis alle S-Locks auf Tupel t wieder freigegeben sind. Hierdurch wird gewährleistet, dass die Daten während des lesenden Zugriffs nicht verändert werden können. X-Lock Besitzt eine Transaktion A einen X-Lock auf dem Tupel t, so bewirkt dies: Alle angeforderten S-Locks anderer Transaktionen werden zurückgewiesen. Alle angeforderten X-Locks anderer Transaktionen werden zurückgewiesen. S X S X 7-20

21 Dead Lock (1) Haben zwei Transaktionen A und B Ressourcen gesperrt, auf deren Freigaben sie jeweils warten, um einen X-Lock zu fordern, so entsteht ein Dead Lock. Beispiel Dead Lock time transact. operation 1 T1 X/S-lock t1 2 T2 X/S-lock t2 3 T1 X-lock t2 4 T2 X-lock t1 wird angefordert wait wird angefordert wait Ein vom DBMS erkannter Dead Lock wird dadurch aufgelöst, dass eine der beteiligten Transaktionen abgebrochen wird. Im allgemeinen gibt es eine maximale Wartezeit für Transaktionen in jedem DBMS. Ist diese maximale Wartezeit überschritten (Time Out), so wird die entsprechende Transaktion ebenfalls abgebrochen (kein Dead Lock!), um die entsprechenden Sperren freizugeben (Aufhebung von Locks). 7-21

22 Dead Lock (2) Dead-Lock-Situationen können durch die Untersuchung so genannter Wait-for-Graphen frühzeitig erkannt werden: Die Ecken des Graphen sind konkurrierende Transaktionen. Die gerichtete Kante zwischen zwei Ecken T1 und T2 des Graphen bedeutet, dass T1 auf die Freigabe einer Sperre durch T2 wartet. T1 T2 Wait-for-Graph für das Beispiel auf der vorhergehenden Folie Ein Dead Lock liegt genau dann vor, wenn der Graph einen geschlossenen Teilgraphen enthält. 7-22

23 Isolationlevel Im o. g. Locking-Konzept wird für eine Transaktion gefordert, ein einmal erworbenes Locking so lange zu halten, bis ein Commit / Rollback für diese Transaktion erfolgt ist. In der Praxis führt dies i. A. zu enormen Behinderungen von Transaktionen (wait-status, Dead Locks). Aus diesem Grund ist es auch möglich, mit Hilfe spezifischer Isolation Level ein differenzierteres Sperrverhalten zu erreichen. Der Isolation Level gibt dabei an, in welchem Maß die jeweilige Sperre konkurrierenden Zugriff auf die Daten zulässt: Isolation Level Dirty Read Daten werden vor einem commit / rollback gelesen Isolation Level (SQL 92) Nonrepeatable Read update / delete von der Seite mit commit möglich Read Uncommitted möglich möglich möglich Read Committed nicht möglich möglich möglich Repeatable Read nicht möglich nicht möglich möglich Phantom Read insert von der Seite mit commit möglich Serializable nicht möglich nicht möglich nicht möglich 7-23

24 Isolationlevel bei DB2 (IBM) DB2 unterstützt genau die Isolation Level des SQL 92 Standards, allerdings mit anderen Bezeichnern: SQL set transaction [ { read only read write } ] [ isolation level { read uncommitted read committed repeatable read serializable } ] DB2 change isolation to [ { UR CS RS RR } ] Uncommitted Read Cursor Stability Read Stability Repeatable Read 7-24

25 Isolationlevel bei Oracle Oracle unterstützt die Isolation Level read committed und serializable des SQL 92 Standards: SQL set transaction [ { read only read write } ] [ isolation level { read uncommitted read committed repeatable read serializable } ] Oracle set transaction [ { read only read write } ] [ isolation level { read committed serializable } ] Isolation Level innerhalb einer Session ändern: alter session set isolation_level Isolationsebene; 7-25

26 Multiversion concurrency control MVCC DBMS mit Multiversionen-Synchronisation (multiversion concurrency control, MVCC) ermöglichen es immer, auf den zuletzt fest geschriebenen Zustand (commit) eines Datenobjektes lesend zu zu greifen. Jedes Objekt x erhält beim letzten Festschreiben einen Zeitstempel ts(x). Jede Transaktion T erhält beim Start einen Zeitstempel ts(t). Konflikte, die aus konkurrierenden Schreibzugriffen zweier Transaktionen entstehen, werden aufgrund einer Zeitstempelanalyse erst beim Commit entdeckt und führen dann ggf. zum Abbruch einer der beteiligten Transaktionen. Sehr viele DBMS arbeiten mittlerweile mit MVCC, u.a. Oracle seit Version 3 IBM DB2 seit Version 9.7 unter Isolationlevel CS (in einem bestimmten Modus) MS SQL Server seit Version SQL Server

27 Multiversion concurrency control MVCC Ein Beispiel Isolation-Level Serializable (Oracle) ts(x=10) = 1 T1: BOT ts(t1) = 2 T1: lese x (vom ts(x) = 1): x = 10 T1: schreibe x:= 20; X-LOCK T1: commit; ts(x=20) = 4 Zeit T2: BOT ts(t2) = 3 T2: lese x (vom ts(x) = 1): x = 10 a) T2: schreibe x: = 30; WAIT b) T2: schreibe x: = 30; "can't serialize access for this transaction" T2 wird in Fall a) und b) zurückgesetzt: der Versuch, das Objekt x fest zu schreiben scheitert deshalb, weil 3 = ts(t2) < ts(x lastcommit ) =4. Vorteil von MVCC? Nachteil von MVCC? 7-27

28 Transaktionsmanagement Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien 7-28

29 JDBC und Transaktionsmanagement 1 Isolation Level und JDBC Der Isolation Level kann für eine Connection explizit gesetzt werden. Unterstützt die Datenbank den in der Methode settransactionisolation(level) übergebenen Level nicht, so wird im Fall von Oracle eine Exception generiert. Wird der Isolationlevel nicht explizit über die o.g. Methode festgelegt, so wird bei Oracle der default-isolationlevel READ_COMMITTED gesetzt. void settransactionisolation(int level) throws SQLException; Konstanten des Connection-Interfaces TRANSACTION_NONE TRANSACTION_READ_UNCOMMITTED TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE -- Beispiel: Isolation Level Serializable wird für die gesamte Session gesetzt con.settransactionisolation(connection.transaction_serializable); 7-29

30 JDBC und Transaktionsmanagement 2 Isolation Level und JDBC Oracle Oracle unterstützt nur - READ_COMMITTED (int-wert = 2) und - SERIALIZABLE (int-wert = 8). Zu allen anderen ILs wird eine Exception generiert. Default-IL ist bei Oracle READ_COMMITTED. TRANSACTION_NONE TRANSACTION_READ_UNCOMMITTED TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE -- Wert des aktuell gesetzten Isolationlevels ausgeben: con.gettransactionisolation(); 7-30

31 JDBC und das Connection-Interface Steuerung des Transaktionsverhalten der Datenbank durch weitere Methoden des Interface Connection: void commit( ) void rollback( ) void setautocommit(boolean autocommit) Nach dem Aufbau der Verbindung ist die Datenbank gemäß JDBC-Spezifikation zunächst im Auto-Commit-Modus, d.h. jede einzelne Anweisung wird als eigene Transaktion angesehen, die nach Ende des Kommandos automatisch bestätigt wird (commit). Eine Änderung kann erreicht werden durch Aufruf von setautocommit mit Übergabe von false. Danach müssen alle Transaktionen explizit durch Aufruf von commit bestätigt bzw. durch rollback zurückgesetzt werden. Nach Abschluss einer Transaktion beginnt automatisch die nächste. 7-31

32 JDBC und das Interface ResultSetMetaData Die Methode getmetadata des Interfaces ResultSet liefert ein Objekt vom Typ ResultSetMetaData zur selektierten Datenmenge. Dieses Objekt kapselt Meta-Informationen zur selektierten Ergebnismenge, z.b. int getcolumncount( ) String getcolumnname(int column) String gettablename(int column) int getcolumntype(int column)... Anzahl der Spalten Name einer Spalte Name einer Tabelle Datentyp einer Spalte 7-32

33 JDBC und das Interface DatabaseMetaData Die Methode getmetadata des Interfaces Connection liefert ein Objekt vom Typ DatabaseMetaData zur aktiven Verbindung. Dieses Objekt kapselt Meta-Informationen zur aktiven Verbindung, die in die folgenden Kategorien unterteilt werden können: Informationen zur Datenbank Informationen zu unterstützten Features Informationen zu Beschränkungen des Treibers Informationen aus dem Systemkatalog Mit Hilfe der Methode supporttransactionisolationlevel des DatabaseMetaData-Objektes kann z.b. abgefragt werden, ob eine Datenbank einen bestimmten Isolation Level unterstützt oder nicht. 7-33

34 Transaktionsmanagement Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien *) *) Ein Teil des Folienmaterials aus diesem Abschnitt stammt aus dem DB-Skript der Kollegin Uta Störl. 7-34

35 Recovery- und Buffermanager Gesamtübersicht der Komponenten beim Zusammenspiel des lokalen Recovery Manager und des Datenbank Buffer Manager: persistenter Log Main memory Lokaler Recovery Manager (LRM) Log Buffer Fetch, Flush Datenbank persistente Datenbank Read Write Datenbank Buffer Manager (BM) Read Write Buffer (volatile Datenbank) Fetch: holt Daten page-weise in den DB-Buffer (read von persistenter DB) Flush: gibt Daten page-weise aus dem DB-Buffer frei (write in persistente DB) 7-35

36 Fehlerklassifikation Klassifikation von Fehlern: Transaktionsfehler Systemfehler Externspeicherfehler Unterschiedliche Recoverymaßnahmen sind je nach Fehlerkategorie erforderlich. 7-36

37 Transaktionsfehler Im Falle von Transaktionsfehlern spricht man beim Wiederherstellen eines konsistenten Zustandes von Transaktionsrecovery: BOT T 1 commit T 1 Zustand A 1 Zustand B 1 BOT T 2 Zustand A 2 abort T 2 Zeit Abort einer einzelnen Transaktion Alle Änderungen der Transaktion T 2 müssen rückgängig gemacht werden UNDO. Alle parallelen Änderungen anderer Transaktionen, die mit commit abgeschlossen wurden, dürfen nicht rückgängig gemacht werden kein Einfluss auf den Rest des Systems auch: lokaler Fehler 7-37

38 Transaktionsfehler und Transaction-Recovery Typische Transaktionsfehler Fehler im Anwendungsprogramm Transaktionsabbruch explizit durch den Benutzer Transaktionsabbruch durch das System Behandlung (Transaction-Recovery) Isoliertes Zurücksetzen aller Änderungen der abgebrochenen Transaktionen = lokales UNDO bzw. R1-Recovery Wichtig: von dieser Seite veränderte Pages können sich sowohl im Datenbank-Puffer als auch bereits auf dem persistenten Speichermedium befinden! 7-38

39 Protokoll der Änderungsinformationen Die durchgeführten Änderungen werden von den meisten DBMS in einem Datenbank-Log geschrieben und persistent gespeichert. Ein Log besteht aus Einträgen der Form: { LSN, TA, PageID, Undo, Redo PrevLSN } LSN: Log-Sequence Number = eindeutige und aufsteigende Nummerierung der Log-Einträge TA: Transaktionskennung (Nummer) PageID: Seitennummer Undo: UNDO-Information Redo: REDO-Information PrevLSN: LSN des letzten Eintrags der selben Transaktion Pro Transaktion werden außerdem die folgenden Informationen geschrieben: BOT record termination record (commit, abort). 7-39

40 Beispiel für Log-Einträge LSN TA PageID Undo Redo PrevLSN #1 T 1 BOT 0 #2 T 1 27 [. A.] [. A.] #1 #3 T 2 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #5 T 1 70 [. B.] [. B.] #2 #6 T 1 commit #5 7-40

41 und entsprechendes Transaktionsrecovery Alle Log-Einträge von T 2 werden in umgekehrter Reihenfolge ihrer ursprünglichen Ausführung gelesen und rückgängig gemacht, d.h. die Undo-Information (alter Zustand der Page) in die Datenbank eingebracht. LSN TA PageID Undo Redo PrevLSN #1 T 1 BOT 0 #2 T 1 27 [. A.] [. A.] #1 #3 T 2 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #5 T 1 70 [. B.] [. B.] #2 #6 T 1 commit #5 #7 T 2 abort #4 7-41

42 Der Truncate-Operator *) Syntax: TRUNCATE TABLE <table_name> Löscht alle Zeilen einer Tabelle. Berücksichtigt keine DELETE-Trigger und kann nur auf Tabellen angewandt werden, die nicht als Parenttabelle von einer FK-Spalte referenziert werden: You cannot truncate the parent table of an enabled foreign key constraint. You must disable the constraint before truncating the table. An exception is that you can truncate the table if the integrity constraint is self-referential. Quelle: Database SQL Language Reference Allokierter Speicher wird freigegeben ohne Einzelprüfung der Datensätze. Es wird kein Log-File geschrieben. Ein Rollback ist nicht möglich! *) vgl. auch Kapitel 5, Folie

43 Systemfehler Im Falle von Systemfehlern spricht man beim Wiederherstellen eines konsistenten Zustandes von Crashrecovery: BOT T 1 commit T 1 Zustand A 1 Zustand B 1 BOT T 2 Zustand A 2 Zeit Systemfehler Alle Daten im Buffer sind zerstört. Alle Daten auf den persistenten Speichermedien sind noch verfügbar. 7-43

44 Systemfehler und Crash-Recovery Typische Systemfehler DBMS-Fehler Betriebssystemfehler Hardware-Fehler Behandlung (Crash-Recovery) Nachvollziehen der von abgeschlossenen Transaktionen nicht in die DB eingebrachten Änderungen = partielles REDO bzw. R2-Recovery Zurücksetzen der von nicht beendeten Transaktionen in die DB eingebrachten Änderungen = globales UNDO bzw. R3-Recovery 7-44

45 Crash-Recovery: Szenarien Mögliche Zustände von Änderungen auf Pages nach einem Systemfehler: im Buffer geändert und committet, bereits persistent im Buffer geändert und noch nicht committet, bereits persistent im Buffer geändert und committet, noch nicht persistent im Buffer geändert und noch nicht committet, noch nicht persistent persistenter Log Main memory Lokaler Recovery Manager (LRM) Log Buffer Fetch, Flush Datenbank persistente Datenbank Read Write Datenbank Buffer Manager (BM) Read Write Buffer (volatile Datenbank) 7-45

46 3 Phasen des Crash-Recovery Analyse Das Log wird von Anfang bis zum Ende gelesen und ermittelt, welche Transaktionen erfolgreich beendet (committed) wurden und welche zum Fehlerzeitpunkt offen waren. Wiederholung der Historie (REDO) Es werden alle(!) protokollierten Änderungen in der Reihenfolge ihrer Ausführung in die Datenbank eingebracht. UNDO Die Änderungsoperationen der zum Fehlerzeitpunkt offenen Transaktionen werden rückgängig gemacht. 7-46

47 Das Write-Ahead-Logging-Protokoll (WAL) In Analogie zu den Werten der Datenbank wird auch der Log vom Buffer Manager im Hauptspeicher gepflegt und in einen persistenten Log dauerhaft geschrieben. Der persistente Log sollte immer vor dem Update der entsprechenden Daten auf der persistenten Datenbank geschrieben werden: Das Write-Ahead-Logging-Protokoll (WAL) Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr gehörenden Log-Einträge ausgeschrieben werden (für das REDO im Fehlerfall). Bevor eine veränderte Page in die Datenbank eingebracht wird, müssen alle diese Page betreffenden Log-Einträge ausgeschrieben werden (für das UNDO im Fehlerfall). Anmerkung: Log-Einträge werden nicht einzeln, sondern alle Log-Einträg bis zum betroffenen Eintrag sequentiell ausgeschrieben. 7-47

48 Externspeicherfehler und Media-Recovery Die Daten der materialisierten Datenbank sind zerstört oder unbrauchbar. Typische Externspeicherfehler Hardware-Fehler: Head-Crashes, Controller- Fehler etc. Naturgewalten wie Feuer oder Erdbeben Viren Behandlung (Media-Recovery) Die Datenbank muss mit Hilfe einer Sicherungskopie (Backup) wiederhergestellt werden. Danach muss der letzte transaktionskonsistente Zustand wiederhergestellt werden, d.h. alle seit der Erstellung des Backup erfolgreich beendeten Transaktionen nachvollzogen werden. persistente Datenbank Konsequenz: Die Log-Dateien müssen auf einem anderen Medium gesichert werden (z.b. anderer Rechner, Magnetband o.ä.)! 7-48

49 Media-Recovery (1) Gesicherte Daten mit Offline-Backup: Offline- Log-Datei n-4 Log-Datei n-3 Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Offline- Backup x-1 Media-Recovery Letzte Sicherungskopie der Datenbank wird eingespielt Nach der letzten Sicherung erstellte Log-Dateien werden analysiert und die Änderungen erfolgreich beendeter Transaktionen nachvollzogen (REDO) Bemerkung: Aus Performance-Gründen kann auch eine Vorgehensweise analog zur Crash-Recovery gewählt werden: komplette Historie wiederholen und danach Undo der Änderungen offener Transaktionen. Zeit Offline- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Zeit 7-49

50 Media-Recovery (2) Gesicherte Daten mit Online-Backup: Online- Log-Datei n-4 Log-Datei n-3 Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Online- Backup x-1 Media-Recovery Letzte Sicherungskopie der Datenbank wird eingespielt. Es müssen auch Log-Dateien vor dem letzten Backup betrachtet werden, da die Sicherungskopie u.u. Änderungen von später nicht erfolgreich beendeten Transaktionen enthält. Die Undo-Information dieser Transaktionen wird benötigt. Recovery zeitaufwändiger und Administration (Aufbewahren der Log- Dateien) aufwändiger. Zeit Log-Datei n-4 Log-Datei n-3 Online- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Zeit 7-50

51 Inkrementelles Backup und Crash-Recovery Bei großen Datenbanken ist eine Komplettsicherung sehr(!) zeitaufwändig. Inkrementelles Backup = Sicherung der veränderten Datenbankseiten Bei der Wiederherstellung wird das letzte Full Backup und alle danach erstellten inkrementellen Backups eingespielt, und danach nur die Log-Dateien (Annahme: offline Backup) nach dem letzten inkrementellen Backup angewandt: 7-51

52 Weitere Backup-Varianten Die bereits aufgeführten Backup-Varianten Online vs. Offline Backup Komplettes Backup vs. inkrementelles Backup können orthogonal mit weiteren Backup-Varianten kombiniert werden: Partielles Backup (Backup von Teilen der Datenbank z.b. Tablespaces) Paralleles Backup 7-52

53 Zusammenfassung Zum Verständnis des Transaktionskonzeptes sind vor allem die ACID- Eigenschaften von Transaktionen wichtig. Bei ungeschützten konkurrierenden Zugriffen können verschiedene Kategorien von Inkonsistenzen auftreten. Zur Vermeidung solcher Inkonsistenzen werden Sperrkonzepte genutzt. Die Granularität des Sperrverhaltens definiert unterschiedliche Isolationlevel. Den drei Fehlerkategorien Transaktionsfehler, Systemfehler und Mediafehler entsprechen unterschiedliche Recovery-Strategien. Zur Wiederherstellung von Daten werden Logfiles und Backups verwendet. 7-53

54 Datenbanken Einführung Semantische Datenmodellierung Relationenmodell Interne Datenorganisation SQL - Structured Query Language Prozedurale Spracherweiterungen von SQL, Stored Procedure und Trigger, JDBC Transaktionsmanagement 7-54