Transaktionen - Hochschule Anhalt
Werbung
Transaktionen • Begriff, Eigenschaften • • • • • • Nutzungsbedingungen von DBS Konkurrierende Transaktionen Transaktionsoperationen Transaktionsstatus, Zustandsdiagramm Systemprotokoll Sicherungspunkt • • commit-Punkt Transaktionsverwaltung mit SQL DBS1 2004 Transaktionen Seite 1 Klöditz Hochschule Anhalt (FH) Transaktionen Definition • Eine Transaktion ist eine Folge von Operationen, die die Datenbank in ununterbrechbarer Weise von einem konsistenten Zustand in einen (nicht notwendig verschiedenen) konsistenten Zustand überführt Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 2 Transaktionen Eigenschaften • Atomicity (Ununterbrechbarkeit, Unteilbarkeit): – Eine Transaktion ist eine atomare Einheit, die entweder vollständig oder gar nicht ausgeführt wird • Consistency (Konsistenzerhaltung): – Die korrekte Ausführung einer Transaktion überführt die DB von einem konsistenten Zustand wieder in einen konsistenten Zustand • Isolation (isolierter Ablauf): • Durability (Dauerhaftigkeit der Ergebnisse): – Die Transaktion muss serialisierbar sein – Ist eine Transaktion erst einmal erfolgreich abgeschlossen, dürfen die getätigten Änderungen auf keinen Fall verlorengehen; diese Informationen werden im Falle eines Fehlers zur Wiederherstellung des konsistenten Zustandes der Datenbank benötigt DBS1 2004 Transaktionen Seite 3 Klöditz Hochschule Anhalt (FH) Nutzungsumgebung Ein- NutzerUmgebung DBS Mehr-NutzerUmgebung Klöditz Hochschule Anhalt (FH) Sequenzverarbeitung (ein Prozessor) echte Parallelverarbeitung (mehrere Prozessoren) DBS1 2004 Transaktionen Seite 4 Nutzungsumgebung Sequentielle / Parallel-Verarbeitung Sequentielle Verarbeitung Parallel-Verarbeitung Transaktion 1 Transaktion 2 Zeit DBS1 2004 Transaktionen Seite 5 Klöditz Hochschule Anhalt (FH) Konkurrierende Transaktionen Problematik • Eine Transaktion greift gleichzeitig auf dasselbe Datenelement zu wie eine andere Transaktion • Wird das nicht überwacht, können inkonsistente DB-Zustände entstehen Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 6 Konkurrierende Transaktionen Beispiel • In einem Platzreservierungssystem werden durch eine Transaktion1 N Plätze im Flug "X" rückgängig gemacht und anschließend im Flug "Y" reserviert; eine Transaktion2 reserviert M Plätze im Flug "X" Transaktion1 read_item (X) X := X – N write_item X) read_item (Y) Y := Y + N write_item (Y) Transaktion2 read_item (X) X := X + M write_item (X) Zeit DBS1 2004 Transaktionen Seite 7 Klöditz Hochschule Anhalt (FH) Konkurrierende Transaktionen Lost-Update-Problem • Liest T2 den Wert von X, bevor T1 die Änderung in der Datenbank abgespeichert hat, ist der Endwert von T1 verloren • "verlorene Änderung", "Lost-Update-Problem" Transaktion1 read_item (X) X := X – N Transaktion2 read_item (X) X := X + M write_item X) read_item (Y) write_item (X) Y := Y + N write_item (Y) Klöditz Hochschule Anhalt (FH) Zeit DBS1 2004 Transaktionen Seite 8 Konkurrierende Transaktionen Temporary-Update-Problem • Transaktion scheitert während ihrer Ausführung – Änderungen in der Datenbasis sind bereits vorgenommen, – andere Transaktion greift auf geändertes Datenelement zu, ehe der alte Zustand wiederhergestellt wurde • "temporäre Änderung", "Temporary Update Problem" Transaktion1 read_item (X) X := X – N write_item X) Transaktion2 read_item (X) X := X + M write_item (X) read_item (Y) Klöditz Hochschule Anhalt (FH) Abbruch: T1 wird rückgängig gemacht Zeit DBS1 2004 Transaktionen Seite 9 Konkurrierende Transaktionen Dirty-Read-Problem • Wird über mehrere Datensätze z.B. die Summe von einzelnen Datenelementen gebildet, während eine andere Transaktion gerade eines aktualisiert, können falsche Werte entstehen • "schmutziges Lesen", "Dirty-Read-Problem", "incorrect summary problem" Transaktion1 Abbuchen Konto1 Transaktion2 Saldenbestände lesen Gutschreiben Konto 2 Zeit Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 10 Fehler bei der Ausführung von Transaktionen • Hard- oder Software-Fehler während einer Transaktion (crash): meist Verlust der Daten im Hauptspeicher • Systemabsturz während einer Transaktion (z.B. Division durch Null, falsche Parameter) Abbruch der Transaktion wegen selbsterkanntem Fehler (z.B. Zugriff auf Datenelemente, die nicht gefunden werden): Transaktion wird zurückgesetzt Integritätskontroll-Komponente verlangt den Abbruch Schreibkopf einer Platte berührt die Oberfläche (head crash): Schreib-/Lesefehler; Datenblöcke werden unlesbar Einfluss höherer Gewalt: Feuer, Wasser, Diebstahl, Sabotage • • • • DBS1 2004 Transaktionen Seite 11 Klöditz Hochschule Anhalt (FH) Wiederanlauftechnik • Wiederanlauftechnik (Recovery) muss sichern, dass nach Fehlern wieder ein konsistenter DB-Zustand hergestellt werden kann • System muss dafür genügend Informationen besitzen Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 12 Transaktionsoperationen read-Operation • read (X) Einlesen des DB-Elementes X in eine Programmvariable gleichen Namens • löst folgende Schritte aus: – Finde die Adresse des Plattenblockes, der das Datenelement mit dem Namen X enthält – Falls dieser Plattenblock nicht bereits im Arbeitsspeicher vorhanden ist, kopiere ihn in den Hauptspeicher – Kopiere X in die Programmvariable gleichen Namens DBS1 2004 Transaktionen Seite 13 Klöditz Hochschule Anhalt (FH) Transaktionsoperationen write-Operation • write (X) Schreiben des Wertes der Programmvariablen in das DB-Element X • löst folgende Schritte aus: – Finde die Adresse des Plattenblockes, der das Datenelement X enthält – Kopiere diesen Block in den Arbeitsspeicher – Schreibe den Inhalt der Programmvariablen in das Datenelement X – Speichere den aktualisierten Block auf der Platte ab Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 14 Transaktionsstatus Markierungen • Zum erfolgreichen Wiederanlauf muss der Transaktionsstatus bekannt sein • Folgende Operationen markieren einen bestimmten Transaktionsstatus: – begin_transaction – read / write – end_transaction – commit_transaction markiert den Beginn einer Transaktion im Falle eines Wiederanlaufes interessierende Operationen markiert das Ende einer Transaktion; DBMS prüft, ob die Änderungen auf der DB permanent gemacht werden dürfen oder die Transaktion abgebrochen werden muss zeigt das erfolgreiche Ende einer Transaktion an; getätigte Änderungen werden gesichert DBS1 2004 Transaktionen Seite 15 Klöditz Hochschule Anhalt (FH) Transaktionsoperationen Zusätzliche Operationen • außerdem für bestimmte Wiederanlauftechniken notwendige zusätzliche Operationen: – rollback oder abort – undo – redo Klöditz Hochschule Anhalt (FH) signalisiert, dass die Transaktion nicht erfolgreich durchgeführt werden konnte und die Veränderungen rückgängig gemacht werden müssen macht einzelne Operationen der Transaktion rückgängig führt einzelne Operationen erneut aus DBS1 2004 Transaktionen Seite 16 Transaktionszustandsdiagramm begin_transaction end_transaction commit_transaction partiell festgelegt aktiv festgelegt rollback rollback read / write gescheitert beendet DBS1 2004 Transaktionen Seite 17 Klöditz Hochschule Anhalt (FH) Systemprotokoll Begriff, Inhalt • Das Systemprotokoll zeichnet alle Informationen für eine Transaktion (alle Operationen, alter und neuer Wert des betr. DB-Elementes) auf, die benötigt werden, um bei Transaktionsabbrüchen und bei Wiederanläufen den konsistenten Zustand der Datenbank wieder herzustellen Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 18 Systemprotokoll Begriff, Inhalt • Jeder Transaktion wird ein eindeutiger Transaktionsidentifikator T vom System automatisch zugeordnet • Folgende Einträge werden protokolliert: – [start_transaction, T]: Transaktion T wurde gestartet – [write, T, X, alter_Wert, neuer_Wert]: Datenelement X wurde von alter_Wert in neuer_Wert geändert – [read, T,X]: Datenelement X wurde gelesen (kein notwendiger Eintrag, nicht konsistenzgefährdend) – [commit, T]: Transaktion T wurde erfolgreich beendet, Wirkungen werden in die Datenbank weitergeleitet und gespeichert DBS1 2004 Transaktionen Seite 19 Klöditz Hochschule Anhalt (FH) Systemprotokoll Nutzung • Änderungen der DB geschehen ausschließl. über Transaktionen • • Transaktionen dürfen nicht geschachtelt werden Im Falle von Fehlern werden beim Recovery entweder – alle write-Operationen im Systemprotokoll rückgängig gemacht (undo) und die Inhalte auf die alten Werte zurückgesetzt (Durchlauf des Systemprotokoll rückwärts) oder – alle Systemprotokoll-Einträge wiederholt (redo) und die Datenelemente ein zweites Mal auf die neuen Werte geändert (Durchlauf des Systemprotokolls vorwärts) • Bis wohin bzw. ab wann muss Recovery erfolgen? Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 20 commit-Punkt • Eine Transaktion T erreicht ihren TransaktionsFestlegungspunkt (commit-point), wenn – einerseits alle Datenbank-Operationen erfolgreich ausgeführt worden sind und – andererseits die Wirkungen aller Transaktions -Operationen auf die Datenbank im Systemprotokoll registriert sind • Bei Transaktionsfehlern werden – Transaktionen, die im Systemprotokoll einen Eintrag [start_transaction, T] aber keinen Vermerk [commit, T] besitzen, zurückgesetzt und ihre Wirkungen beim Recovery rückgängig gemacht und – alle übrigen Transaktionen mit Hilfe der im Systemprotokoll enthaltenen write-Operationen ein zweites Mal ausgeführt DBS1 2004 Transaktionen Seite 21 Klöditz Hochschule Anhalt (FH) Sicherungspunkt • Ein Sicherungspunkt (check point) wird periodisch im Systemprotokoll verzeichnet, wenn das System die geänderten Blöcke von festgelegten Transaktionen aus dem Puffer auf die Datenbank schreibt • Sicherungspunkte werden in festen Zeitabständen oder nach einer bestimmten Anzahl Transaktionen eingerichtet. Dann wird folgendes ausgeführt: – Die Ausführung von Transaktionen wird kurzzeitig unterbrochen – Alle aktualisierten Blöcke werden aus dem Puffer auf die Platte geschrieben – Im Systemprotokoll wird ein Sicherungspunkt vermerkt – Die Ausführung der Transaktionen wird fortgesetzt Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 22 Control of Database Transactions with SQL • Transactions contain one of the following statements: – DML statements that make up one consistent change to the data – One DDL statement – One DCL statement DBS1 2004 Transaktionen Seite 23 Klöditz Hochschule Anhalt (FH) Database Transactions • Begin when the first executable SQL statement is executed • End with one of the following events: – COMMIT or ROLLBACK – DDL or DCL statement executes (automatic commit) – Certain errors , exit, or system crash Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 24 Advantages of COMMIT and ROLLBACK • Ensure data consistency • • Preview data changes before making changes permanent Group logically related operations DBS1 2004 Transaktionen Seite 25 Klöditz Hochschule Anhalt (FH) Controlling Transactions INSERT COMMIT UPDATE Savepoint A INSERT DELETE Savepoint B ROLLBACK to Savepoint B ROLLBACK to Savepoint A ROLLBACK Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 26 Implicit Transaction Processing • An automatic commit occurs under the following circumstances: – A DDL statement is issued – A DCL statement is issued – A normal exit from SQL*Plus, without explicitly issuing COMMIT or ROLLBACK • An automatic rollback occurs under an abnormal termination of SQL*Plus or a system failure DBS1 2004 Transaktionen Seite 27 Klöditz Hochschule Anhalt (FH) State of the Data Before COMMIT or ROLLBACK • The previous state of the data can be recovered because the database buffer is affected • The current user can review the results of the DML operations by using the SELECT statement Other users cannot view the results of the DML statements by the current user The affected rows are locked; other users cannot change the data within the affected rows • • Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 28 State of the Data After COMMIT • Data changes are made permanent in the database • • • The previous state of the data is permanently lost All users can view the results Locks on the affected rows are released; those rows are available for other users to manipulate All savepoints are erased • DBS1 2004 Transaktionen Seite 29 Klöditz Hochschule Anhalt (FH) Committing Data • Make the changes SQL> UPDATE emp 2 SET deptno = 10 3 WHERE empno = 7782; 1 row updated. • Commit the changes SQL> COMMIT; Commit complete. Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 30 State of the Data After ROLLBACK • Discard all pending changes by using the ROLLBACK statement – Data changes are undone – Previous state of the data is restored – Locks on the affected rows are released SQL> DELETE FROM 14 rows deleted. SQL> ROLLBACK; Rollback complete. employee; DBS1 2004 Transaktionen Seite 31 Klöditz Hochschule Anhalt (FH) Rolling Back Changes to a Marker • Create a marker within a current transaction by using the SAVEPOINT statement • Roll back to that marker by using the ROLLBACK TO SAVEPOINT statement SQL> UPDATE... SQL> SAVEPOINT update_done; Savepoint created. SQL> INSERT... SQL> ROLLBACK TO update_done; Rollback complete. Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 32 Statement-Level Rollback • If a single DML statement fails during execution, only that statement is rolled back • • • Oracle8 implements an implicit savepoint All other changes are retained The user should terminate transactions explicitly by executing a COMMIT or ROLLBACK statement DBS1 2004 Transaktionen Seite 33 Klöditz Hochschule Anhalt (FH) Read Consistency • Read consistency guarantees a consistent view of the data at all times • Changes made by one user do not conflict with changes made by another user Ensures that on the same data: • – Readers do not wait for writers – Writers do not wait for readers Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 34 Implementation of Read Consistency Data blocks update emp set sal = 2000 where ename = 'SCOTT' Rollback segments User A select * from emp Read consistent image User B changed and unchanged data before change ‘old’ data DBS1 2004 Transaktionen Seite 35 Klöditz Hochschule Anhalt (FH) Locking • Oracle8 locks: – – – – – Prevent destructive interaction between concurrent transactions Require no user action Automatically use the lowest level of restrictiveness Are held for the duration of the transaction Have two basic modes : • Exclusive • Shared Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 36 Summary Statement Description COMMIT Makes all pending changes permanent SAVEPOINT Allows a rollback to the savepoint marker ROLLBACK Discards all pending data changes Klöditz Hochschule Anhalt (FH) DBS1 2004 Transaktionen Seite 37
