Czap, Grundlagen betrieblicher IS - 1

Transkript

1 Czap, Grundlagen betrieblicher IS Daten-Integrität 8.1 Integritätsaspekte Unter Integrität einer Datenbank versteht man alle die Aspekte, die mit der Erhaltung der Korrektheit der Daten in der DB zu tun haben. Eine Datenbank heißt im (engeren Sinne) konsistent, wenn die explizit angegebenen Integritätsbedingungen erfüllt sind. Der Begriff der Konsistenz von Daten wird häufig synonym mit dem Begriff der Integrität von Daten gebraucht. Im engeren Sinn bezeichnet Konsistenz allerdings die Widerspruchsfreiheit der Daten, weniger die technischen Aspekte, die zu ihrer Erhaltung zu berücksichtigen sind.

2 Czap, Grundlagen betrieblicher IS - 2 semantische Integrität: Um beabsichtigte oder unbeabsichtigte Falscheingaben von Daten zu vermeiden, sollte das DBS die Möglichkeit haben, die Korrektheit von Daten und die Zulässigkeit von Operationen zu überprüfen. Operationale Integrität: o Benutzer dürfen sich nicht gegenseitig stören, o Verhinderung der Ausgabe inkorrekter Daten o Sicherstellung, dass die Daten der DB nicht selbst inkorrekt werden. o enge Verknüpfung mit dem Problem einer Synchronisation paralleler Transaktionen Technische Fehler (System Crash) können zu inkorrekten Daten führen. Der Begriff Recovery (Wiederherstellung) umfasst technische Maßnahmen zur Wiederherstellung eines korrekten DB-Zustandes. Datenschutz dagegen fasst Maßnahmen zusammen, die einen unberechtigten Zugriff auf Daten und deren missbräuchliche Verwendung unmöglich machen bzw. verhindern. Darunter fallen auch sämtliche vom Gesetzgeber geforderte technische und organisatorische Maßnahmen im Umgang mit personenbezogenen Daten

3 Czap, Grundlagen betrieblicher IS Semantische Integrität Um beabsichtigte oder unbeabsichtigte Falscheingabe von Daten erkennen zu können, werden zusammen mit den Datendefinitionen Integritätsbedingungen im konzeptionellen Schema abgelegt. Sie beschreiben für einzelne Attribute, welche Werte erlaubt sein sollen, welche konkreten Beziehungen zwischen Objekten (Attribute/Felder, Tupel/Entities, Relationen/Entity-Typen) möglich sein sollen, welche Veränderungen zulässig sind usw. An Hand dieser Bedingungen kann dann eine Zulässigkeitsprüfung der Eingabe erfolgen. Bei einer großen DB kann die Zahl der Integritätsbedingungen außerordentlich groß werden. Deswegen ist abzuwägen zwischen - Laufzeitverlusten und Kosten für die Auswertung der Integritätsbedingungen und - Fehlerwahrscheinlichkeiten und Korrektheitsanforderungen in der betrachteten Umgebung implizite Integritätsbedingung: Typvereinbarung, funktionale Abhängigkeiten, Eindeutigkeit von Schlüsseln (UNIQUE INDEX) explizite Integritätsbedingung: Assertion zustandsbezogene Integritätsbedingungen veränderungsbezogene Integritätsbedingungen

4 Czap, Grundlagen betrieblicher IS Transaktionen Transaktion: Benutzerauftrag, der die DB von einem konsistenten Zustand wieder in einen konsistenten Zustand überführt. Grundlegender Begriff bei DBMS! Abgrenzungen von Transaktionen: gesamtes Benutzerprogramm (Batchbetrieb) einzelne SQL-Statements (Dialogbetrieb) explizite Abgrenzung durch Benutzer BEGIN_TRANS bzw. SET AUTOCOMMIT OFF END_TRANS bzw. COMMIT[WORK] /ROLL[BACK]

5 Czap, Grundlagen betrieblicher IS Probleme im Mehrbenutzerbetrieb Lost Update (write-write-konflikt) Transaktion T1 Zeitablauf Transaktion T2 start (T1) 1 r(x) 2 3 start(t2) 4 r(x) u(x) 5 6 u(x) w(x) 7 end(t1) 8 9 w(x) 10 end(t2) Die durch T1 verursachte Änderung des Wertes von x geht verloren.

