Seit Oracle 11g gibt es ja einige neue Backup- und Recovery-Features, unter anderem auch den Data Recovery Advisor.
Dieser neue Assistent soll Fehler ermitteln, klassifizieren, darstellen und auch lösen. In bunten Oracle-Bildchen sieht das dann so aus:
(Quelle: Oracle)
Wir haben den Ratschlaggeber Advisor mit einer kleinen Aufgabe auf die Probe gestellt: man nehme eine x-beliebige Oracle-Datendatei, zerstückele sie ein bisschen und warte, was passiert.
Zunächst die Ausgangslage: wir suchen uns die Datei EXAMPLE01.DBF aus, die zum Beispielschema der Datenbank gehört. Der Benutzer HR greift mit seinen Objekten auf diese Datei zu.
Wir öffnen die Datei mit dem VI und löschen mitten in der Datei wahllos zwei Zeilen (Kommando „dd“). Dann speichern wir die nun logisch korrupte Datei mit „wq!“ ab.
Der nächste Screenshot zeigt, dass sich die Größe der veränderten EXAMPLE01.DBF vom Ausgangszustand unterscheidet.
Als Benutzer HR führen wir nun ganz unbedarft im SQL*Plus-Statement aus, das potenziell die von uns zerstörten Daten betrifft.
Und tatsächlich — wir haben auf Anhieb die kaputte Stelle getroffen und werden als Anwender sofort über den Schadensfall informiert. Falls wir wissend sind und genügend Rechte haben, können wir noch ein
analyze <Tabelle> validate structure;
ausführen und Oracle die Struktur der Tabelle prüfen lassen. Auch hier bekommen wir eine Fehlermeldung. (Falls der Anwender den Analyze-Befehl nicht ausführen kann, sollte der DBA auf diese Weise die Integrität der Tabelle überprüfen.) Nun ist es also höchste Zeit, den DBA anzurufen.
Dieser versucht sich ggf. mit dem DBVERIFY-Utility einen Überblick über die Lage zu verschaffen.
Im Enterprise Manager wird mittlerweile auch schon vor einem „kritischen Vorfall“ gewarnt.
Die Fehlerbeschreibung ist eindeutig: EXMAPLE01.DBF ist defekt und somit sind einige Objekte im Example-Tablespace nicht verfügbar.
Der Recovery-Advisor bietet sogleich seine Hilfe an.
Die Empfehlung wird anhand des RMAN-Skripes dargestellt, das der Advisor zur Lösung des Problems ausführen möchte, so man ihn denn lässt: Hier soll die Datei EXAMPLE01.DBF aus dem vorhandenen RMAN-Backup wiederhergestellt und dann mittels der Archive-Log-Dateien auf den Stand vor dem Crash aktualisiert werden.
Gibt man dem Advisor freie Fahrt, legt er das RMAN-Skript als Job an und macht sich sogleich an die Arbeit…
Während der Laufzeit des Jobs hat man eine Übersicht über die einzelnen Schritte:
…und fertig!
Das ausgeführte Skript liest sich dann wie folgt:
Fazit: In unserem einfachen Testszenario leistet der Advisor gute Arbeit. Man muss sich nicht um RMAN-Skripte kümmern, hat jederzeit den Überblick und konzentriert sich auf das Wesentliche. Wie sich der Advisor bei komplexeren Problemen verhält, bleibt auszutesten. Allerdings darf man nicht die eierlegende Wollmilchsau erwarten, denn Oracle setzt dem Advisor relativ enge Grenzen:
A. Physical corruption such as block checksum failures and invalid block header field values
B. I/O failures such as hardware errors and operating system driver failures
C. Inconsistencies such as a datafile that is older than other database files
D. Failures on standby databases
Für diese Fälle wird er sich gut eignen, nimmt dem DBA aber nicht die verantwortungsvolle Planung und Administration eines sicheren Backup- und Recovery-Konzeptes ab.
