Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für Notwendigkeit von Transaktionen INSERT INTO auftrag (aufnr,

Ähnliche Präsentationen


Präsentation zum Thema: "Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für Notwendigkeit von Transaktionen INSERT INTO auftrag (aufnr,"—  Präsentation transkript:

1 Dr. Heidrun BethgeDatenbanken II1 Transaktionen

2 Dr. Heidrun BethgeDatenbanken II2 Bsp. für Notwendigkeit von Transaktionen INSERT INTO auftrag (aufnr, kundennr) VALUES (111,333); INSERT INTO auftragdetails (aufnr, artikelnr, anzahl) VALUES (111,3456,4); UPDATE artikel SET anzahl_auf_lager=234 WHERE artikelnr=3456;

3 Dr. Heidrun BethgeDatenbanken II3 Was ist eine Transaktion? Eine Transaktion ist eine ununterbrechbare Folge von DML- Befehlen, welche die Datenbank von einem logisch konsistenten Zustand in einen neuen logisch konsistenten Zustand überführt. Die Datenbank braucht nur vor und nach einer Transaktion in einem zulässigen Zustand zu sein.

4 Dr. Heidrun BethgeDatenbanken II4 ACID-Prinzip Atomicity: Atomarität. Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Consistency: Konsistenz. Transaktionen sind die Einheiten der Integritätsüberwachung. Nach einer Transaktion müssen alle Integritätsbedingungen erfüllt sein. Isolation: Parallel laufende Transaktionen sind isoliert und können sich nicht gegenseitig be- einflussen. Ein Nutzer sollte immer den Eindruck haben, dass er allein mit der DB arbeitet. Durability: Dauerhaftigkeit. Sobald eine Transaktion ihre Änderungen freigegeben hat, muss das System das Überleben dieser Änderungen trotz beliebiger (erwarteter) Fehler garantieren (Persistenz).

5 Dr. Heidrun BethgeDatenbanken II5 Transaktionsbefehle BEGIN / BOT (Begin of Transaction): Beginn einer Transaktion. Wird von einigen DBMS implizit gesetzt. COMMIT / EOT (End of Transaction): Die Transaktion soll erfolgreich beendet werden. ROLLBACK / ABORT: Die Transaktion wird abgebrochen. Alle bereits in ihr durchgeführten Aktionen werden rückgängig gemacht.

6 Ende der Transaktion Für das Ende einer Transaktion gibt es nur zwei Möglichkeiten: COMMIT; Erfolgreich beendet. ROLLBACK; Nicht erfolgreich beendet. Dr. Heidrun BethgeDatenbanken II6

7 Dr. Heidrun BethgeDatenbanken II7 Abschluss von Transaktionen Der User setzt ein COMMIT oder ROLLBACK selbst ab. Vor und nach jedem DDL-Befehl wie z.B. CREATE, ALTER, DROP, RENAME wird vom DBMS ein implizites COMMIT abgesetzt. Hardware- oder Laufzeitfehler können zu einem Rollback führen. Das DBMS kann Transaktionen zurückrollen, wenn sie z.B. bei Beendigung Konsistenzbedingungen verletzen oder in ein Deadlock laufen. wird eine neue Transaktion eingeleitet, während eine andere noch offen ist, so wird die offene Transaktion automatisch durch COMMIT abgeschlossen.

8 Dr. Heidrun BethgeDatenbanken II8 Automatische Sperren bei Transaktionen Ist eine Transaktion aktiv, kann eine andere Transaktion keine Operationen durchführen, die Datensätze der aktiven Transaktion betreffen. Dies gilt, sofern auf diesen Datensätzen von der offenen Transaktion bereits geschrieben wurde. Diese Kommandos werden blockiert. Jedoch: Standard-Sperrlevel von DBMS erfüllen NICHT vollständig das ACID- Prinzip! → Sperren von Hand setzen.

9 Dr. Heidrun BethgeDatenbanken II9 Transaktion 1Transaktion 2 select * from testdaten; update testdaten set wert=11 where id=1;select * from testdaten; update testdaten set wert = 22 where id=1; commit; select * from testdaten; rollback;select * from testdaten; Beispiel Transaktion

10 Dr. Heidrun BethgeDatenbanken II10 Transaktionen im Mehrbenutzerbetrieb Fehler durch gleichzeitigen Zugriff mehrerer Benutzer auf dieselben Daten mehrere Transaktionen laufen parallel und behindern sich ggf. gegenseitig → nebenläufige konkurrierende Prozesse

11 Dr. Heidrun BethgeDatenbanken II11 Inkonsistentes Lesen: Nonrepeatable Read X = A + B +C am Ende der Transaktion T1 Integritätsbedingung A + B + C = 0

12 Lesen inkonsistenter Zustände Integritätsbedingung X + Y = 0 Dr. Heidrun BethgeDatenbanken II12 T1T2 read(X,x); read(Y,y); x=x+1; write(X,x); y=y-1; read(X); read(Y); write(Y,y); commit;

13 Dr. Heidrun BethgeDatenbanken II13 Dirty Read Lesen nicht freigegebener, ungültiger Daten

14 Dr. Heidrun BethgeDatenbanken II14 Verlorengegangenes Ändern: Lost Update

15 Dr. Heidrun BethgeDatenbanken II15 Mehrbenutzer-Anomalie Integritätsbedingung A = B

16 Dr. Heidrun BethgeDatenbanken II16 Das Phantom-Problem

17 Dr. Heidrun BethgeDatenbanken II17 Probleme bei Cursor- Referenzen

18 Transaktions-Sperrlevel in SQL Sperrlevel der nächsten Transaktion: set transaction [read only, |read write,] [isolation level read uncommitted, | read committed,| repeatable read,| serializable] Sperrlevel innerhalb dieser Session: alter session set isolation_level serializable;

19 Sperrlevel read uncommitted Erlaubt Lesen nicht committeter Daten. Read only. read committed Erlaubt nur Lesen von committeten Daten. Non Repeatable Read-Problem besteht. repeatable read Non Repeatable Read-Problem behoben, jedoch Phantom-Problem nicht. serializable Stärkste Stufe, garantiert Serialisierbarkeit. ACID-Prinzip wird erfüllt. Dr. Heidrun BethgeDatenbanken II19

20 Auswirkungen der Isolationsstufen Leveldirty readnon repeatable read / lost update Phantomproblem read uncommitted ist möglich read committed neinist möglich repeatable read nein ist möglich serializablenein

21 Dr. Heidrun BethgeDatenbanken II21 Sperren shared lock: read lock (S) exclusive lock: write lock (X) Kompatibilitätsmatrix XS- XNNJ SNJJ -JJJ von T1 gehaltene Sperre von T2 geplante Sperre

22 Dr. Heidrun BethgeDatenbanken II22 Regeln für Sperren Eine Transaktion, welche einen Datensatz lesen will, muss diesen zunächst mit einem S- oder X-Lock versehen. Eine Transaktion, welche einen Datensatz ändern will, muss diesen zunächst mit einem X-Lock versehen. Ein S-Lock kann durch die gleiche Transaktion durch ein X-Lock erweitert werden. Liegt auf einem Objekt ein X-Lock, kann durch die gleiche Transaktion kein S-Lock auf dieses Objekt gesetzt werden. Wird einer Transaktion A eine Sperre verweigert, da bereits anderweitig eine Sperre besteht, so geht A in Wartestellung (Wartezeit ist begrenzt). Sperren werden in der Regel bis zum Ende der Transaktion gehalten. COMMIT löst alle bestehenden Sperren.

23 Dr. Heidrun BethgeDatenbanken II23 Sperren in DBMS X-Lock wird vom DBMS automatisch beim Schreiben auf die zu ändernden Datensätze gesetzt. SELECT setzt keine Sperren. SELECT... FOR UPDATE versieht die Ergebnisdatensätze mit einem X-Lock und den Rest der Tabelle mit einem S-Lock. Lesezugriffe sind auch dann möglich wenn auf den Daten ein S- oder X-Lock liegt. LOCK TABLE tabelle IN SHARE MODE LOCK TABLE tabelle IN EXCLUSIVE MODE Datenbanksysteme unterscheiden in der Praxis noch weitere Sperrtypen.

24 Dr. Heidrun BethgeDatenbanken II24 Beispiel Sperren I T1T2 write(A) read(A) rollback T1T2 X-Lock A write(A) Anfrage: S-Lock A (read(A)) waitrollback (löst X-Lock(A)) resume: S-Lock(A) read(A) Dirty Read

25 Dr. Heidrun BethgeDatenbanken II25 Beispiel Sperren II T1T2 read(A) read(B) write(B) write(A) T1T2 S-Lock(A) read(A) S-Lock(B) read(B) X-Lock(B) (write(B)) waitX-Lock(A) (write(A)) wait vorher: lost update nachher: deadlock -> eine der beiden Transaktionen bekommt rollback „deadlock victim“

26 Dr. Heidrun BethgeDatenbanken II26 DEADLOCKS Deadlocks sind Fälle, in denen sich zwei oder mehr Prozesse gegenseitig blockieren und jeder auf das Ende der Transaktion eines anderen Prozesses wartet. Das DBMS erkennt automatisch Deadlock-Situationen und führt bei dem Prozess, der den Deadlock ausgelöst hat, ein ROLLBACK aus. (Oracle: nur der letzte Transaktionsschritt wird rückgängig gemacht)

27 Dr. Heidrun BethgeDatenbanken II27 Beispiel DEADLOCK Transaktion 1Transaktion2 sperrt Asperrt B versucht B zu sperrenversucht A zu sperrenbegin; select * from testdaten where id=1 where id=2for update of wert; update testdaten set wert=100 set wert=50 where id=2;where id=1;


Herunterladen ppt "Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für Notwendigkeit von Transaktionen INSERT INTO auftrag (aufnr,"

Ähnliche Präsentationen


Google-Anzeigen