Kapitel 12 Integrität der Datenbank

Transkript

1 Kapitel 12 Integrität der Datenbank 12 Integrität der Datenbank 12 Integrität der Datenbank Aspekte des Integritätsproblems Semantische Integrität Das Konzept der Transaktion Synchronisation paralleler Transaktionen Probleme beim parallelen Zugriff Serialisierbarkeit Zwei-Phasen-Sperrprotokoll Realisierung von Synchronisationsverfahren DEADLOCK Der LOCK-Manager...21 Seite 1

2 12.5 RECOVERY Fehlerklassen ROLLBACK SYSTEM-NEUSTART REKONSTRUKTION...27 Seite 2

3 12.1 Aspekte des Integritätsproblems Definition: Integrität einer Datenbank Unter der Integrität einer Datenbank versteht man die Zusammenfassung aller Maßnahmen zur Erhaltung der Korrektheit der Daten in der Datenbank. Aspekte des Integritätsproblems: Semantische Integrität Transaktionen Synchronisation paralleler Transaktionen Recovery Maßnahmen zur Wahrung der Integrität: Semantische Integrität Operationale Integrität Datensicherung bzw. Recovery Seite 3

4 Definition: Konsistenz Unter Konsistenz versteht man die Widerspruchsfreiheit und Vollständigkeit von Daten in einer Datenbank (Integrität im logischen Sinne) Semantische Integrität Logische Fehler in einer Datenbank durch: absichtliche Fehleingaben Tippfehler Unwissen der Benutzer Fragestellungen: Stimmt der Datentyp? Liegen die eingegebenen Daten im Bereich zulässiger Werte? Widerspricht ein eingegebener Wert einer Plausibilitätsprüfung? Seite 4

5 Implizite Integritätsbedingungen: Eine Datentypbeschreibung ist bereits eine Integritätsbedingung Beispiel 1: RECORD PERSON... FAM-STAND = Ledig Verheiratet Verwitwet Geschieden Beispiel 2: SET - Typ (S: A, B) Explizite Integritätsbedingungen: 1. Integritätsbedingungen in den DBTG-Vorschlägen DDL-Angaben über eine SET-Mitgliedschaft bilden schon eine Integritätsbedingung 2. Integritätsbedingungen in relationalen Systemen Abbilden von funktionalen Abhängigkeiten: o Schlüsseldefinition im Relationenschema o SQL-Statements (ASSERT-Abfragen) Seite 5

6 3. Klassen von Integritätsbedingungen o Klassifiziert nach bezogenem Objekt o Klassifiziert nach dem Veränderungstyp 12.3 Das Konzept der Transaktion Eine Transaktion umfasst alle logisch zusammengehörigen Änderungen, die die Datenbank von einem konsistenten Zustand in den nächsten konsistenten Zustand überführen. Beispiel: Überweisungsauftrag 1. Sollbuchung 2. Protokollierung 3. Habenbuchung Die Transaktionsverarbeitung ist das wesentliche Unterscheidungsmerkmal von Datenbanksystemen (DBS) zu konventionellen Dateisystemen. Seite 6

7 12.4 Synchronisation paralleler Transaktionen Probleme beim parallelen Zugriff Der Ablauf paralleler Zugriffe kann nicht beliebig erfolgen. Dabei können folgende Probleme auftreten: lost update inkonsistente Sicht auf DB Inkonsistenz der DB Phantome Seite 7

8 Beispiel: lost update Die Transaktionen T1 und T2 wollen den Wert von Objekt a um 10 erhöhen. Transaktion Kommentar T1 liest a /a hat den Wert 20/ T2 liest a /a hat den Wert 20/ T1 erhöht, a := a + 10 speichert a T2 erhöht, a := a + 10 speichert a /a hat den Wert 30/ /a hat den Wert 30/ Seite 8

9 Beispiel: inkonsistente Sicht Gegeben seien zwei Konten a und b mit der Integritätsbedingung a + b = 0. Transaktion T1 ändert a: = a 1 T2 liest a und b T1 ändert b: = b + 1 Seite 9

10 Beispiel: Inkonsistenz der DB Die Transaktion T1 will a und b um 10 erhöhen und die Transaktion T2 will a und b um 10 % erhöhen. Transaktion T1 a := a + 10 T2 a := a * 1,1 T2 b := b * 1,1 T1 b := b + 10 Beispiel: Phantom Transaktion T1 T2 T1 zählt alle Angestelltensätze von Berlinern fügt einen Angestellten ein, der in Berlin-Mitte wohnt zählt die Sätze von Angestellten aus Berlin-Mitte und bestimmt den prozentualen Anteil Seite 10