6 Czap, Grundlagen betrieblicher IS - 6 Dirty Read (write-read-konflikt) Transaktion T1 start (T1) 1 r(x) 2 u(x) 3 w(x) 4 Zeitablauf Transaktion T2 5 start(t2) 6 r(x) 7 u(x) abort 8 9 w(x) 10 end(t2) Durch das Rücksetzen von T1 verwendet T2 einen falschen Wert.

7 Czap, Grundlagen betrieblicher IS - 7 Phantom-Problem (Unrepeatable Read) (read-write-konflikt) Transaktion T1 Zeitablauf Transaktion T2 Beispiel: T1 fasse die Buchungsbeträge x, y und z zu start (T1) 1 sum:=0 2 r(x) 3 r(y) 4 sum:=sum+x 5 sum:=sum+y 6 7 start(t2) 8 r(z) 9 z:=z w(z) 11 r(x) 12 x:=x w(x) 14 end(t2) r(z) 15 sum:=sum+z 16 end(t1) 17 einer Summe zusammen, T2 nehme eine Umbuchung von 10 Einheiten vom Konto z zu Gunsten Konto x vor. T1 berechnet für x+y+z einen falschen Wert, da z vor dem Lesen verändert wurde

8 Czap, Grundlagen betrieblicher IS Serialisierbarkeit Eine Transaktion T ist eine Folge (a i,x i ), i=1,..k, mit a i = Aktion (= r i bzw. w i ) und x i = Objekt. Transaktions-Log = Graph, mit Knoten-Menge A T = {(a i,x i ) einer Transaktion T} und Kanten-Menge P T, die die zeitlichen Abhängigkeiten ausdrücken. Der so gebildete Graph (A T,P T ) muß zyklenfrei sein. Beispiel: r 1 (x) r 1 (z) w 1 (x) w1(x) kann erst nach Ablauf von r1(x) und r1(z) stattfinden. Die Abarbeitungsreihenfolge von r1(x) und r1(z) ist nicht festgelegt.

9 Czap, Grundlagen betrieblicher IS - 9 Ein serieller Schedule einer Menge {T 1,T 2,..,T n } von Transaktionen ist eine beliebige Permutation T p(1),..,t p(n) (beliebige Anordnung ohne Wiederholungen) der Folge T 1,T 2,..,T n. Entsprechend dieser Anordnung T p(1),..,t p(n) werden die Transaktionen abgearbeitet. Eine Umordnung der Schritte (a i,x i ) innerhalb der einzelnen Transaktionen wird dabei nicht vorgenommen. Ein serieller Schedule ist eine Möglichkeit, die abzuarbeitenden Transaktionen in eine gemeinsame Ausführungs-Reihenfolge zu bringen. Er ist konfliktfrei, d.h. die Konsistenz der DB wird durch diese Ausführungsreihenfolge nicht beeinträchtigt. Eine Ausführungsreihenfolge S (Schedule S) einer Menge von Transaktionen {T1,T2,..,Tn} ist eine Folge S = (Ti,ai,xi) (i = 1,..,m), die durch (Ordnung erhaltendes) Mischen der einzelnen Schritte der Transaktionen Ti entstanden ist. D.h.: S besteht aus genau den Aktionen (a j,x j ), die in den einzelnen Transaktionen vorkommen, wobei die Reihenfolge in S der Aktionen (T i,a j,x j ), die aus T i kommen, mit der durch T i vorgegebenen Reihenfolge übereinstimmt.

