|
1.1. Datenspeicher ist defekt:r /
r />
Die Daten auf einem defekten Datenspeicher sind verloren. Gegen diesen Verlust schützt das regelmäßige Sichern der Datenbestände auf einen externen Datenträger (zB: Streamer). Es muß beachtet werden, daß die Datenbank während der Sicherung geschlossen ist (sonst erhält man eine inkonsistente Datenbanksicherung). Da eine komplette Sicherung zeit- und platzaufwendig ist und andererseits die Daten seit der letzten Sicherung verloren wären, verwendet man Logfiles.
Das Logfile ist vergleichbar mit einem Journal, in welchem laufend mitprotokolliert wird, wer, was, wann, wo in welcher Datei verändert hat. Bei Datenverlust wird zunächst die letzte Sicherung wiederhergestellt und anschließend können alle Veränderungen seit der letzten Sicherung gemäß den Einträgen im Logfile nachvollzogen werden (= Forward-Recovery)
Folgende Regeln sollten für Logfiles beachtet werden:
. Logfiles und Datenbestand, der durch das Logfile aufgezeichnet wird, niemals auf dem gleichen
Datenträger sichern. Im Fehlerfall wären der Datenbestand und das Logfile defekt.
. Logfiles möglichst doppelt (auf zwei getrennten Platten= führen (= Dual Logging)
. Logfiles werden wie andere Daten gesichert.
Wenn ein Datensatz geändert wird, so werden im Logfile folgende Informationen gespeichert:
- Before Image:
Zustand des Datensatzes vor der Änderung (für Rollback benötigt um alten Zustand wiederherstellen zu können)
- After Image:
Zustand des neuen Datensatzes nach der Änderung (wird für Forward Recovery benötigt)
- Userprozessdaten:
Um später die Änderungen zuordnen zu können, werden noch Datum, Uhrzeit, User-ID und Prozess- ID gespeichert.
Kriterien, wie häufig gesichert werden soll:
. Größe der Datenbank
. Häufigkeit des Änderns
Generell kann man sagen, daß man jenen Teil öfters sichert, der kleiner ist; d.h. ist die Datenbank sehr groß und es wird kaum etwas geändert, so empfiehlt es sich die Logfiles in kürzeren Zeitabständen als die gesamte Datenbank zu sichern. Ist es genau umgekehrt, so soll die Datenbank häufiger gesichert werden als die Logfiles. Wie oft Datenbestände und Logfiles zu sichern sind, hängt auch von der geforderten Wiederherstellungszeit ab.
Theoretisch könnte man mit dem Logfile alles Userprozesse genau in den Zustand versetzen, den sie vor dem Absturz hatten. Leider können meist die laufenden Programme ebenfalls an die Absturzstelle gesetzt werden.
Index-Recovery:
Gelegentlich können Fehler in den Verkettungen der Indizes auftreten. In solchen Fällen wird der Index gelöscht und neu angelegt (zusätzlich bewirkt dies eine Reorganisation). Dieses Vorgehen ist möglich, da der Index eine redundante Speicherung der Schlüsseldaten darstellt.
Beispiel für Sicherung:
Es wurden jeweils am Beginn des Monats Sicherungsbänder angelegt. Erfolgt nun ein Absturz am 25.5.96, so muß die Datenbank wiederhergestellt werden:
b1 a1
SB 1 SB 2 SB 3
b2
Zeit
1.3.96 1.4.96 1.5.96
26.5.96 Absturz
1. Einspielen des Sicherungsbandes 3 vom 1.5.96 (a1)
2. Einspielen des aktuellen Logfiles zur Rekonstruktion der Datenbank bis zum Zeitpunkt des Absturzes (a2)
Wenn das Sicherungsband 3 defekt ist, so ist folgendes zu tun:
1. Einspielen des Sicherungsbandes 2 vom 1.4.96 (b1)
2. Einspielen des Logfiles vom 1.4.92 bis 1.5.96 um dem Zustand der Datenbank am 1.5.96 wiederher stellen zu können (b2)
3. Einspielen des aktuellen Logfiles bis zum Zeitpunkt des Absturzes (b3 = a2)
Wenn das aktuelle Logfile (vom 1.5.96 bis zum 26.5.96) defekt ist, so kann man nur noch den Zustand vom 1.5.96 wiederherstellen. Alle Änderungen vom 26.5.96 wären somit verloren.
1.2. Applikation ist abgestürzt:
Bei diesem Problem ist der Datenspeicher physisch in Ordnung, doch er kann logisch beschädigt sein. Der Schaden besteht aus durchgeführten Änderungen, die möglicherweise nicht abgeschlossen wurden. Der User kann die Änderungen nicht mehr zurücknehmen, da seine Applikation abgestürzt ist.
In einem einfachen System wird der Operator verständigt, der durch entsprechende Befehle die Änderungen des jeweiligen Prozesses zurücknimmt. Das System liest dann im Logfile nach, welche Änderungen seit dem letzten Synchpoint (Momentaufnahme des Systems) durch den User verursacht wurden und macht diese Änderungen rückgängig (= Backward-Recovery)
In größeren Systemen überprüft das Datenbanksystem in regelmäßigen Abständen, ob noch eine Verbindung zu den Usern besteht. Falls nicht, so wird automatisch der Recovery-Vorgang eingeleitet.
1.3. Datenbanksystem oder Betriebssystem ist abgestürzt:
Bei einem Systemabsturz, Stromausfall, ... gehen keine Daten verloren, da der Datenträger nicht beschädigt werden. Die Datenbank befindet sich somit in einem inkonsistentem Zustand, da offene Transaktionen nicht abgeschlossen wurden.
Da beim ordnungsgemäßen Öffnen und Schließen Einträge im Logfile gemacht werden, erkennt das System einen Systemabsturz,... und beginnt mit dem Recovery. Dabei wird im Logband überprüft welche Transaktionen offen waren, d.h. für welche kein Commit vorgefunden wurde. Für diese Transaktionen wird ein Backward-Recovery durchgeführt.
1.4. Programmfehler (kein Absturz):
Programmfehler sind nur sehr schwer erkennbar (zB: Rundungsfehler). Das Suchen eines solchen Fehlers ist sehr aufwendig, da der Programmfehler bis zu seinem ersten Auftreten rückverfolgt werden muß. Ist der Programmfehler eliminiert muß die Datenbank rekonstruiert werden.
Dazu kann unter Umständen das Logfile verwendet werden, welches anzeigt, welche Daten von dem fehlerhaften Programm bearbeitet wurden. Sicherung zurückspielen, Logfile bis zum 1. Auftreten, danach eventuell korrigiertes Logfile einspielen. Probleme liegen in der Fehlerfortpflanzung, da die fehlerhaften Daten inzwischen von anderen Programmen weiterverarbeitet wurden.
|
