Recovery Flashcards
Definition Recovery
Wiederherstellung von Daten bei schweren Fehlern
Beispiele Hardwarefehler
Stromausfall, Wackelkontakt, Festplattenausfall, Brand, Anschlag
Beispiele Softwarefehler
Fehler in Datenbank-Software, Netz-Software, Anwendungsprogramm
Vorsorgemaßnahmen
1) Hardware-Einkauf (lange Standzeiten, Zertifizierungen)
2) Software-Einkauf (Komponenten aufeinander abstimmen, zertifizierte Software, Updates vorher testen)
3) Sicherung (tägliche Differenzsicherung, sichere Aufbewahrung der Sicherungen, einmal pro Woche: Komplettsicherung)
Zeitpunkt der Sicherung
- nächtliche Sicherungen stören Regelbetrieb nur geringfügig
- erhebliche Störung des Regelbetriebs wegen Erstellung des Protokolls und der Speicherung in Datei (Logdatei)
Voraussetzungen sicherer Datenbankbetrieb
- Datenbank und Logdaten befinden sich auf zugreifbaren, externen nichtflüchtigen Medien
- Datenbankdaten werden im Arbeitsspeicher (Datenbank-Cache) zwischengespeichert
- Schreiben der Daten im Datenbank-Puffer
- Aktualisierung der Datenbank erfolgt asynchron
Metadaten
- Daten, die Informationen zu und Zustände über eine Datenbank merken
- aktuelle Metadaten werden im Arbeitsspeicher gehalten
- z.B. Informationen zu laufenden Transaktionen, Zustand aktuelle Logdaten, Zustände Synchronisationsmechanismen, Aktualität und Gültigkeit der Daten im Datenbankpuffer
Datenbankpuffer
- bereits gelesene Daten müssen nicht nochmals gelesen werden (Pufferung)
- Daten werden bei Bedarf von Festplatte geholt oder bei Engpässen im Puffer in DB geschrieben
- Daten werden ausschließlich im Puffer bearbeitet (keine ständigen I/Os)
- Änderungen werden parallel in Logdateien geschrieben und persistent gesichert
Before-Image
- zu ändernden Daten bzw. Abbild bevor geändert wurde
- wird bis Transaktionsende gespeichert
After-Image
- die geänderten Daten bzw. Abbild, nachdem geändert wurde
- wird bis zur nächsten Sicherung gespeichert
Schwächen des einfachen Transaktionsbetriebs
- Daten von lange laufen TAs werden im Arbeitsspeicher gehalten
- Absturz während des Schreibens der geänderten Daten am TA-Ende: Komplexe Recovery (welche Daten wurden schon geschrieben und welche nicht)
- Schreiben am TA-Ende kann zu punktuellen Überlastungen führen
- Schreiben zu TA-Ende ist inflexibel
TA-Betrieb mit Pufferung
- hochperfomant (I/O-Verkehr wird minimiert, mehrmals geänderte Daten müssen nicht jedes Mal geschrieben werden)
- Konsistenz der Daten hängt wesentlich von den Logdateien ab (Dauerhaftigkeit nur dank Logdateien gesichert)
Struktur Before- und After-Images
- Logdateien (enthalten nur Änderungen) ebenfalls Blockstruktur
- viele Änderungen zu einem Block zusammengefasst
- geringer Schreibverkehr; zusätzlich: gestreamt
Inhalt Logdateien
- alle Before- / After-Images mit Transaktionsnummer und Zeitstempel
- dazugehörige Metadaten (Transaktionsende, gehaltene Sperren)
- Logdateien müssen nicht gleich lange aufbewahrt werden
Undo-Log (in speziellem Datenbankbereich)
- Logdatei, die alle Before-Images und dazugehörige Metadaten enthält
- muss nur bis TA-Ende aufgehoben werden
- wird für Rollback benötigt
- wird zyklisch überschrieben
- muss auf Festplatte stehen, bevor Daten nicht abgeschlossene TA in die DB geschrieben werden
Redo-Log (“Lebensversicherung” des aktuellen Datenbestands)
- Logdatei, die alle After-Images und dazugehörige Metadaten enthält
- Redo-Log muss bis zur nächsten Sicherung aufgehoben werden
- wird ausschließlich sequentiell beschrieben
- werden auf externem Medium angelegt
- häufig mit Raid I gespiegelt (Sicherheit)
Least Recently Used (LRU) Algorithmus
- Verdrängung von Seiten, wenn DB-Puffer voll
- Verdrängung der Seite, die am längsten nicht mehr verwendet wurde
- Modifikation: zyklische Freigabe
Hot Spots
- Daten, auf die ständig zugegriffen wird (nie verdrängt)
- gute Performance (weniger I/Os)
- aufwendige Recovery (Nachvollziehen der Änderungen zu Hot Spots)
- viele Metadaten (kein zyklisches Überschreiben der Metadaten möglich)
Checkpoints
- Zeitpunkte, wo alle geänderten Daten zwangsweise in DB geschrieben werden
- viele Metadaten können gelöscht werden
- im Recoveryfall müssen nur Redo-Daten seit letztem Checkpoint nachvollzogen werden
- punktuell sehr viel I/Os -> Behinderung laufender TAs
- bei jedem Checkpoint steigen die Antwortzeiten
Häufigkeit von Checkpoints
- zeitgesteuert
- ereignisgesteuert (z.B. wenn Redo-Log voll)
- optimale Parameter zur Einstellung: Zeitintervall, Größe des Redo-Logs