10 Czap, Grundlagen betrieblicher IS - 10 Die Reihenfolge, mit der zwei Aktionen (T i,a i,x i ) und (T j,a j,x j ) eines Schedules S abgearbeitet werden, hat Auswirkungen auf das Ergebnis des Schedules genau dann, wenn gilt: a) Beide Aktionen operieren auf dem gleichen Objekt: x i = x j. b) Mindestens eine der Operationen ist eine Schreiboperation: a i = w oder a j = w. In diesem Fall spricht man von zwei konfliktären Aktionen. Äquivalenz zweier Schedules: Zwei Schedules können dann als äquivalent angesehen werden, wenn sie nach vollständiger Abarbeitung den gleichen Zustand der DB liefern. Dies wird immer dann der Fall sein, wenn bezüglich jedes Paares konfliktärer Aktionen, die gleiche Reihenfolge eingehalten wird.

11 Czap, Grundlagen betrieblicher IS - 11 Definition, Abhängigkeitsgraph D(S) eines Schedules S: Knotenmenge A S = {(T i,a i,x i ) i= 1,..,m} Kantenmenge P S = {((T i,a i,x i ),(T j,a j,x j )) 1 i<j m}, die folgenden Bedingungen genügt: (a) i<j, T i Tj (b) x i = x j = x (c) a i = w oder a j = w (d) es gibt kein k, i<k<j, T k T i, T k T j, (T k,a k,x) in S mit a k = w. Die Bedingung (d) ist in dem bei Vossen verwendeten Begriff eines Log für S nicht enthalten. Sie bedeutet, dass der Abhängigkeitsgraph D(S) (D = Dependency) nur echte Abhängigkeitsbeziehungen zwischen konfliktären Aktionen beinhaltet: Beispiele Abhängigkeitsgraphen zwischen (T i,r,x), (T k,r,x), (T j,w,x), zwischen (T i,w,x), (T k,r,x), (T j,w,x) und (T i,w,x), (T k,w,x), (T j,r,x);

12 Czap, Grundlagen betrieblicher IS - 12 Satz: Äquivalenz von Ausführungsreihenfolgen Zwei Schedules S1 und S2 der gleichen Menge von Transaktionen {T1,T2,..,Tn} sind genau dann äquivalent, wenn ihre Abhängigkeitsgraphen D(S1) und D(S2) identisch sind. Eine Ausführungsreihenfolge heißt serialisierbar, wenn sie äquivalent zu einem seriellen Schedule ist. Serialisierbare Ausführungsreihenfolgen sind damit integritätserhaltend. Beispiel: T1 = (w(x), w(y)), T2 = (w(x), w(y)). S 1 S 2 S 3 T 1 T 2 T 1 T 2 T 1 T 2 w(x) w(x) w(x) w(x) w(x) w(y) w(y) w(y) w(x) w(y) w(y) w(y) Da S 3 ein serieller Schedule ist, und D(S 1 ) = D(S 3 ) gilt, ist S 1 serialisierbar.

13 Czap, Grundlagen betrieblicher IS - 13 Offensichtlich gilt für einen seriellen Schedule S (T 1, T 2 Transaktionen aus S; x,y Datenbankobjekte), dass: (1) (T 1,x,T 2 ) D(S) impliziert (T 2,y,T 1 ) nicht aus D(S). (2) mittels T 1 < T 2 (T 1,x,T 2 ) D(S) für ein x ist eine lineare Ordnung auf der Menge T = {T 1,T 2,..,T n } der Transaktionen definiert. Da bei (1) und (2) nur der Abhängigkeitsgraph D(S) betrachtet wird, gelten beide Aussagen in gleicher Weise für einen serialisierbaren Schedule. Daraus folgt: (3) Eine Abarbeitungsreihenfolge S ist dann und nur dann serialiserbar, wenn es eine lineare Ordnung "<" auf der Menge der Transaktionen gibt, so dass für jedes Paar konfliktärer Aktionen (Ti,x,ai), (Tj,x,aj), mit i < j ( d.h. (Ti,x,ai) kommt vor (Tj,x,aj)), Ti < Tj gilt.

14 Czap, Grundlagen betrieblicher IS - 14 Abhängigkeitsbeziehung der Transaktionen bezüglich einzelner Objekte x der DB: Definiere auf der Menge der Transaktionen T = {T 1,T 2,..,T n } eines Schedules eine Relation " " : T i T j genau dann, wenn es ein x gibt, so dass T i liest x, T j schreibt x danach oder T i schreibt x, T j liest x danach oder T i schreibt x, T j schreibt x danach. (4) Der Schedule S ist serialiserbar, genau dann, wenn die Relation " " keinen Zyklus enthält, es also keine Folge gibt mit T i T j, T j T k, T k... T l, T l T i.

