Vorlesung 8

SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
Vorlesung #8
Fehlerbehandlung
„Fahrplan“







SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
2
SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
3
Fehlerklassifizierung
SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
4
Lokaler Fehler einer
Transaktion





SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
5
Fehler mit
Hauptspeicherverlust





SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
6
Fehler mit
Hintergrundspeicherverlust





SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
7
„Media Recovery“
in der Praxis
SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
 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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
8
„Media Recovery“
in der Praxis (2)




SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
9
„Media Recovery“
in der Praxis (3)
SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
 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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
10
SQL für Backup/Recovery


SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
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š, 14.02.2017
Vorlesung #8 - Fehlerbehandlung
11
SS 2012 – IBB4C
Datenmanagement
Fr 15:15 – 16:45
R 1.007
Vorlesung #8
Ende