Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 1 Worzyk FH Anhalt Transaktionen und Parallelverarbeitung Eigenschaften von Transaktionen Konsistenz Isolation Parallelverarbeitung Sperrkonzepte Deadlock Beispiele

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 2 Worzyk FH Anhalt Zugriffsteuerung Konto BaFöG Sachbearbeiter 1 Miete Sachbearbeiter

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 3 Worzyk FH Anhalt Zugriffsteuerung Konto BaFöG Sachbearbeiter 1 Miete Sachbearbeiter

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 4 Worzyk FH Anhalt Konsistenzsicherung Konto 1Konto Überweise 500 von Konto 1 nach Konto 2 Konto Konto

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 5 Worzyk FH Anhalt Konsistenzsicherung Konto 1Konto Überweise 500 von Konto 1 nach Konto 2 Konto

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 6 Worzyk FH Anhalt Konsistenzsicherung Konto 1Konto Überweise 500 von Konto 1 nach Konto 2 Konto Konto alt Transaktion

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 7 Worzyk FH Anhalt Eigenschaften von Transaktionen Konsistenz Dauerhaftigkeit Unteilbarkeit Isolation

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 8 Worzyk FH Anhalt Konsistenz Jede Transaktion erhält die Konsistenz der Datenbasis aufrecht. Sämtliche Zustandsbedingungen gelten vor und nach Beendigung der Transaktion. Transaktionen stellen die Klammer dar, um Folgen von Datenbankoperationen zu konsistenzerhaltenden Zustandsübergängen zusammenzufassen.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 9 Worzyk FH Anhalt Dauerhaftigkeit Korrekt beendete Transaktionen wirken sich dauerhaft auf die Daten aus. Ihre Wirkung kann nicht durch Systemfehler nachträglich zerstört werden.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 10 Worzyk FH Anhalt Unteilbarkeit Eine Transaktion ist eine unteilbare Operation. Sie wird entweder vollständig durch geführt oder bleibt ohne Wirkung.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 11 Worzyk FH Anhalt Isolation Parallel ablaufende Transaktionen sind voneinander isoliert, so daß jede Transaktion unabhängig von den anderen zurückgesetzt werden kann.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 12 Worzyk FH Anhalt Konsistenz im DBMS alle Gesetzmäßigkeiten, die dem DBMS bekannt gemacht sind, werden auf dem jeweils aktuellen Datenbestand eingehalten Eine Datenbank ist vollständig konsistent, wenn sie ein isomorphes Abbild der Umwelt ist.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 13 Worzyk FH Anhalt Lang andauernde Transaktionen Normale Transaktionen in einem DBMS dauern einige Sekunden Transaktionen in Entwurfsdatenbanken können mehrere Tage dauern –CAD –CASE Tools Im Workflow Management wird Rollback häufig durch inverse Transaktionen ersetzt.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 14 Worzyk FH Anhalt Teilaufgaben zur Konsistenzsicherung Konsistenzbeschreibung Konsistenzüberwachung Konsistenzerhaltung Konsistenzerzeugung

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 15 Worzyk FH Anhalt Anfang und Ende einer Transaktion Eine Transaktion beginnt mit der ersten ausführbaren SQL-Anweisung Eine Transaktion endet mit –COMMT oder ROLLBACK –einer DDL-Anweisung z.B.: CREATE TABLE DROP TABLE –Der Benutzer meldet sich ab –Der Prozess bricht ab

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 16 Worzyk FH Anhalt Beispiel commit; insert into ta_kunde values(88,'Anna'); update ta_angebot set kunden#=88 where kunden#=13; update ta_auftrag set kunden#=88 where kunden#=13; delete from ta_kunde where kunden#=13; commit;

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 17 Worzyk FH Anhalt Savepoints Savepoints können gesetzt werden, um Teilergebnisse einer Transaktion zu kennzeichnen. Es kann dann ein Rollback bis zu einem Savepoint vorgenommen werden.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 18 Worzyk FH Anhalt Unteilbarkeit Dauerhaftigkeit Umbuchung eines Betrages von einem Konto auf ein anderes. UPDATE ta_konto SET Kontostand = Kontostand - Betrag WHERE Konto# = VonKonto UPDTE ta_konto SET Kontostand = Kontostand + Betrag WHERE Konto# = NachKonto

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 19 Worzyk FH Anhalt Ablauf - Ändern Die alten Daten (vor der Veränderung) werden gespeichert. Die Transaktion bekommt eine System Change Number SCN zugeordnet. Die Veränderungsbefehle werden protokolliert. Die Veränderungen werden durchgeführt in die Datenbank übernommen.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 20 Worzyk FH Anhalt Ablauf - Commit Die interne Transaktionstabelle zeichnet auf, daß die Transaktion festgeschrieben ist und zeichnet die SCN auf. Dier Änderungsvorschrift wird archiviert Die Sperren auf Zeilen und Tabellen werden freigegben. Die Transaktion wird als beendet gekennzeichnet.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 21 Worzyk FH Anhalt Ablauf - Rollback Alle Änderungen, die von der SQL- Anweisung vorgenommen wurden, werden mit Hilfe gespeicherten Daten rückgängig gemacht. Die Sperren auf Zeilen und Tabellen werden frei gegben. Die Transaktion wird als beendet gekennzeichnet.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 22 Worzyk FH Anhalt Isolation gegenseitige Beeinflusung Lost Update (verlorengegeangene Aktualisierung) Dirty Read (Lesen von nicht festgeschriebenen Daten) Non Repeatable Read (Nichtwiederholbares Lesen) Phantoms (Inkonsistentes Lesen) DDL-Operationen

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 23 Worzyk FH Anhalt Lost Update

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 24 Worzyk FH Anhalt Dirty Read

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 25 Worzyk FH Anhalt Non Repeatable Read

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 26 Worzyk FH Anhalt Phantoms

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 27 Worzyk FH Anhalt DDL - Operationen

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 28 Worzyk FH Anhalt Konsistenzerhaltung von ORACLE automatisch Lesekonsistenz auf Anweisungsebene (Phantoms) ORACLE beobachtet die SCN (System Change Number) und zur Zeit der Ausführung der Abfrage werden nur die Daten, die mit der gleichen SCN gekennzeichnet sind, berücksichtigt

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 29 Worzyk FH Anhalt SCN

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 30 Worzyk FH Anhalt Sperrkonzepte von ORACLE Automatische Sperren –Tabellensperre mit Zeilensperre im Exclusiv-Modus –Tabellensperre mit Zeilensperre im Share- Modus Programmierbare Sperren –Tabellensperre im Share-Modus –Tabellensperre im Exclusiv-Modus

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 31 Worzyk FH Anhalt Tabellensperren * Wenn die Spalten nicht betroffen sind

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 32 Worzyk FH Anhalt Deadlock (Systemverklemmung) Ein Deadlock tritt auf, wenn mehrere Transaktionen gegenseitig auf die Freigabe von Ressourcen warten, sie die Ressourcen aber nicht freigeben können, da sie diese für den Abschluß ihrer Arbeit benötigen.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 33 Worzyk FH Anhalt Deadlock

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 34 Worzyk FH Anhalt Deadlock Beispiel

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 35 Worzyk FH Anhalt Reduzieren von (Dead)lock- Situationen Transaktionen so kurz wie möglich. Keine Bildschirmaktionen innerhalb einer Transaktion. Bei Mehrtabellen-Update (z.B.: Master- Detail-Tabellen) muß eine für alle Anwendungen und alle Programmierer verbindliche Reihenfolge der Zugriffe und der Sperrungen festgelegt werden.

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 36 Worzyk FH Anhalt Zusammenfassung 1 Eine Transaktion T überführt die Datenbank von einem konsisten Zustand K1 in einen konsisten Zustand K2. Ist das nicht möglich, wird der Zustand K1 wieder hergestellt (Rollback).

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 37 Worzyk FH Anhalt Zusammenfassung 2 Eigenschaften von Transaktionen –Konsistenz –Dauerhaftigkeit –Atomizität –Isolation Gegenseitige Beeinflussung –Lost Update –Dirty Read –Non Repeatable Read –Phantoms

Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 38 Worzyk FH Anhalt Zusammenfassung 3 Deadlocks können reduziert werden durch –Kurze Transaktionen –Keine Bildschirmeingabe innerhalb –Mehrtabellen Update immer in der gleichen Reihenfolge Das Ende einer Transaktion wird vom Programmierer bestimmt