15 Czap, Grundlagen betrieblicher IS Das 2-Phasen-Sperrprotokoll Um Serialisierbarkeit eines Schedules, der vom Transaktions-Manager erzeugt wird, sicherzustellen, bedarf es neben den bislang betrachteten Aktionen a i = w (write) bzw a i = r (read) zusätzlicher Aktionen "lock" und "unlock". Damit durch lock(x) gesetzte Zugriffsbeschränkungen auf das Objekt x die angestrebte (Quasi-)Parallelverarbeitung nicht zu stark einschränken, ist es sinnvoll unterschiedliche locks zu ermöglichen: s-lock: Shared- bzw. Read-Lock gestattet einer Transaktion nur lesend zuzugreifen. e-lock: Exclusive- bzw. Write-Lock gestattet einer Transaktion schreibenden und lesenden Zugriff.

16 Czap, Grundlagen betrieblicher IS - 16 Ein Sperrprotokoll verknüpft die Verwendung von locks mit bestimmten Regeln: (1) Enthält die Transaktion T i eine Aktion der Form r i (x), dann ist vor Ausführung von r i (x) die Aktion s-lock(x) zu veranlassen. Enthält T i die Aktion w i (x), dann muß davor e-lock(x) ausgeführt werden. Die Sperre muß während der Dauer lesender oder schreibender Zugriffe bestehen. (2) Die Operation unlock(x) muß nach Ablauf sämtlicher lesender bzw. schreibender Operationen ausgeführt werden. (3) Sperren derselben Art auf dem gleichen Objekt werden innerhalb einer Transaktion nur einmal gesetzt. Sperren bezüglich des gleichen Objektes müssen kompatibel sein: Auf ein s-lock(x) kann kein e-lock(x) folgen. unlock(x) setzt voraus, dass zuvor x gesperrt wurde. (4) Kompatibilität von Sperren: (T i,s-lock(x)) und (T j,s-lock(x)), T i T j ist zulässig, nicht jedoch (T i,e-lock(x)) und (T j,e-lock(x)) bzw. (T i,e-lock(x)) und (T j,s-lock(x)).

17 Czap, Grundlagen betrieblicher IS - 17 Beispiel: T 1 : e-lock(x) T 2 : e-lock(x) 2. write(x) 2. write(x) 3. unlock(x) 3. e-lock(y) 4. e-lock(y) 4. unlock(x) 5. write(y) 5. write(y) 6. unlock(y) 6. unlock(y) mit der Ausführungsreihenfolge S: T 1 T 2 1. e-lock(x) 2. write(x) 3. unlock(x) 4. e-lock(x) 5. write(x) 6. e-lock(y) 7. unlock(x) 8. write(y) 9. unlock(y) 10. e-lock(y) 11. write(y) 12. unlock(y)

18 Czap, Grundlagen betrieblicher IS - 18 Die Kantenmenge des Abhängigkeitsgraph D(S)={(T 1,x,T 2 ),(T 2,y,T 1 )}. Folglich ist S nicht serialisierbar. Die Serialisierbarkeit von Ausführungsreihenfolgen kann sichergestellt werden, wenn alle erforderlichen Locks ausgeführt werden, bevor ein erstes Unlock abgesetzt wird: Ein Sperrprotokoll heißt Two-Phase (2 Phasen-Sperrprotokoll, 2 Phase-Locking, 2PL), wenn auf die erste unlock-operation keine weiteren lock-operationen folgen. Man kann dann zwei Phasen unterscheiden, die "growing phase", in der sämtliche benötigten Sperren gesetzt werden und die "shrinking phase", in der gesperrte Objekte wieder frei gegeben werden. Schedules, die durch ein 2PL-Sperrprotokoll erzeugt wurden, sind serialisierbar. Ein 2PL-Sperrprotokoll kann zu Deadlocks führen: Beispiel: T 1 : e-lock(x) T 2 : e-lock(y) 2. write(x) 2. write(y) 3. e-lock(y) 3. e-lock(x) 4. unlock(x) 4. unlock(y) 5. write(y) 5. write(x) 6. unlock(y) 6. unlock(x)

