SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 Vorlesung #9 Fehlerbehandlung „Fahrplan“ SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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 © Bojan Milijaš, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 2 SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 3 Fehlerklassifizierung SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 Es gibt drei Fehlerarten 1. Lokaler Fehler einer Transaktion expliziter Abort – ROLLBACK Anweisung impliziter Abort – z.B. Konsistenzverletzung oder systemgesteuert beim Vorliegen eines Deadlocks (Verklemmung) 2. Fehler mit Hauptspeicherverlust Stromausfall Betriebsystemabsturz 3. Fehler mit Hintergrundspeicherverlust Platten-Crash Feuer, Erdbeben, Überflutung - die Platte wird zerstört Platten-Diebstahl, versehentliches Löschen, usw. © Bojan Milijaš, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 4 Lokaler Fehler einer Transaktion SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 5 Fehler mit Hauptspeicherverlust SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 Betriebsystem- oder DBMS-Absturz, Stromausfall Treten relativ selten auf (Stunden- bzw. TageBereich) 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 6 Fehler mit Hintergrundspeicherverlust SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 7 „Media Recovery“ in der Praxis SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 8 „Media Recovery“ in der Praxis (2) SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 9 „Media Recovery“ in der Praxis (3) SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 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š, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 10 SQL für Backup/Recovery SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 Kein SQL Standards, sondern eigene SQLKommandos 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 '2012-04-27:14:00:00'; RMAN Commandos: CATALOG DATAFILECOPY '/tmp/users01.dbf'; © Bojan Milijaš, 31.05.2013 Vorlesung #9 - Fehlerbehandlung 11 SS 2013 – IBB4B Datenmanagement Fr 17:00 – 18:30 R 0.012 Vorlesung #9 Ende