Vorlesung #6 Fehlerbehandlung

1. Vorlesung #6Fehlerbehandlung

2. „Fahrplan“ • Besprechung der Übungsaufgaben • Übungsblatt #4 • Übungsblatt #5 • Motivation • Fehlerklassifikation und Speicherhierarchie • Protokollierung (Log-Datei) • Wiederanlauf nach einem Fehler • Zurücksetzen einer Transaktion • Sicherungspunkte • Recovery nach dem Verlust der materialisierten Datenbank - Backup/Recovery Szenarien • Fazit und Ausblick Vorlesung #7 Vorlesung #6 - Fehlerbehandlung

3. Motivation • Die in der Datenbank gespeicherten Daten haben immensen Wert für ein Unternehmen/Behörde • Man kann Fehler nie ausschließen • Software - Bugs • Stromausfall, Überflutung • Betriebsystemfehler usw. • Recoverykomponente des DBMS sorgt für • den Wiederanlauf nach einem „Crash“ • Rekonstruktion des jüngsten konsistenten Datenbankzustands Vorlesung #6 - Fehlerbehandlung

4. Fehlerklassifizierung Es gibt drei Fehlerarten • Lokaler Fehler einer Transaktion • expliziter Abort – ROLLBACK Anweisung • impliziter Abort – z.B. Konsistenzverletzung oder system-gesteuert beim Vorliegen eines Deadlocks (Verklemmung) • Fehler mit Hauptspeicherverlust • Stromausfall • Betriebsystemabsturz • Fehler mit Hintergrundspeicherverlust • Platten-Crash • Feuer, Erdbeben, Überflutung - die Platte wird zerstört • Platten-Diebstahl, versehentliches Löschen, usw. Vorlesung #6 - Fehlerbehandlung

5. Lokaler Fehler einer Transaktion • Alle Änderungen, die von der zurückzusetzenden, noch aktiven TA verursacht wurden, müssen rückgängig gemacht werden • Lokales Zurücksetzen nennt man lokales „Undo“ • Diese Art von Fehlern tritt sehr häufig auf, so dass die Recoverykomponente des DBMS innerhalb weniger Millisekunden den Fehler beheben soll • Aus Effizienzgründen darf das System während der Fehlerbehebung nicht für andere Transaktionen gesperrt werden • In der Praxis automatisch von DBMS abgefangen Vorlesung #6 - Fehlerbehandlung

6. Fehler mit Hauptspeicherverlust • Betriebsystem- oder DBMS-Absturz, Stromausfall • Treten relativ selten auf (Stunden- bzw. Tage-Bereich) • ACID verlangt, dass alle nicht erfolgreich abgeschlossene Transaktionen zurückgesetzt werden (Globales Undo), und alle erfolgreich abgeschlossene TAs dauerhaft in die Datenbasis festgeschrieben werden (Globales Redo)  detailliert in den Folien von Kemper) • Recovery soll in Minutenbereich erfolgen, wird mit Hilfe einer Protokoll-Datei (Log, Redo-Log) realisiert • In der Praxis automatisch von DBMS abgefangen Vorlesung #6 - Fehlerbehandlung

7. Fehler mit Hintergrundspeicherverlust • Zerstören der Daten auf einer/mehreren Platte aus verschiedenen Gründen (Ausfall, Feuer, menschliches Versagen wie format C:\, rm *, usw.) • In der Praxis sehr wichtig, weil es von DBMS nicht automatisch abgefangen wird. (alle anderen Fehler werden vom DBMS automatisch abgefangen) • Treten relativ selten auf (monatlich oder jährlich) aber haben verheerende Folgen • Sehr wichtig: Backup/Recovery Strategie und Implementierung (etwas detaillierter Folien #8 - #11) • ... weiter Kemper Kapitel 10 Vorlesung #6 - Fehlerbehandlung

8. „Media Recovery“ in der Praxis • Analyse - es wird festgestellt, welche Archiv-Kopien (Sicherungen, Backups) für die Wiederherstellung der Datenbasis in den jüngsten transaktionskonsistenten Zustand benötigt werden (Teile von Datenbasis-Archiv und Log-Archiv) • Restore – erforderliche Backups werden eingespielt, kann sehr lange oder sehr kurz dauern, je nach eingesetztem Archivierungssystem (z.B. Platte vs. Bänder) • Recovery – DBMS Wiederanlauf, bei dem anschließend die archivierten Log-Dateien an die rekonstruierte Datenbasis angewendet werden können Vorlesung #6 - Fehlerbehandlung

9. „Media Recovery“ in der Praxis (2) • Der wichtigste Recovery-Schritt ist aber vergessen ... • ... die Voraussetzung für das Media Recovery • Backups !!! • Logische Backups (Änderungsoperationen) • Änderungsoperationen • Datenbankobjekte • Physische Backups (DB Dateien) • Offline (Cold Backups) – bei heruntergefahrener Datenbank • Online - im laufenden Betrieb • Logische Fehler kann man im Mehrbenutzerbetrieb nur mit Hilfe von logischen Backups beheben! Vorlesung #6 - Fehlerbehandlung

10. „Media Recovery“ in der Praxis (3) • Beispiel: Oracle Backup/Recovery Verfahren • Logische Backups • Log-Archiv kann mit dem Tool „Log Miner“ auf der Transaktionsebene betrachtet werden • Datenbank-Exports/Import – Tabellen, Views, PL/SQL Programme usw. können aus der Datenbank extrahiert werden obwohl sie physisch auf mehreren Dateien verteilt werden können • Physische Backups • Hot bzw. Online Backups – im laufenden Betrieb • Cold bzw. Offline Backups • Voraussetzung – Kenntnisse über DBMS-Architektur Vorlesung #6 - Fehlerbehandlung

11. SQL für Backup/Recovery • Kein SQL Standards, sondern eigene SQL-Kommandos oder spezielle Tools mit ihren proprietären Sprachen • Beispiele (Oracle): Oracle SQL Kommandos ALTER DATABASE RECOVER STANDBY DATAFILE '/finance/stbs_21.f' UNTIL CONTROLFILE; ALTER DATABASE RECOVER AUTOMATIC UNTIL TIME '2001-10-27:14:00:00'; RMAN Commandos: CATALOG DATAFILECOPY '/tmp/users01.dbf'; Vorlesung #6 - Fehlerbehandlung

12. Ausblick Vorlesungen #7, #8 • Mehrbenutzersynchronisation • Fehler beim unkontrollierten Mehrbenutzerbetrieb ( • „lost update“ • „dirty read“ • „Phantom“ • Serialiesierbarkeit • Sperrbasierte Synchronisation („Locks“) • Verklemmungen („Deadlocks“) • Hierarchische Sperrgranulate (Sperren auf der Satz-, Seiten oder Datenbasis-Ebene) • Zeitstempelbasierte Synchronisation („Time Stamp“) • Synchronisation von Indexstrukturen • Mehrbenutzersynchronisation in SQL-92 Standard Vorlesung #6 - Fehlerbehandlung

13. Vorlesung #6Ende