Vorlesung #10 Fehlerbehandlung

Vorlesung #10 - Fehlerbehandlung „Fahrplan“ 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 #10 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

Vorlesung #10 - Fehlerbehandlung 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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

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. © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

„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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

„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! © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

„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 © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

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'; © Bojan Milijaš, 07.11.2018 Vorlesung #10 - Fehlerbehandlung

Vorlesung #10 Ende