fbi h_da Datenbanken Kapitel 7: Transaktionsmanagement Schestag Datenbanken (Cnam) Kapitel 7-1

Transkript

1 Datenbanken Kapitel 7: Transaktionsmanagement Schestag Datenbanken (Cnam) Kapitel 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 Schestag Datenbanken (Cnam) Kapitel 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 set gehalt = gehalt * proz2 where current of c; end if; 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? Schestag Datenbanken (Cnam) Kapitel 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? Schestag Datenbanken (Cnam) Kapitel 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. Schestag Datenbanken (Cnam) Kapitel 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. Schestag Datenbanken (Cnam) Kapitel 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. Schestag Datenbanken (Cnam) Kapitel 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. Schestag Datenbanken (Cnam) Kapitel 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) Schestag Datenbanken (Cnam) Kapitel 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 Schestag Datenbanken (Cnam) Kapitel 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]; Schestag Datenbanken (Cnam) Kapitel 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); Schestag Datenbanken (Cnam) Kapitel 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; Schestag Datenbanken (Cnam) Kapitel 7-13

14 Transaktionsmanagement Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien Schestag Datenbanken (Cnam) Kapitel 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 LH 4225 T2: read x=100 AnzahlFreieSitzplätze 100 ( 99 ) 98 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? Schestag Datenbanken (Cnam) Kapitel 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 LH 4225 AnzahlFreieSitzplätze 100 ( ) 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? Schestag Datenbanken (Cnam) Kapitel 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 zwischen diesen beiden lesenden Zugriffen den Wert: Flugnr LH 4225 AnzahlFreieSitzplätze 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; Zeit Innerhalb der selben Transaktion wurden für ein Feld, das von dieser Transaktion nicht verändert wurde(!), unterschiedliche Werte gelesen. Schestag Datenbanken (Cnam) Kapitel 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: Zeit T1: count = 0 T1: read LH 4225: count = 1 T1: read KL 1775: count = 1 T1: read BA 914: count = 2 ( 3) Flugnr LH 4225 AF 1018 KL 1775 BA 914 AnzahlFreieSitzplätze T2: insert into... values ('AF 1018',150,...); Schestag Datenbanken (Cnam) Kapitel

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. Schestag Datenbanken (Cnam) Kapitel 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 Schestag Datenbanken (Cnam) Kapitel 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). Schestag Datenbanken (Cnam) Kapitel 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. Schestag Datenbanken (Cnam) Kapitel 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 Isolation Level (SQL 92) Nonrepeatable Read Phantom Read 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 Serializable nicht möglich nicht möglich nicht möglich Schestag Datenbanken (Cnam) Kapitel 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 Schestag Datenbanken (Cnam) Kapitel 7-24

25 Isolationlevel bei Oracle DB2 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; Durch eine Multiversionen-Synchronisation (multiversion concurrency control, MVCC) ist es in Oracle IMMER möglich, auf den zuletzt committeten Zustand eines Datenobjektes zuzugreifen vgl. auch Praktikum 6! MVCC ist ebenfalls in PostgreSQL implementiert. Schestag Datenbanken (Cnam) Kapitel 7-25

26 Transaktionsmanagement Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement Wiederherstellung der Daten (Recovery) und Backupstragien Schestag Datenbanken (Cnam) Kapitel 7-26

27 JDBC und Transaktionsmanagement Isolation Level und JDBC Der Isolation Level kann für eine Connection explizit gesetzt werden. Unterstützt ein Treiber den in der Methode settransactionisolation(level) übergebenen Level nicht, so darf er eine restriktivere Ebene verwenden. Unterstützt er keine restriktivere Ebene, so wird eine Ausnahme vom Typ SQLException erzeugt. Isolation Level sollten nie innerhalb einer Transaktion, sondern stets nur zwischen zwei Transaktionen geändert werden. void void settransactionisolation(int level) level) throws throws SQLException; 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); Schestag Datenbanken (Cnam) Kapitel 7-27

28 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. Schestag Datenbanken (Cnam) Kapitel 7-28

29 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 Schestag Datenbanken (Cnam) Kapitel 7-29

30 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. Schestag Datenbanken (Cnam) Kapitel 7-30

31 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. Schestag Datenbanken (Cnam) Kapitel 7-31