11 Serialisierbarkeit Das Prinzip der Serialisierbarkeit: serielle Abarbeitung serialisierbare Abarbeitung Definition: korrekt synchronisiert Ein paralleles System von Transaktionen ist korrekt synchronisiert, wenn es serialisierbar ist, d.h. wenn es irgendeine Folge derselben Transaktionen gibt die denselben Datenbankzustand dieselben Ausgabedaten der Transaktionen liefert. Beispiel: Die beabsichtigte Wirkung auf den Konten soll sein: a := a + 10 b := b c := c 10 Seite 11

12 TRANSAKTION 1 ( T1 ) TRANSAKTION 2 ( T2 ) read a read b a := a + 10 b := b + 10 write a read b write b read c b := b - 10 c := c - 10 write b write c Seite 12

13 ABLAUF 1 ABLAUF 2 T1 T2 T1 T2 read a read a read b read b a := a + 10 a := a + 10 b := b + 10 write a write a b := b + 10 write b read b read b write b read c b := b - 10 b := b - 10 read c c := c - 10 write b write b c := c - 10 write c write c Serialisierbarkeitsbedingungen: Bezeichnung: Zwei Operationen verschiedener Transaktionen stehen in Konflikt zueinander, wenn sie auf dasselbe Objekt zugreifen und mindestens eine der Operationen ein write ist. Seite 13

14 Serialisierbarkeitsbedingung (1. Form): Sei T ein Transaktionssystem der Form T 1,...,T n, modelliert durch die Menge der Logs {L 1,..,L m }. T ist serialisierbar, wenn eine totale Ordnung S für T existiert, so dass gilt: für jedes Paar T i,t j mit T i vor T j bezüglich S, ist in jedem Log O(T i ) vor O(T j ), wenn die Operationen O(T i ) zu O(T j ) in Konflikt steht. Serialisierbarkeitsbedingung (2. Form): Schedule-Einträge: (T : OP a) T ausführende Transaktion OP read, write a bezogenes Objekt Ein Pfeil (T i,t j ) U existiert, falls gilt (T i : write a) vor (T j : read a) (T i : read a) vor (T j : write a) (T i : write a) vor (T j : write a) Ein Transaktionsssystem ist dann serialisierbar, wenn der Graph G zyklenfrei ist. Seite 14

15 Beispiel: (T2: read b) vor (T1: write b), (T2: write b) vor (T1: write b) Pfeil von T2 nach T1. (T1: read b) vor (T2: write b) Pfeil von T1 nach T2. Der Graph ist zyklisch. T1 T2 Methoden zur Gewährleistung der Serialisierbarkeit Beobachtung der Schedule, beispielsweise in Graphenform. Präventive Synchronisationsverfahren Zwei-Phasen-Sperrprotokoll Grundidee: Exklusives Sperren würde Serialisierbarkeit gewährleisten. Seite 15

16 Es entstehen dadurch drei Probleme: 1. Die Möglichkeit von DEADLOCKS 2. Die Möglichkeit von permanentem Blockieren 3. Die Serialisierbarkeit muss gewährleistet sein Beispiel zu Problem 2: T2 wartet auf UNLOCK(a) von T1, T3 fordert etwas später ebenfalls LOCK(a) an und erhält vor T2 den Zuschlag, usw. => Dadurch kommt T2 schließlich nie zum Zug. Beispiel zu Problem 3: T1 will a := a + l0 und b := b + l0 T2 will a und b um 10 % erhöhen Transaktion Transaktion T1 LOCK(a) T2 LOCK(b) T1 a := a + 10 T2 b := b * 1.1 T1 UNLOCK(a) T2 UNLOCK(b) T1 LOCK(b) T2 LOCK(a) T1 b := b + 10 T2 a := a * 1.1 T1 UNLOCK(b) T2 UNLOCK(a) Seite 16

17 Arbeitsweise des Zwei-Phasen-Sperrprotokolls Das Zwei-Phasen-Sperrprotokoll garantiert Serialisierbarkeit paralleler Transaktionen. Arbeitsweise: Nach dem ersten UNLOCK einer Transaktion T darf von T kein LOCK mehr angefordert werden. Wachstumsphase: Schrumpfungsphase: Sperren setzen Sperren freigeben Sperren Wachstumsphase Schrumpfungsphase Zeit Seite 17

18 Realisierung von Synchronisationsverfahren Sperrobjekte Logische Objekte Physische Objekte Mögliche Sperrhierarchie: Datenbank Datei (oder Relation) Satz (oder Tupel) Sperren über Prädikate: Die zu sperrenden Objekte werden durch Bedingungen beschrieben. Sperre alle Angestelltensätze, für die gilt: WOHNORT = Berlin und ALTER > 25 Seite 18

