Vorlesung6 - Fehlerbehandlung

WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Vorlesung #6
Fehlerbehandlung
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
„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
© Bojan Milijaš, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
2
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
3
Fehlerklassifizierung
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
4
Lokaler Fehler einer
Transaktion





WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
5
Fehler mit
Hauptspeicherverlust





WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
6
Fehler mit
Hintergrundspeicherverlust





WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
7
„Media Recovery“
in der Praxis
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
8
„Media Recovery“
in der Praxis (2)




WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
9
„Media Recovery“
in der Praxis (3)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
10
SQL für Backup/Recovery


WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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
'2001-10-27:14:00:00';
RMAN Commandos:
CATALOG DATAFILECOPY '/tmp/users01.dbf';
© Bojan Milijaš, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
11
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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
© Bojan Milijaš, 17.11.2004
Vorlesung #6 - Fehlerbehandlung
12
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Vorlesung #6
Ende