WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R 0.006 Vorlesung #10 Transaktionsverwaltung

WS 2011/12Datenbanksysteme

Mi 15:15 – 16:45R 0.006

Vorlesung #10

Transaktionsverwaltung


Mi 15:15 – 16:45R 0.006

© Bojan Milijaš, 02.12.2011 Vorlesung #10 - Transaktionsverwaltung 2

„Fahrplan“

Anforderungen an die Transaktionsverwaltung Behebung von Fehlersituationen (Recovery) Synchronisation

Operationen auf der Transaktionsebe BOT (begin of transaction) COMMIT ABORT (auch ROLLBACK)

Eigenschaften von Transaktionen (ACID Paradigma) Atomicity, Consistency, Isolation, Durability

Transaktionsverwaltung in SQL Zustandsübergänge einer Transaktion Ausblick Vorlesung #12


Mi 15:15 – 16:45R 0.006


Einführung

Konzept der Transaktion – einer der größten Beiträge der Datenbankforschung für andere Informatikbereiche

Transaktion - Bündelung von mehreren Operationen, die in einem Mehrbenutzersystem ohne unerwünschte Einflüsse auf oder durch andere Transaktionen als eine Einheit fehlerfrei ausgeführt werden


Mi 15:15 – 16:45R 0.006


Transaktionsbegriff

Transaktion ist eine „Arbeitseinheit“ Alle Teiloperationen einer Transaktion werden als

eine Einheit, voneinander ungetrennt und ununterbrechbar ausgeführt

Deshalb spricht man von der atomaren Ausführung Transaktion ist eine Folge von

Datenverarbeitungsbefehlen (Lesen, Verändern, Einfügen und Löschen), die atomar ausgeführt wird

Eine Transaktion überführt die Datenbank von einem transaktionskonsistenten Zustand in den anderen (nicht notwendigerweise unterschiedlichen) transaktionskonsistenten Zustand


Mi 15:15 – 16:45R 0.006


Beispiel: Bankanwendung

Es werden 50 € von Konto A nach Konto B transferiert

1. Lese Kontostand A in die Variable a: read(A,a);2. Reduziere den Kontostand um 50 €: a:=a-50;3. Schreibe den neuen Zustand 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 €: b:=b+50;6. Schreibe den neuen Kontostand in die Datenbasis:

write(B,b);


Mi 15:15 – 16:45R 0.006


Beispiel: Bankanwendung (2) Wenn die Operationsfolge abgebrochen wäre,

könnten inkonsistente Zustände entstehen. Beispiele: wenn das System nach dem Schritt 3 abstürzt,

ist der Kontostand A um 50 € vermindert, ohne dass Konto B um 50 € jemals erhöht wurde

wenn Konto B einem anderen Inhaber gehört und das Abheben von 50 € zur Überschreitung des Dispositionskredit beim Konto A führt, müsste der gesamte Transfer rückgängig gemacht werden


Mi 15:15 – 16:45R 0.006


Beispiel: Bankanwendung (3) In einer SQL-Datenbank sieht es eigentlich

so aus:-- Transferiere 50 € von Konto A nach BUPDATE Konto SET Stand = Stand - 50 WHERE ID = 'A';--> Unterbrechung auf --> Kosten des InhabersUPDATE Konto SET Stand = Stand + 50 WHERE ID = 'B';

muss atomarausgeführtwerden


Mi 15:15 – 16:45R 0.006


Anforderungen

Synchronisation sehr viele gleichzeitig nebenläufig ablaufende

Transaktionen müssen abgearbeitet werden Konsistenzverletzungen durch unkontrollierte

Nebenläufigkeiten müssen ausgeschlossen bleiben

Recovery Abgeschlossene Transaktionen müssen auch

nach jedem denkbaren Fehler in ihrer Wirkung erhalten bleiben und

nicht erfolgreich abgeschlossene Transaktionen müssen vollständig zurückgesetzt werden


Mi 15:15 – 16:45R 0.006


