Transaktion

DatenbankVerwaltungssystems
• Dozent: Diana Troancă
• E-mail: dianat [at] cs.ubbcluj.ro
• Website: www.cs.ubbcluj.ro/~dianat/
• Feedback vom letzten Semester?
• Was hat euch gefallen / was sollte sich nicht ändern?
• Was hat euch nicht gefallen und wie würdet ihr das verbessern?
• Kursanforderungen - http://www.cs.ubbcluj.ro/~dianat/sgbd.php
Struktur und Klausur
• Vorlesung: jede Woche (2 Std)
• Praktische Übungen: jede 2te Woche (2 Std)
• Seminar: jede 2te Woche (2 Std)
• Praktisches Test: in der letzten Übungsstunde (16.01.201720.01.2017)
• Schriftliche Prüfung: während der Prüfungszeit (23.01.2017 –
12.02.2017)
Praktische Übungen
• Working „environments“:
• DBMS:
• App. Development:
• Data access:
MS SQL Server
.NET / C#
ADO.NET
Folien, Literatur
• Folien und andere Informationen zur Vorlesung, Seminar und
Übungen werden unter www.cs.ubbcluj.ro/~dianat/ zur Verfügung
gestellt
• Literatur:
• A. Kemper , A. Eickler. Datenbanksysteme – Eine Einführung. Oldenbourg
Verlag, 2015. 10. Auflage.
• A. Kemper, M. Wimmer. Übungsbuch Datenbanksysteme. Oldenbourg
Verlag, 3. Auflage, 2012.
1. Einführung
Datenbank-VerwaltungssystemsDatenbankVerwaltungssystems
Schwerpunkt der Vorlesung
• Transaktionsverarbeitung
• Concurrency Control
• Fehlerbehandlung, Logging und Recovery
• Externes Sortieren
• Anfrageoptimierung
• Verteilten Datenbanken (Distributed Databases)
• Sicherheitsaspekte
Motivation für den Einsatz eines
Datenbank-Verwaltungssystems
Typische Probleme bei Informationsverarbeitung ohne DBMS:
• Redundanz und Inkonsistenz
• Beschränkte Zugriffsmöglichkeiten
• Probleme beim Mehrbenutzerbetrieb
• Verlust von Daten
• Integritätsverletzung
• Sicherheitsprobleme
• Hohe Entwicklungskosten für Anwendungsprogramme
Detailierte Struktur eines DBMS
Transaktionsverwaltung
• Beispiel für eine Transaktion:
• Überweise Geld von Konto A nach Konto B
•
•
•
•
•
•
Lies den Kontostand von A in die Variable a: read(A,a)
Reduziere den Kontostand um 50 Euro: a = a-50
Schreibe den neuen Kontostand in die Datenbasis: write(A,a)
Lies den Kontostand von B in die Variable b: read(B,b)
Erhöhe den Kontostand um 50 Euro: b = b+50
Schreibe den neuen Kontostand in die Datenbasis: write(B,b)
• Transaktionsverwaltung beinhaltet die folgenden zwei Teilgebiete:
• Synchronisation von mehreren gleichzeitig auf der Datenbank ablaufenden
Transaktionen
• Recovery – die Behebung von eingetretenen, oft unvermeidbaren
Fehlrensituationen
Transaktionen
• Transaktionen sind eine Zusammenfassung von aufeinanderfolgenden
DB-Operationen, die eine Datenbank von einem konsistenten Zustand
wieder in einen konsistenten Zustand überführt
• Transaktionen werden immer beendet:
• Normal (commit): Änderungen sind permanent in DB
• Abnormal (abort / rollback): bereits durchgeführte Änderungen werden
zurückgenommen
Transaktionen
• Gleichzeitige Ausführung mehreren Operationen ist sehr wichtig für eine
gute Effizienz des DBMS
• Eine Anwendung kann viele Operationen auf den abgerufenen Daten
ausführen, aber für das DBMS sind nur die Lese- und Schreiboperationen
wichtig
• Aus der Sicht der Datenbankbenutzer ist eine Transaktion eine logische
Arbeitseinheit
• Auf der Ebene des DBMS stellt eine Transaktion eine Folgen von
Datenverarbeitungsbefehlen (lesen, verändern, einfügen, löschen) dar:
eine Folge von Lese- und Schreiboperationen
• Das wesentliche dabei ist, dass diese Folge von Befehlen logisch
ununterbrechbar (atomar) ausgeführt wird
Transaktionen - Operationen
• Begin – transaction → kennzeichnet den Beginn einer Transaktion
• Read
• Write
• End – transaction
• Commit – transaction → erfolgreiche Beendigung einer Transaktion
• Abort – transaction → Selbstabbruch der Transaktion, erfolglose
Beendigung
• Undo
• Redo
Transaktionszustände
• Active – nach dem Beginn; ab jetzt können Lese- und Schreiboperationen
abgerufen werden
• Partially committed –die Transaktion ist von Seiten des Anwendungs-programms
nun beendet, muss aber mit Hilfe von Concurrency Control-Maßnahmen
überprüft werden (die Konsistenz der DB muss erhalten werden)
• Committed – wenn alle Prüfungen keinen Fehler ergeben
• Terminated – die Transaktion verlässt das System
• Aborted – wenn die Transaktion abgebrochen wird oder wenn eine Prüfung
einen Fehler liefert
‐ Die Recovery-Komponenen übernimmt das Zurücksetzen aller
durchgeführten Schreiboperationen
Transaktionszustände
Nebenläufigkeit/Concurrency in einer DBMS
• Die Benutzer denken an jede Transaktion als an eine eigenständige Einheit
von Operationen
• Concurrency wird aber von dem DBMS erreicht, indem mehrere
Transaktionen parallel oder verzahnt durchgeführt werden
• Jede Transaktion erhaltet den konsistenten Zustand der DB (falls der
Zustand beim Beginn der Transaktion konsistent war)
• DBMS überprüft bestimmte Concurrency Control-Maßnahmen
(Intergitätsbedingungen, die beim CREATE TABLE definiert wurden)
• Das DBMS versteht die Semantik der Daten nicht → die Konsistenz wird nur bzgl.
Integritätsbedingungen beurteilt
• Probleme der Synchronisation und des Concurrency Control:
• die Wirkung der parallelen oder verzahnten Transaktionen und der
Crashes
Nebenläufigkeit/Concurrency in einer DBMS
• Wir können zwei Arten von Nebenläufigkeit unterscheiden:
• Parallele Nebenläufigkeit (parallel concurrency)
‒ bei Vorhandensein eines Mehrprozessorsystems
‒ Transaktionen laufen gleichzeitig ab, d.h. Parallel auf verschiedenen Prozessoren
• Verzahnte Nebenläufigkeit (interleaved concurrency, „quasi-parallele“
Nebenläufigkeit)
‒ Bei Vorhandensein eines Einprozessorsystems
‒ Zu einem Zeitpunkt kann höchstens eine Transaktion von der CPU verarbeitet werden,
aber die CPU Zeit wir in sehr kurzen Zeitintervallen zwischen verschiedenen in
Ausführung befindlichen Transaktionen verteilt
‒ Wir betrachten meistens diesen Fall
Eigenschaften einer Transaktion - ACID
• Atomarität (Atomicity)
• Eine Transaktion ist eine unteilbare Verarbeitungseinheit – sie wird entweder
vollständig oder gar nicht ausgeführt.
• Konsistenzerhaltung (Consistency)
• Eine korrekte Ausführung einer Transaktion überführt die Datenbank von
einem konsistenten Zustand in einen anderen konsistenten Zustand.
• Isolation (Isolation)
• Mehrere Transaktionen laufen voneinander isoliert ab und benutzen keine
(inkonsistenten) Zwischenergebnisse anderer Transaktionen
• Dauerhaftigkeit (Durability)
• Ergebnisse und Auswirkungen einer erfolgreich beendeten Transaktion
(committed) sind und bleiben persistent, d.h. Sie überleben jeden
nachfolgenden Fehler
Atomarität (Atomicity)
• Unteilbarkeit durch Transaktionsdefinition (Begin – End)
• Alles-oder-Nichts Prinzip, d.h. Das DBMS garantiert:
• Entweder die vollständige Ausführung einer Transaktion
• Oder die Wirkungslosigkeit der gesamten Transaktion
• Eine Transaktion wir am Ende entweder committed, oder aborted
• Das DBMS führt eine Log-Datei, die alle Operationen (die Werte von
Datenobjekten verändern) einer Transaktion protokolliert, sodass es
möglich ist alle Auswirkungen der Transaktion rückgängig zu machen
(undo)
• Um die Atomarität bei Transaktionsfehlern zu gewährleisten → RecoveryMaßnahmen (crash recovery)
Konsistenzerhaltung (Consistency)
• Eine Transaktion hinterlässt nach Beendigung einen konsistenten DBZustand.
• Eine erfolgreiche Transaktion garantiert, dass alle Konsistenzbedingungen
(Indegritätsbedingungen) eingehalten worden sind.
• Wenn die Transaktion nicht alle Konsistenzbedingugen einhält, wird diese
zurückgesetzt.
• Zwischenzustände, die während der Bearbeitung des Transaktions
entstehen, dürfen inkonsistent sein, aber der resultierende Endzustand
muss immer konsistent sein.
Isolation (Isolation)
• Nebenläufige (parallele, gleichzeitige) ausgeführte Transaktionen
müssen sich gegenseitig nicht beeinflussen.
• Den Benutzern wird den Eindruck einer seriellen Ausführung der
Transaktionen vermittelt
• D.h., wenn man die Transaktionen nacheinander ausgeführen würde,
sollte man die gleichen Ergebnisse erhalten (Serialisierbarkeit)
• Die Zwischeergebnisse einer Transaktion dürfen vor dem Commit der
Transaktion für andere Transaktionen nicht sichtbar sein.
• Notwendig um kaskadierendes Rücksetzen zu vermeiden (cascading aborts)
Dauerhaftigkeit (Durability)
• Die Wirkung einer erfolgreich abgeschlossenen Transaktion
(committed) bleibt dauerhaft in der Datenbank erhalten.
• Die Transaktionsverwaltung muss sicherstellen, dass dies auch nach
einem Systemfehler (Hardware oder Software) gewährleistet ist.
• DB Recovery
Transaktionsverwaltung
• Die Transaktionsverwaltung besteht aus zwei „großen“ Komponenten:
• Der Mehrbenutzersynchronisation
• Der Recovery
• Die Aufgabe der Mehrbenutzersynchrosnisation besteht darin, die
Isolation von parallel ablaufenden Transaktionen zu gewährleisten
• Die Aufgabe der Recovery besteht darin, die Atomarität und die
Dauerhaftigkeit zu gewährleisten
Beispiel
• Wir betrachten folgenden Transaktionen:
T1:
T2:
BEGIN A=A+100,
B=B-100 END
BEGIN A=1.1.06*A, B=1.06*B END
• Die erste Transaktion überweist 100 Euro von Konto B nach Konto A
• In der zweiten Transaktion werden beide Kontos mit 6% verzinst
• Wenn die Transaktionen gleichzeitig beginnen, wissen wir nicht ob die
erste Transaktion vor der zweiten durchgeführt wird oder umgekehrt.
• Der Endeffekt muss aber äquivalent zu der Serialisierung der zwei
Transaktionen sein (in einer Reihenfolge).
Beispiel
• Ein möglicher verzahnter Ausführungsplan/Schedule ist:
T1:
A=A+100,
B=B-100
T2:
A=1.06*A,
B=1.06*B
Das ist OK (äquivalent mit der Serialisierung T1, T2).
• Ist der folgende Ausführungsplan OK?
T1:
T2:
A=A+100,
B=B-100
A=1.06*A, B=1.06*B
• Der Ausführungsplan aus dem Sicht des DBMS:
T1:
T2:
R(A), W(A),
R(B), W(B)
R(A), W(A), R(B), W(B)
Konfliktoperationen
• Zwei Transaktionen sind nicht in Konflikt wenn:
• Diese nur Daten lesen (und nicht schreiben)
• Unterschiedliche Datenobjekte lesen und schreiben
• Zwei Transaktionen/Operationen stehen in Konflikt miteinander, wenn
beide auf dem gleichen Datenobjekt arbeiten und mindestens eine
davon eine Schreiboperation ist:
• WR Konflikt: T2 liest ein Datenobjekt, der vorher von T1 geschrieben wurde
• RW Konflikt: T2 schreibt ein Datenobjekt, der vorher von T1 gelesen wurde
• WW Konflikt: T2 schreibt ein Datenobjekt, der vorher von T1 geschrieben wurde
• Operationen die in Konflikt miteinander stehen, dürfen nicht parallel
ausgeführt werden
Anomalien ohne Synchronisation
• Abhängigkeit von nicht freigegebenen Änderungen:
• WR Konflikt, „dirty read“
T1:
R(A), W(A),
T2:
R(A), W(A), C
R(B), A
• WW Konflikt, „dirty overwrite“, „blind write“
T1:
W(A),
W(B), C
T2:
W(A), W(B), C
• Inkonsistente Analyse (RW Konflikt, non-repeatable reads)
T1:
T2:
R(A),
R(A), W(B), C
R(A), W(A), C
• Verlorengegangene Änderungen
T1:
T2:
R(A),
W(A)
R(A),
W(A)
Zusammenfassung
• Nebenläufigkeitskontrolle (Concurrency Control) und Recovery sind Teil der
wichtigsten Aufgaben eines DBMS
• Die Benutzer müssen sich keine Sorgen über die Nebenläufigkeit machen:
• Das System benutzt Sperren und Ausführungpläne für die Transaktionen um
sicherzustellen, dass die Wirkungen und Ergebnisse äquivalent sind mit den
Wrikungen irgendeiner serialen Ausführung der Transaktionen
• Write-Ahead Logging (WAL) wird als Undo-Protokoll benutzt → nach dem
Abort einer Transaktion werden alle ausgeführten Operationen
zurückgesetzt
• Konsistenten Zustand: man sieht nur die Wirkungen der erfolgreich
beendeten Transaktionen (committed)