19 Czap, Grundlagen betrieblicher IS - 19 mit der Ausführungsreihenfolge S: T 1 T 2 1. e-lock(x) 2. write(x) 3. e-lock(y) 5. write(y) Verklemmung: Beide Transaktionen warten auf ein Ereignis, das nie eintreten wird. Gängige Strategie zur Deadlockbehandlung: Erkennen eines Deadlocks und Zurücksetzen (ROLLBACK) eines der beteiligten Transaktionen. Das Erkennen kann über einen sog. Wartegraphen geschehen, dessen Knoten aus den laufenden Transaktionen bestehen und dessen Kanten (T i,t j ) den Sachverhalt repräsentieren, dass T i auf ein unlock von T j warten muß. Genau dann, wenn dieser Wartegraph einen Zyklus hat, liegt ein Deadlock vor. Granularitätsebenen Bislang bestand die Vorstellung dass die DB-Objekte x,y bezüglich denen Locks abgesetzt werden, einzelne Sätze sind. Dies führt zu Effizienz-Problemen, wenn alle Sätze einer (großen) Relation gesperrt werden müssen, bzw. größere Bereiche oder auch die gesamte DB. Es kann desweiteren

20 Czap, Grundlagen betrieblicher IS - 20 zu Inkonsistenzen führen, wenn logische Konsistenz-Bedingungen zu beachten sind (logische Locks, Verwendung von Trigger zum Nachführen logisch abhängiger Updates). Es gibt deswegen Überlegungen hierarchisch strukturierte Sperrobjekte zu verwenden oder auch die Möglichkeit logische Locks vorzusehen. Das hier vorgestellte 2PL-Protokoll ist ein sog. pessimistisches Verfahren,. Bei den optimistischen Verfahren unterstellt man, dass in der Regel alles ordnungsgemäß ablaufen wird und überprüft erst beim "commit", ob Störungen eintreten konnten mit ggf. erforderlichem Zurücksetzen.

21 Czap, Grundlagen betrieblicher IS Recovery Recovery = Zurücksetzen der Datenbank in einen korrekten Zustand im Falle eines Systemabsturzes Gründe Systemabsturz verursacht durch einen Hardware- oder Softwarefehler. Verlust des Hauptspeicherinhalts Fehler des Sekundärspeichers (z.b. Headcrash). Verlust weiter Teile des Sekundärspeichers Anwendungsfehler, z. B. logische Fehler in Anwendungsprogrammen, die bei einzelnen Transaktionen einen ordnungsmäßigen Abschluss verhindern. Katastrophen (Feuer, Überschwemmungen, Erdbeben etc.) Nachlässigkeit oder unbeabsichtigtes Zerstören von Daten oder Datenträgern durch Benutzer oder Bedienpersonal Sabotage bzw. bewusstes Zerstören von Daten, Datenträgern oder Software Im Wesentlichen zwei Konsequenzen: Verlust von Hauptspeicherinhalten sowie Verlust/Zerstörung des Datenträgers (Platte), auf dem sich die Datenbank befindet.

22 Czap, Grundlagen betrieblicher IS Transaktionen und Recovery Basiseinheit für Recovery ist der Begriff Transaktion. Der Recovery Manager muss zwei der vier ACID-Eigenschaften. nämlich Atomicity und Durability garantieren: Nach einem Systemcrash müssen sämtliche Aktionen einer Transaktion permanent gemacht werden oder ungeschehen. Schritte beim Lesen read(x) eines Wertes aus einer Datenbank z.b. x = Kontostand, Konto 4711 Finde die Adresse des Daten-Blocks auf der Platte, die den gesuchten Satz 4711 enthält Übertrage den Block in den Datenbankpuffer des Hauptspeicher Kopiere den gesuchten Wert Kontostand des Satzes Konto 4711 in die Variable x. Schritte beim Schreiben des Wertes x in eine Datenbank z.b. x = Kontostand, Konto 4711 Finde die Adresse des Daten-Blocks auf der Platte, die den gesuchten Satz 4711 enthält Übertrage den Block in den Datenbankpuffer des Hauptspeicher Kopiere den Wert x in den Datenbankpuffer als Kontostand des Satzes Konto Schreibe den Datenbankpuffer auf Platte zurück. Änderungen werden erst durch das Zurückschreiben (sog. Flushing) des Datenbankpuffers permanent gemacht (Force-writing heißt das explizite Auslösen des Zurückschreibens des DB- Puffers)

