WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #6 Fehlerbehandlung.

Präsentation zum Thema: "WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #6 Fehlerbehandlung."—  Präsentation transkript:

1 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #6 Fehlerbehandlung

2 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung2 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

3 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung3 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

4 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung4 Fehlerklassifizierung Es gibt drei Fehlerarten 1.Lokaler Fehler einer Transaktion expliziter Abort – ROLLBACK Anweisung impliziter Abort – z.B. Konsistenzverletzung oder system- gesteuert 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.

5 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung5 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

6 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung6 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

7 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung7 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

8 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung8 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

9 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung9 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!

10 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung10 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

11 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung11 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';

12 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 © Bojan Milijaš, 17.11.2004Vorlesung #6 - Fehlerbehandlung12 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

13 WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #6 Ende