Recovery AIFB SS (1/8) Sicherungspunkte (Checkpoints) (1/8) (1) Transaktions-Orientierte Sicherungspunkte Transaction-Oriented Checkpoint (TOC) Um den Aufwand der Recovery bei einem Systemausfall zu begrenzen, werden sogenannte Sicherungspunkte benutzt: Bei der Erzeugung eines solchen Sicherungspunktes wird ein gewisser Konsistenz-Zustand erreicht, so dass die Recovery- Maßnahme (R2 und z.T. R3) maximal bis zu diesem Zeitpunkt zurückgehen muss. Bei Anwendung einer FORCE-Strategie befindet sich die Datenbank bei Transaktionsende bezüglich der abgeschlossenen Transaktionen immer in einem konsistenten Zustand.

Recovery AIFB SS (2/8) Sicherungspunkte (Checkpoints) (2/8) Somit kann jedes Transaktionsende als Sicherungspunkt angesehen werden. Begrenzt nur R2-Recovery, nicht R3. Nachteil: Hohe E/A-Kosten; in größeren Systemen nicht anwendbar. T1 T2 T3 SP1SP2 Crash Zeit

Recovery AIFB SS (3/8) Sicherungspunkte (Checkpoints) (3/8) (2) Transaktions-Konsistente Sicherungspunkte Transaction-Consistent Checkpoint, TCC Zu best. Zeitpunkten werden alle veränderten Seiten aus dem Puffer in die Datenbank geschrieben. Um die (Transaktions-)Konsistenz zu gewährleisten, dürfen während dieser Zeit keine Änderungstransaktionen aktiv sein, d. h.: Bevor ein TCC generiert wird, muss gewartet werden, bis alle Änderungstransaktionen beendet sind. Neue Änderungstransaktionen werden erst zugelassen, wenn die Erstellung des TCC beendet ist.

Recovery AIFB SS (4/8) Sicherungspunkte (Checkpoints) (4/8) Generierung SP T1 T2 T3 T4 Wartezeit für neue TAs Crash Sowohl R2-, als auch R3-Recovery werden auf den Sicherungspunkt beschränkt. Bei größeren Systemen insbesondere mit großen Datenbankpuffern dauert die Generierung eines TCC viel zu lange und ist somit nicht praktikabel.

Recovery AIFB SS (5/8) Sicherungspunkte (Checkpoints) (5/8) (3) Aktions-Konsistente Sicherungspunkte Action-Consistent Checkpoint, ACC Eine Transaktion kann als Folge von Operationen betrachtet werden. Die Generierung eines ACC erfolgt ähnlich wie die des TCC, es wird aber nur noch gewartet, bis keine Änderungsoperation mehr aktiv ist. Der Betrieb wird dadurch weit weniger beeinträchtigt. Es wird nun allerdings nur ein aktionskonsistenter Zustand festgehalten, d.h. ein Zustand, der durch vollständige Operationen herbeigeführt wurde. Ein ACC ist somit nur eine Grenze für die R2-Recovery. R3-Recovery muss global durchgeführt werden.

Recovery AIFB SS (6/8) Sicherungspunkte (Checkpoints) (6/8) Signal: SP-Beginn T1 T2 T3 T4 T5 T6 Crash Generierung Wartezeit Der Datenbankbetrieb wird nicht so lange unterbrochen wie bei der Erzeugung eines TCC. Der E/A-Aufwand ist aber immer noch hoch. t

Recovery AIFB SS (7/8) Sicherungspunkte (Checkpoints) (7/8) Fuzzy Checkpoints Um den Aufwand weiter zu verringern, werden an einem Sicherungspunkt nicht die Datenbankseiten in die Protokolldatei geschrieben, sondern nur Informationen über diese Seiten. Es wird also festgehalten, welche Seiten zu diesem Zeitpunkt im Datenbankpuffer sind und welche von diesen Seiten geändert wurden. So kann festgestellt werden, welche Seiten bei einem System-Fehler noch im Puffer waren und Daten von vollendeten Transaktionen enthielten. Nur für R2-Recovery nützlich.

Recovery AIFB SS (8/8) Sicherungspunkte (Checkpoints) (8/8) Wenn hot-spots vorhanden sind, muss beim Wiederholen trotzdem die temporäre Protokolldatei bis weit zurück durchsucht werden, um das entsprechende After-Image zu finden. Deshalb Verfeinerung: Wenn eine Seite bei zwei aufeinanderfolgenden Sicherungspunkten immer noch im Puffer ist, dann wird sie in die Protokolldatei ausgeschrieben. Begrenzung der R2-Recovery auf die letzten beiden Sicherungspunkte. Messungen haben ergeben, dass der Aufwand für einen Fuzzy Checkpoint bei etwa 3% des Aufwandes für einen ACC liegt.