23 Czap, Grundlagen betrieblicher IS - 23 Aktionen Ein Fehler (Crash), der nach dem Schreiben in den DB-Puffer aber vor dem Flushing entsteht, wird dahingehend geprüft, ob die betroffene Transaktion ordnungsgemäß beendet wurde (commit) oder nicht. Redo (Roll forward) Wurde Commit abgesetzt, dann müssen die Änderungen nur noch permanent gemacht werden: Redo Roll back (Undo) Im anderen Fall müssen sämtliche Aktionen der Transaktion zurückgesetzt werden, um atomicity zu garantieren: undo (rollback).

24 Czap, Grundlagen betrieblicher IS Buffer Management Der Buffer-Manager liest benötigte Seiten/Blöcke von der Platte in den DB-Puffer. Wenn dieser gefüllt ist, muss ein Austausch der Seiten erfolgen, d.h. nicht länger benötigte Seiten müssen zurückgeschrieben werden. Zwei Variable, pincount und dirty pro Seite pincount: Zählt die Anzahl der Transaktionen, die die Seite (per lock) angefordert haben. Unlock reduziert pincount um 1. Dirty hat den Wert 0, wenn die Seite unverändert ist und eine Wert >0, falls Änderungen vorgenommen wurden. Nur Seiten, bei denen dirty gesetzt ist und pincount==0, werden in der Regel zurückgeschrieben. Alternative Vorgehensweisen Steal-policy: Der Buffer-Manager kann eine Seite zurückschreiben, bei der pincount > 0 ist. Man sagt, der Buffer-Manager stiehlt die Seite von den aktiven Transaktionen. Alternativ: no-steal. (no steal: kein Undo bei abgebrochenen Transaktionen. Steal: Vermeidung großer DB-Puffer) Force-policy: Unmittelbar dann, wenn eine Transaktion ihre Aktivitäten beendet hat, wird eine Seite zurückgeschrieben. Alternativ: no-force. (force: kein Redo bei committed Transaktionen. Noforce: Reduktion der Schreibaktivitäten bei mehrfachem update der gleichen Seite.) Üblich: Steal, no-force

25 Czap, Grundlagen betrieblicher IS Hilfsmittel für das Recovery Backup-Mechanismus: Erstellen von Kopien der Datenbank und des Log-files auf regelmäßiger Basis. Unterscheide: Vollständige Kopie bzw. Kopie der Änderungen. Verwendung von Bändern. Lagerung außerhalb der Geschäftsräume Log-File (Journal) Siehe Beispiel. Da das Log-File unverzichtbar ist für den Recovery-Prozess, wird es z.t. dupliziert oder auch tripliziert. Speicherung heute in der Regel im Hauptspeicher. Problem: Volumen. Tägliche Logfiles in der Größenordnung von 10 GB sind nicht selten. Deswegen: Unterteilung in zwei Files, von denen eines auf Platte ausgelagert wird. Das Log-File ist ein potentieller Engpass bei DBMS. Die Geschwindigkeit mit der es beschrieben werden kann, ist deswegen relevant für die Performanz des Systems. Checkpoint Finden in festgelegten Zeitabständen statt (etwa alle Minuten). Operationen: o Schreiben aller Sätze der Log-Datei auf Platte o Schreiben der geänderten Blöcke des DB-Puffers auf Platte o Schreiben eines Satzes checkpoint mit den aktiven Transaktionen in die Log-Datei.

