Datenbank- Verwaltungssysteme

Transkript

1 Datenbank- Verwaltungssysteme Diana Troancă Babeș-Bolyai Universität Fakultät Mathematik und Informatik

2 Dozent: Diana Troancă dianat [at] cs.ubbcluj.ro Website: 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 -

3 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 Schriftliche Prüfung: in der letzten Vorlesungsstunde

4 Struktur und Klausur Anwesenheit: 5 Seminar-Anwesenheiten aus 7 sind verpflichtend 6 Labor-Anwesenheiten aus 7 sind verpflichtend Ohne diese Anwesenheiten dürft ihr keine Klausur schreiben Ihr dürft die Laborstunden und das Seminar nur mit eurer Gruppe besuchen. Im Ausnahmenfällen und wenn ihr das vorher sagt, dürft ihr das Seminar mit der anderen Gruppe besuchen (natürlich nur im Falle, wenn es um dasselbe Seminarthema geht, das ihr verpasst habt)

5 Praktische Übungen Working environments : DBMS: MS SQL Server App. Development:.NET / C# Data access: ADO.NET

6 Folien, Literatur Folien und andere Informationen zur Vorlesung, Seminar und Übungen werden unter zur Verfügung gestellt Literatur: A. Kemper, A. Eickler. Datenbanksysteme Eine Einführung. Oldenbourg Verlag, Auflage. A. Kemper, M. Wimmer. Übungsbuch Datenbanksysteme. Oldenbourg Verlag, 3. Auflage, 2012.

7 1. Einführung Datenbank-Verwaltungssystems

8 Schwerpunkt der Vorlesung Transaktionsverarbeitung Concurrency Control Fehlerbehandlung, Logging und Recovery Externes Sortieren Anfrageoptimierung Verteilten Datenbanken (Distributed Databases) Sicherheitsaspekte

9 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

10 Detailierte Struktur eines DBMS

11 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

12 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

13 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

14 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

15 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 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 Terminated die Transaktion verlässt das System

16 Transaktionszustände

17 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

18 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

19 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

20 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 Recovery- Maßnahmen (crash recovery)

21 Konsistenzerhaltung (Consistency) Eine Transaktion hinterlässt nach Beendigung einen konsistenten DB- Zustand. Eine erfolgreiche Transaktion garantiert, dass alle Konsistenzbedingungen (Integritä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.

22 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)

23 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

24 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

25 Beispiel Wir betrachten folgenden Transaktionen: T1: BEGIN A=A+100, B=B-100 END T2: 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).

26 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: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Der Ausführungsplan aus dem Sicht des DBMS: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

27 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

28 Anomalien ohne Synchronisation WR Konflikt, dirty read T1: R(A), W(A), R(B), A T2: R(A), W(A), C Inkonsistente Analyse (RW Konflikt, non-repeatable reads) T1: R(A), R(A), W(B), C T2: R(A), W(A), C Verlorengegangene Änderungen (WW Konflikt, dirty overwrite, blind write ) T1: W(A), W(B), C T2: W(A), W(B), C oder T1: R(A), W(A) T2: R(A), W(A)

29 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 Wirkungen irgendeiner seriellen 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)