Operationen auf der TransaktionsebeneAus der DBMS-Sicht gibt es nur zwei Operationen read() und write()Zusätzlich Transaktionsoperationen: Begin of Transaction (BOT) – oft implizit, durch

die erste Operation angegeben Commit – Beendigung der Transaktionen. Alle

Änderungen an der Datenbasis werden dauerhaft in die Datenbasis festgeschrieben.

Abort bzw. Rollback – Selbstabbruch der Transaktion. DBMS muss sicherstellen, dass die Datenbank wieder in den Zustand vor Transaktionsbeginn zurückgesetzt wird.


Mi 15:15 – 16:45R 0.006


Operationen auf der Transaktionsebene (2)

... zusätzlich gibt es bei weiterentwickelten DBMS-Systemen für lange Transaktionen zwei weitere Befehle

define savepoint – Definition eines Sicherungspunktes, auf den sich eine noch aktive Transaktion zurücksetzen lassen kann. DBMS „merkt“ sich alle Änderungen bis zum Savepoint, darf sie aber nicht commiten wegen möglichen Abort

backup transaction – Rücksetzen der Transaktion auf den letzten Savepoint


Mi 15:15 – 16:45R 0.006


Abschluss einer Transaktion

erfolgreich - COMMIT erfolglos - ABORT (explizit) oder irgendein

Fehler (impliziter ABORT)

BOT

op1

...

opn

COMMIT;

BOT

op1

...

opn

ABORT;

BOT

op1

...

opn

~~ Fehler ~~


Mi 15:15 – 16:45R 0.006


Wichtig!

Eine Transaktion führt die Datenbank aus einem konsistenten Zustand in das andere konsistente Zustand

Es wird entweder alles erfolgreich festgeschrieben oder alles zurückgesetzt. In DBMS-Jargon: „alles wird commited oder alles wird zurückgerollt - komme was wolle“)

Während der Abarbeitung einer Transaktion darf es vorübergehend einzelne Teiloperationen geben, die die Konsistenz verletzen. Die Transaktion darf als eine Einheit nicht die Konsistenz verletzen. Was zählt ist die Transaktion als Ganzes, nicht einzelne Teiloperationen.


Mi 15:15 – 16:45R 0.006


ACID Paradigma

Atomicity – die Transaktion gilt als eine Einheit, entweder werden alle Änderungen festgeschrieben oder gar keine.

Consistency – eine Transaktion hinterlässt nach Ihrer Beendigung immer einen konsistenten Datenbankzustand. Sonst wird sie zurückgesetzt.

Isolation – nebenlaufende Transaktionen beeinflussen sich nicht gegenseitig. Jede Transaktion wird so ausgeführt, als wäre sie die einzige in DBMS.

Durability – die Wirkung einer erfolgreich abgeschlossener Transaktion bleibt dauerhaft in der Datenbank erhalten, trotz aller möglichen Fehler.


Mi 15:15 – 16:45R 0.006


Transaktionsverwaltung in SQL In SQL-92 Standard gibt es kein BOT, Transaktionen

werden implizit mit der Ausführung der ersten Anweisung begonnen

COMMIT [WORK] – Commit ROLLBACK [WORK] – AbortUPDATE Konto SET Stand = Stand - 50 WHERE ID = 'A';UPDATE Konto SET Stand = Stand + 50 WHERE ID = 'B';COMMIT;


Mi 15:15 – 16:45R 0.006



Mi 15:15 – 16:45R 0.006


Fazit und Ausblick

Transaktionsbegriff wurde eingeführt und erläutert

Transaktionsverwaltung besteht aus zwei großen Komponenten Recovery bzw. Fehlerbehandlung (wird kurz

erwähnt, nächstes Semester vertieft) Mehrbenutzersynchronisation (Vorlesung #12)


Mi 15:15 – 16:45R 0.006

Vorlesung #10

Ende

Documents

WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R 0.006 Vorlesung #10 Transaktionsverwaltung