26 Czap, Grundlagen betrieblicher IS - 26 Beispiel Log-Datei Tid Time Operation Objekt Before After pptr nptr image image T1 10:12 START 0 2 T1 10:13 UPDATE STAFF SL21 (old (new 1 8 value) value) T2 10:14 START 0 4 T2 10:16 INSERT STAFF SG37 (new 3 5 value) T2 10:17 DELETE STAFF SA9 (old 4 6 value) T2 10:17 UPDATE PROPERTY (old (new 5 9 PG16 value) value) T3 10:18 START 0 11 T1 10:18 COMMIT :19 CHECKPOINT T2, T3 T2 10:19 COMMIT 6 0 T3 10:20 INSERT PROBPERTY (new 7 12 PG4 value) T3 10:21 COMMIT 11 0

27 Czap, Grundlagen betrieblicher IS Techniken des Recovery Wiedereinspielen der letzten Backup-Kopie + Verwendung der Log-Datei Verwendung der Before-Images und After-Images der Log-Datei Deferred Update Die Veränderungen einer Transaktion werden erst dann auf Platte geschrieben, wenn die Transaktion ihr commit abgesetzt hat. Schritte: Schreiben eines Satzes Start der Transaktion in die Logdatei. Bei jeder Schreiboperation in der DB Erstellung eins Satzes mit der Aktualisierungsinfo in der Logdatei. Kein Schreiben dieser Info in den DB-Puffer oder die DB zu diesem Zeitpunkt. Wenn die Transaktion das commit absetzt, Schreiben der commit-info in die Logdatei. Anschließend Schreiben der Sätze dieser Transaktion aus der Logdatei auf Platte. Beenden der Transaktion. Anschießend Schreiben der Änderungen in die DB (auf Platte). Beim Abort der Transaktion: Ignoriere sämtliche Sätze dieser Transaktion. Im Falle eines Crashs: Redo all der Transaktionen, die nach dem letzten Checkpoint begonnen und per commit beendet wurden. Transaktionen, deren Start vor dem letzen Checkpoint war, müssen per undo ungeschehen gemacht werden und neu aufgesetzt werden.

28 Czap, Grundlagen betrieblicher IS - 28 Die erforderlichen Systemaktivitäten sollen an folgendem Beispiel verdeutlicht werden. T 1 T 2 T 3 T 4 T 5 t 1, Checkpoint t 2, Crash Zeit T 1 ist vor dem letzten Checkpoint t 1 beendet und damit permanent gemacht. T 2 und T 3 setzten vor dem Crash ihr commit ab. Da aber unklar ist, ob die Änderungen in die DB übertragen wurden, muss ein Redo dieser Aktivitäten erfolgen. T 4 und T 5 müssen komplett wiederholt werden. Da die Änderungen aber noch nicht in die DB übertragen wurden, muss nur ein RESTART erfolgen. ( No-Undo/Redo Felhlerprotokoll!)

29 Czap, Grundlagen betrieblicher IS Immediate Update Die Veränderungen einer Transaktion werden unmittelbar auf Platte geschrieben, ohne dass das commit abgewartet wird. Schritte: Schreiben eines Satzes Start der Transaktion in die Logdatei. Bei jeder Schreiboperation in der DB Erstellung eins Satzes mit der Aktualisierungsinfo in der Logdatei. Anschließendes Schreiben dieser Änderung des DB-Inhalts in den DB-Puffer. Update des XCDB-Puffe5rs erfolgt beim nächsten Flushing. Wenn die Transaktion das commit absetzt, Schreiben der commit-info in die Logdatei. Wichtig: die Log-Info muss vor dem Schreiben in die DB erfolgen, write-ahead-log-protokoll. Andernfalls wäre ein Recovery nicht möglich, wenn ein Crash vor dem Schreiben der log-info erfolgt. Im Falle eines Crashs: Transaktionen, für die es keinen commit-satz in der Logdatei gibt, waren notwendigerweise aktiv zum Zeitzpunkt des Crashs und müssen nach einem Undo wiederholt werden. Verwendung der Before-Images. Redo all der Transaktionen, die nach dem letzten Checkpoint begonnen und per commit beendet wurden. Verwendung der After-Images.