Transaktionen und Parallelverarbeitung
Werbung
Transaktionen und Parallelverarbeitung • • • • • • • Eigenschaften von Transaktionen Konsistenz Isolation Parallelverarbeitung Sperrkonzepte Deadlock Beispiele Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 1 . 1 Zugriffsteuerung BaFöG + 400 Sachbearbeiter 1 500 + 400 900 Konto 500 900 300 Miete - 200 Sachbearbeiter 2 500 - 200 300 900 300 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 2 2 Zugriffsteuerung BaFöG + 400 Sachbearbeiter 1 500 + 400 900 Konto 500 900 700 Miete - 200 Sachbearbeiter 2 900 - 200 700 900 700 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 3 3 Konsistenzsicherung Konto 1 700 200 Überweise 500 von Konto 1 nach Konto 2 -500 Konto 1 -500 Konto 2 +500 Worzyk HS Anhalt Konto 2 300 800 +500 Medienarchive Sommer 2007 Transaktionen - 4 4 Konsistenzsicherung Konto 1 Worzyk HS Anhalt 700 200 Überweise 500 von Konto 1 nach Konto 2 -500 Konto 1 -500 Konto 2 300 Medienarchive Sommer 2007 Transaktionen - 5 5 Konsistenzsicherung alt 700 Konto 1 700 200 Überweise 500 von Konto 1 nach Konto 2 -500 Konto 1 -500 Konto 2 +500 Konto 2 300 800 alt 300 +500 Transaktion Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 6 6 Eigenschaften von Transaktionen • Konsistenz • Dauerhaftigkeit • Unteilbarkeit • Isolation Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 7 Eine Transaktion im Sinn einer Datenbank ist eine Folge von zusammenhängenden Datenbankänderungen. Das Datenbanksystem sorgt dafür, dass entweder alle oder keine Änderung der Folge durchgeführt werden. Es wird keine formale Definition einer Transaktion gegeben, sondern es werden die Eigenschaften von Transaktionen angegeben. 7 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. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 8 Es gibt Zustandsbedingungen, die die referentielle Integrität beschreiben. Diese Bedingungen werden bei jeder einzelnen Datenbankänderung geprüft und bei einem Widerspruch wird die Änderung zurückgewiesen. Weiterhin gibt es umfassendere Zustandsbedingungen, die durch eine Folge von Datenbankänderungen realisiert werden. Diese Transaktionen werden vom Anwendungsprogrammierer definiert und bilden die Geschäftsregeln der Anwendung ab. Ein Beispiel einer solchen Geschäftsregel ist die Vorschrift, dass die Summe aller Kontostände konstant sein soll. Sie kann realisiert werden, indem zu jeder Buchung auf ein Konto eine Abbuchung von einem anderen Konto gehört. 8 Konsistenz Kunde Ein Angebot gehört genau zu 1 Kunden Ein Auftrag gehört genau zu 1 Kunden Ein Kunde hat n Angebote Angebot Ein Kunde hat 0 bis n Aufträge Auftrag 0 bis 1 Angebote können 0 bis 1 Aufträge haben Weitere Regeln: Wenn ein Kunde gelöscht wird, werden automatisch alle seine Angebote gelöscht Ein Kunde kann nicht gelöscht werden, wenn ein Angebot für ihn existiert Wenn zu einem Angebot ein Auftrag gehört, kann das Angebot nicht mehr geändert werden Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 9 9 Beispiel 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; Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 10 Die Kundin Anna hat die Kundennummer 13. Sie hat einige Angebote bekommen und einige Aufträge erteilt. Jetzt möchte die Kundin Anna ihre Kundennummer von 13 nach 88 ändern. Dafür müssen auch in allen ihren Angeboten und in ihren Aufträgen die Kundennummer 13 nach 88 geändert werden. Ein einfacher Änderungsbefehl, der in der Kundentabelle die 13 in die 88 ändert funktioniert nicht, weil es dann kurzfristig Angebote und Aufträge mit der Kundennummer 13 gibt, zu denen keine Kundennummer existiert. Andererseits können die Tabellen Angebot oder Auftrag auch nicht zuerst geändert werden, weil dann Angebote oder Aufträge mit einer Kundennummer existieren, zu der kein Kunde vorhanden ist. Also: Zuerst einen neuen Kunden mit der Nummer 88 anlegen und ihn Anna nennen. Dann Angebote und Aufträge zu Kunde 13 dem Kunden 88 zuordnen. Dann den Kunden mit der Nummer 13 löschen 10 Dauerhaftigkeit Korrekt beendete Transaktionen wirken sich dauerhaft auf die Daten aus. Ihre Wirkung kann nicht durch Systemfehler nachträglich zerstört werden. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 11 Weder durch eine gewollte noch ungewollte Beendigung eines Anwendungsprogramms oder des DBMS geht die Änderung verloren. Das DBMS bietet auch die Möglichkeit, Daten, die durch einen Plattenfehler verloren gegangen sind, zu rekonstruieren. 11 Unteilbarkeit Eine Transaktion ist eine unteilbare Operation. Sie wird entweder vollständig durch geführt oder bleibt ohne Wirkung. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 12 Die Unteilbarkeit kann Probleme bei lang andauernden Transaktionen bringen, wenn die Ressourcen während einer Transaktion für andere Benutzer gesperrt sind.. Selbstgebastelte Sperren zur Aufrechterhaltung von unteilbaren Transaktionen sind in der Regel fehleranfällig und wartungsintensiv (Datenübertragung, Replikation,...) Ein Programm zur täglichen Replikation von Datenbeständen in autonome Filialen hat ca. 3 MJ benötigt. Beispiel: in einer Versicherung war der unteilbare und isolierte Vorgang die Bearbeitung eines Kunden (ein Kunde konnte nur gleichzeitig von einem Sachbearbeiter bearbeite werden). Dieses Verfahren gab Probleme bei Großkunden mit einer großen Anzahl von Schadensfällen: Autoversicherung und Hagelkatastrophe in München ca. 1985; es gab Großkunden mit mehreren hundert zerstörte Autos, die einzeln nacheinander bearbeitet werden mussten. 12 Isolation Parallel ablaufende Transaktionen sind voneinander isoliert, so daß jede Transaktion unabhängig von den anderen zurückgesetzt werden kann. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 13 In kommerziellen DBMS gibt es keine echte Parallelität von Programmabläufen. Parallel ablaufende Transaktionen laufen intern verschachtelt nacheinander ab. Sie beeinflussen sich nicht durch ihre Ergebnisse, können sich aber gegenseitig behindern. 13 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. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 14 CAD: Eine Zeichnung wird geladen, lokal bearbeitet und dann wieder zentral gespeichert und muß eventuell zu bereits vorhandenen Zeichnungen passen (Anschlußzeichnungen, Details) CASE Tools: z.B parallele erstellung von ERD‘s. Das CASE toolTeamwork erlaubt parallele Bearbeitung (Strukturierte Analyse, Strukturiertes Design und ERD‘s); Eine frühe Version von ERWIN (ERD‘S unter Windows) benötigte mehrere Stunden zum Zusammenbringen von Teilmodellen (ERD: prüfen auf Fremdschlüssel). Der Begriff einer Transaktion als eine Folge von zusammenhängenden Teilaufgaben wird auch im Workflow Management benutzt. Hier ist ein Zurücksetzen oft nicht möglich, eine fehlerhafte Transaktion muß durch eine inverse Transaktion rückgängig gemacht werden. Beispiel Auftragsabwicklung: Die aufeinanderfolgenden Teilaufgaben sind: Kundennachfrage, Angebot, Auftrag, Lieferung. Wenn ein falsches Angebot verschickt wird, kann dieser Vorgang nicht rückgängig gemacht werden, es muß ein korrigiertes Angebot verschickt werden. 14 Teilaufgaben zur Konsistenzsicherung • Konsistenzbeschreibung • Konsistenzüberwachung • Konsistenzerhaltung • Konsistenzerzeugung Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 15 Konsistenzbeschreibung: Die Regeln, die besagen, ob ein Datenbestand konsistent ist, können der zugehörenden Datenbank bekannt gegeben werden oder sind in Datenbanken für Spezialanwendungen fest programmiert. Konsistenzüberwachung: Die Regeln zur Konsistenzbeschreibung werden regelmäßig oder auf Anforderung überprüft. Bei entdeckten Inkonsistenzen werden entweder automatisch oder nach einem Hinweis durch den Anwender Programme zur Konsistenzerhaltung oder Konsistenzerzeugung aufgerufen. Programme zur Konsistenzüberwachung werden automatisch beim Starten des DBMS aufgerufen und sie überprüfen, ob das DBMS ordnungsgemäß beendet wurde. Konsistenzerhaltung: Programme, die nach vorgegebenen Regeln entdeckte Inkonsistenzen beheben. Konsistenzerzeugung: Die Maßnahmen, die dazu dienen, aus einem inkonsistenten Zustand wieder einen konsistenten Zustand zu erzeugen. Dieser Zustandsübergang kann automatisch oder halbautomatisch in Zusammenarbeit mit dem Benutzer erfolgen, er kann vom System oder vom Benutzer angestoßen werden. ORACLE läßt inkonsistente Zustände im Zusammenhang mit verteilten Datenbanken zu. Inkonsistente Zustände, die durch einen Abbruch des DBMS verursacht wurden, werden automatisch beim Neustart des DBMS behoben. 15 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 – Dem Abmelden des Benutzers – Dem Abbruch des Prozesses Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 16 Eine Transaktion beginnt mit der ersten ausführbaren SQL-Anweisung •nach dem Anmelden an die Datenbank •nach einem Commit oder einem Rollback. Eine Transaktion endet mit •COMMT: die vorangegangenen SQL-Befehle werden festgeschrieben und können nicht automatisch rückgängig gemacht werden. •ROLLBACK: die vorangegangenen SQL-Befehle werden rückgängig gemacht und die Datenbank hat den Stand vor Beginn der Transaktion. •einer DDL-Anweisung z.B.: •CREATE TABLE •DROP TABLE Die DDL-Anweisung bewirkt ein implizites COMMIT vor und nach der Anweisung. •Der Benutzer meldet sich ab: Es wird ein implizites COMMIT ausgelöst.. •Der Prozess bricht ab: Es wird ein implizites ROLLBACK ausgelöst. 16 Savepoints • Savepoints können gesetzt werden, um Teilergebnisse einer Transaktion zu kennzeichnen. Es kann dann ein Rollback bis zu einem Savepoint vorgenommen werden. A n fa n g Worzyk HS Anhalt S a v e p o in t R o llb a c k (S a v e p o in t) Medienarchive Sommer 2007 Transaktionen - 17 Savepoints können gesetzt werden, um Teilergebnisse einer Transaktion zu kennzeichnen. Es kann dann ein Rollback bis zu einem Savepoint vorgenommen werden. Ein sinnvoller Einsatz für den Einsatz von Savepoints könnte gegeben ein, wenn die Konsistenzüberprüfung zeitaufwendig ist und die Konsistenzverletzung die seltene Ausnahme ist. Dann kann die Ausführung der Anweisung und die seltene Zurücksetzung bis zum Savepoint effektiv sein. 17 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 und in die Datenbank übernommen. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 18 18 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. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 19 19 Ablauf - Rollback • Alle Änderungen, die von der SQLAnweisung vorgenommen wurden, werden mit Hilfe gespeicherten Daten rückgängig gemacht. • Die Sperren auf Zeilen und Tabellen werden frei gegeben. • Die Transaktion wird als beendet gekennzeichnet. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 20 20 RECO PMONArchitektur SMON Oracle Änderungsprotokoll System Global Area PGA Shared update... SQL Pool Server update... Prozess Benutzer SQL-Befehl Prozess update... Worzyk HS Anhalt Daten Puffer Änderung Daten Cache alte DBWR Daten Roll back Segm neue CKPT Daten Daten bank Dateien Redo Log Puffer LGWR Steuer dateien Archiv Redo Log ARCH Online Redo Log Medienarchive Sommer 2007 Transaktionen - 21 21 Isolation gegenseitige Beeinflussung • Lost Update (verlorengegangene Aktualisierung) • Dirty Read (Lesen von nicht festgeschriebenen Daten) • Non Repeatable Read (Nichtwiederholbares Lesen) • Phantoms (Inkonsistentes Lesen) • DDL-Operationen Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 22 Parallel ablaufende Transaktionen werden normalerweise voneinander isoliert, so dass sie sich nicht gegenseitig beeinflussen können. Es gibt aber genügend Möglichkeiten, diese Mechanismen außer Kraft zu setzen und durch fehlerhafte Programme zu umgehen. Die häufigsten Fehler sind: 22 Lost Update Transaktion Zeit Transaktion T2 SELECT x FROM ta_tab WHERE x = 2 xneu = x + 7 t1 UPDATE ta_tab SET x = xneu WHERE x = 2 t3 SELECT x FROM ta_tab WHERE x = 2 COMMIT WORK t4 xneu = 2 * x t5 UPDATE ta_tab SET x = xneu WHERE x = 2 t6 COMMIT WORK Worzyk HS Anhalt t2 Medienarchive Sommer 2007 Transaktionen - 23 Lost update: Beide Transaktionen lesen und ändern die gleichen Daten. Dann überschreibt die spätere Transaktion die geänderten Werte der früheren Transaktion. t3: der alte Wert ist noch bekannt Der von der Transaktion T1 berechnete Wert für x wird von der Transaktion T2 überschrieben. 23 Dirty Read Tranaktion T1 Zeit SELECT x FROM ta_tab WHERE x = 2 t1 xneu = x + 7 t2 UPDATE ta_tab SET x = xneu WHERE x = 2 t3 SELECT x FROM ta_tab WHERE x = 9 ROLLBACK WORK t4 xneu = 2 * x t5 UPDATE ta_tab SET x = xneu WHERE x = 9 t6 COMMTI WORK Worzyk HS Anhalt Transaktion T2 Medienarchive Sommer 2007 Transaktionen - 24 Die TransaktionT1 ändert Daten. Die Transaktion T2 übernimmt die neuen Daten und arbeitet damit weiter. In der Zwischenzeit führt T1 ein ROLLBACK durch und stellt den alten Zustand wieder her. T2 arbeit also mit Daten, die es nie gegeben hat. t3: der neue Wert ist schon bekannt. Die Transaktion T2 liest Daten der Transaktion T1, die noch nicht freigegeben sind. T1 setzt dann die Änderungen zurück. 24 Non Repeatable Read Tranaktion T1 Zeit SELECT x FROM ta_tab WHERE x = 2 t1 IF bedingung ... t2 SELECT x FROM ta_tab WHERE x = 2 t3 xneu = x + 7 t4 UPDATE ta_tab SET x = xneu WHERE x = 2 t5 Transaktion T2 UPDATE ta_tab SET x = x * 2 COMMIT WORK t6 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 25 T1 liest Daten in einen Speicher und erstellt an Hand der Dateninhalte eine Verarbeitungsstrategie. T2 ändert die Daten in der Datenbank, aber die Änderungen wirken sich nicht auf den internen Speicher von T1 aus. T1 bearbeitet dadurch die falschen Daten nach der zuvor bestimmten Strategie. t3: gleiche Bedingung aber unterschiedliche Ergebnismengen Die Transaktion T1 liest Daten und auf Grund einer Bedingung möchte sie diese Daten nach einem erneuten Lesen bearbeiten. In der Zwischenzeit hat Transaktion T2 den Datanbestand geändert, so daß das erneute Lesen von T1 eine andere Datenmenge ergibt. 25 Phantoms Tranaktion T1 SELECT SUM(x) FROM ta_tab WHERE x > 0 Worzyk HS Anhalt Zeit Transaktion T2 t1 UPDATE ta_tab SET x = -x t2 Medienarchive Sommer 2007 Transaktionen - 26 Während Transaktion T1 die Summe bildet, verändert T2 die Ergebnismenge von T1. Beispiel: Bestandsaufnahme eines Lagers, gleichzeitig werden die Bestände geändert. Diese Art der Inkonsistenzen kann durchaus gewollt sein: Die Transaktion T1 kann unter Umständen sehr lange dauern. Während dieser Zeit können die Daten nicht geändert werden. Wenn das Ergebnis von T1 nur annähernd richtig sein muß, um vielleicht eine Entscheidungshilfe zu bieten, ist es vertretbar, die Transaktion T2 parallel laufen zu lassen. 26 DDL - Operationen Worzyk HS Anhalt Tranaktion T1 Zeit SELECT x FROM ta_tab WHERE x = 2 t1 xneu = x + 7 t2 UPDATE ta_tab SET x = xneu WHERE x = 2 t3 COMMTI WORK t4 Transaktion T2 DROP TABLE ta_tab Medienarchive Sommer 2007 Transaktionen - 27 Während Transaktion T1 eine Tabelle bearbeitet, wird diese Tabelle von T2 gelöscht. Ein solcher Vorgang ist möglich, wenn zur Erzeugung von Zwischenergebnissen Tabellen temporär angelegt werden und nach Erreichen des Endergebnisses wieder gelöscht werden. Wenn dann der Tabellenname nicht eindeutig an die Transaktion geknüpft ist, kann die parallel laufende Transaktion T2 die Tabelle von T1 zerstören. 27 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 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 28 ORACLE ermöglicht automatisch Lesekonsistenz auf Anweisungsebene (Phantoms): Es wird gewährleistet, daß eine einzelne Abfrage hinsichtlich des Abfragebeginns konsistent ist. Zur Herstellung der Lesekonsistenz beobachtet ORACLE 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. 28 SCN SELECT SCN 10023 Datenblöcke der Rollback Segmente SCN 10023 SCN 10024 SCN 10023 SCN 10023 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 29 29 Sperrkonzepte von ORACLE • Automatische Sperren – Tabellensperre mit Zeilensperre im Exclusiv-Modus – Tabellensperre mit Zeilensperre im ShareModus • Programmierbare Sperren – Tabellensperre im Share-Modus – Tabellensperre im Exclusiv-Modus Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 30 Tabellensperre mit Zeilensperre im Exclusiv-Modus wird von den Anweisungen INSERT, UPDATE und DELETE automatisch veranlaßt. In diesem Sperrzustand sind Datenmanipulationen anderer Transaktionen an den gesperrten Zeilen nicht erlaubt. Weiterhin kann die gesamte Tabelle nicht von anderen Transaktionen gesperrt werden. Erlaubt sind Datenmanipulationen von anderen Transaktionen an anderen Zeilen. Tabellensperre mit Zeilensperre im Share-Modus wird von der Anweisung SELECT ... FOR UPDATE ausgelöst. In diesem Sperrzustand sind Datenmanipulationen anderer Transaktionen erlaubt. Unzulässig ist dann das gesamte Sperren der Tabelle im Exclusive-Modus von anderen Transaktionen. Tabellensperre im Share-Modus erlaubt anderen Transaktionen die Anweisung SELECT ... FOR UPDATE. Andere Transaktionen dürfen diese Tabelle nicht verändern. Tabellensperre im Exclusiv-Modus erlaubt anderen Transaktionen nur einen lesenden Zugriff. 30 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. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 31 Beispiel: Autofahren mit Linksabbiegen an versetzten Einmündungen 31 Deadlock Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 32 32 Deadlock Beispiel Transaktion t1 Zeit Transaktion t2 UPDATE ta_angebot SET preis = 2*preis WHERE kdnr=11; t1 UPDATE ta_angebot SET menge = 0.5*menge WHERE kdnr=12; UPDATE ta_angebot SET preis = 0.5*preis WHERE kdnr=12; t2 UPDATE ta_angebot SET menge = 2*menge WHERE kdnr=11; deadlock detected t3 Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 33 t1: Transaktion T1 ändert in der Tabelle ta_angebot alle Zeilen, in denen die Kundennummer den Wert 11 hat. Dadurch werden diese Zeilen festgehalten. Andere Transaktionen können diese Zeilen jetzt nur noch lesen. Transaktion T2 ändert in der gleichen Tabelle alle Zeilen mit der Kundennummer 12 und hält dadurch diese Zeilen fest. t2: Transaktion T1 möchte jetzt die Zeilen mit der Kundennummer 12 ändern, kann das aber nicht, da T2 diese Zeilen festhält. Also wartet T1 darauf, dass T2 die Zeilen freigibt. Gleichzeitig wartet T2 auf T1, auf dass T1 die Zeilen mit der Kundennummer 11 freigibt. t3: Das Betriebssystem erkennt, dass sich zwei Transaktionen gegenseitig behindern. Eine der beiden Transaktionen wird abgebrochen. 33 Reduzieren von (Dead)lockSituationen • Transaktionen so kurz wie möglich. • Keine Bildschirmaktionen innerhalb einer Transaktion. • Bei Mehrtabellen-Update (z.B.: MasterDetail-Tabellen) muß eine für alle Anwendungen und alle Programmierer verbindliche Reihenfolge der Zugriffe und der Sperrungen festgelegt werden. Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 34 34 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). Worzyk HS Anhalt Medienarchive Sommer 2007 Transaktionen - 35 35 Zusammenfassung 2 • Eigenschaften von Transaktionen – – – – Konsistenz Dauerhaftigkeit Unteilbarkeit Isolation • Gegenseitige Beeinflussung – – – – Worzyk HS Anhalt Lost Update Dirty Read Non Repeatable Read Phantoms Medienarchive Sommer 2007 Transaktionen - 36 36