19 Sperrmodi Die Unterscheidung in Lese- und Schreibsperren erlaubt eine höhere Parallelität. Lesesperre Schreibsperre nur lesenden Zugriff lesenden und schreibenden Zugriff Sperrprotokoll Den Rahmen bestimmt das Zwei-Phasen-Protokoll: 1. Preclaiming Alle Objekte der Transaktion werden vor Beginn der Verarbeitung gesperrt. Objekte Freigabephase Zeit Seite 19

20 2. Sperren bis Transaktionsende (EOT) Sperren werden einzeln aufgebaut aber erst bei Transaktionsende wieder abgebaut. Objekte EOT Zeit Anmerkung: Bei PRECLAIMING wird meist eine Obermenge der benötigten Sperrobjekte gesperrt, weil der Transaktionsablauf datenabhängig ist. SPERREN BIS EOT wird meist dann angewandt, wenn man das Fortpflanzen von Rollback verhindern will. Seite 20

21 DEADLOCK Zwei Transaktionen T1 und T2, die auf zwei Objekte a und b zugreifen, sperren sich gegenseitig. Die Folge ist ein DEADLOCK. T1 wartet auf T2 wegen b T2 wartet auf T1 wegen a Behandlung von DEADLOCK-Problemen: PRECLAIMING DEADLOCK-Entdeckung während der Laufzeit Der LOCK-Manager Der LOCK-Manager synchronisiert die einzelnen Transaktionen. Seite 21

22 Dabei ergeben sich drei Aufgabenbereiche: Das Verwalten von Sperren nach dem Zwei-Phasen- Protokoll. Die Verhinderung von dauerhaftem Blockieren. Die Behandlung von DEADLOCKS. Beispiel für eine Sperrtabelle: O T M 2 5 R 7 R 1 W Erläuterung: O = Objekt T = Transaktion M = Modus Seite 22

23 12.5 RECOVERY Fehlerklassen Bei einem Fehler befindet sich die DB in einem inkonsistenten Zustand. Die Wiederherstellung des korrekten DB-Zustandes durch das DBS wird RECOVERY genannt. Fehlerklassen: TRANSAKTIONSFFHLER SYSTEMFEHLER SPEICHERFEHLER Drei RECOVERY-Maßnahmen: 1. Rücksetzen einer Transaktion (ROLLBACK) 2. Neustart nach Systemzusammenbruch 3. Rekonstruktion Seite 23

24 ROLLBACK Grundlegende Annahme: Die Transaktion, die rückgängig gemacht werden soll, hat noch keine Sperren für veränderte Objekte freigegeben. Verwaltung der Informationen: LOGFILE UPDATE auf KOPIEN Realisierung in der Praxis Im wesentlichen erfolgt ROLLBACK über LOGFILES, die folgende Informationen beinhalten müssen: Marke für Beginn und Identifikation einer Transaktion Before Image für jedes veränderte Objekt: Marke für Transaktionsende Basisverfahren für ROLLBACK Für ROLLBACK wird das LOGFILE rückwärts gelesen. Für jedes Before Image mit Transaktionsidentifikation T wird der alte Objektwert in die DB zurückgeschrieben. Seite 24

25 Das Lesen der Beginnmarke für T beendet das ROLLBACK SYSTEM-NEUSTART Die beim Systemzusammenbruch noch nicht beendeten Transaktionen sind zu bestimmen und deren Änderungen sind dann über die LOGFILES rückgängig zu machen. Zeit t T3 Crash T2 T1 Problem: Wie weit muss das LOGFILE rückwärts gelesen werden? CHECKPOINTS begrenzen LOGFILES in bestimmten Zeitabständen Seite 25

26 Beispiel für eine Neustart-Situation: T1 T2 T3 T4 T5 CHECKPOINT: (T2,T4) Crash Das genaue Verfahren hängt ab von... dem Prozess der Datenabspeicherung in die Datenbank der Art des Checkpoints Arten von CHECKPOINTS CHECKPOINT im laufenden Betrieb CHECKPOINT bei Stillstand des Systems CHECKPOINT bei Transaktionsende Seite 26

27 REKONSTRUKTION Für die Rekonstruktion der DB nach Speicherfehlern benutzt man eine Kopie der DB (einen sogenannten dump). Das Erstellen von dumps bewirkt hohe Kosten Beispiel für eine Rekonstruktion: T1 Speicherfehler T2 dump T3 T5 T4 Seite 27