Recovery
Fehleranalyse als Basis für Optimierung
Vor dem Beginn eines Recovers sollte immer eine genaue Fehleranalyse stehen, um eine darauffolgende Optimierung herbeizuführen, die nachhaltig wirkt. Die Desaster Recovery-Prozesse werden von den dbaservice Consultants definiert und bereits bei der Backup-Strategie berücksichtigt. Eine periodische Plausibilitätsprüfung ist integraler Bestandteil und sollte in keinem Notfallkonzept fehlen.
Es werden grundsätzlich zwei Fehlerarten unterschieden:
Logische Fehler
- Datenfehler durch fehlerhafte Programme
- Ein Programm oder Skript ist in seiner Verarbeitung abgebrochen und hinterlässt die Daten in einem inkonsistenten Zustand
- Operatorfehler, z. B. ein Programm zur Erhöhung der Gehälter wurde versehentlich zweimal gestartet
- Anwender oder Administratoren haben wichtige Tabellen oder Datensätze gelöscht
- Es stehen keine ausreichenden Systemressourcen zur Verfügung (Systemüberlastung, Tablespace-Dateien sind voll, Rollbacksegmente sind zu klein, Deadlocks)
- Stromausfall
- Hardwarefehler, z. B. bei den Speicherplatten
Technische Fehler
- Stromausfall
- Hardwarefehler, z. B. bei den Speicherplatten
- Die Ausführung von Tools ist fehlgeschlagen, sodass sich die Daten in einem inkonsistenten Zustand befinden
Recover planen: Wird ein Datenfehler festgestellt, sollte das Recover Schritt für Schritt geplant werden. Konnte die Fehlerursache genau eingegrenzt werden und ist der Umfang der Recovery-Maßnahmen ermittelt, kann mit dem Recover begonnen werden.
Recover ausführen mit einer Offline-Sicherung: Offline-Sicherungen können nur als Ganzes verwendet werden. Einzelne Teile oder einzelne Dateien lassen sich nicht wiederherstellen. Es müssen alle beteiligten Dateien einschließlich dem System-Tablespace, den Control- und den Redolog-Dateien aus der Sicherung übernommen werden. Alle Datenänderungen, die seit dem Start der Offline-Sicherung ausgeführt wurden, müssen wiederholt werden.
Recover ausführen mit einer online-Sicherung: Einzelne Dateien können wiederhergestellt werden. Die Änderungen an den Daten, die seit dem Herstellen der Sicherung ausgeführt wurden, können durch Auslesen der Log-Dateien nachvollzogen werden, ohne dass die Anwendungsprogramme neu ablaufen müssen. Für das Recover mit Online-Sicherungen gibt es eine große Anzahl von Möglichkeiten.
Haben Sie Fragen?
NEUSTE BEITRÄGE
Und täglich grüßt das Murmeltier – ORA-1555
Wohl einer der bekanntesten Fehler überhaupt, der gute alte ORA-01555 und noch genauso aktuell wie früher. Der Fehlertext ist mittlerweile irreführend, da eigentlich nicht mehr Rollback Segmente, sondern nur noch Undo Segmente verwendet werden. Nichtsdestotrotz bleibt...
ORA-600 – DON’T PANIC
Bei Auftreten eines ORA-600 Fehlers sollten Sie weder in Panik verfallen, noch sollten Sie den Fehler ignorieren. Deshalb Ruhe bewahren und den Fehler genau analysieren, da die Fehlermeldung allein nichts aussagt, außer das eine nicht behandelte Fehlersituation...
ORA-28040 nach Upgrade auf 12c, 18c oder 19c
Sie haben gerade Ihre Datenbank upgegradet und ihre Applikation, TOAD oder ein anderer Client meldet auf einmal einen ORA-28040 beim Versuch sich an der Datenbank anzumelden. Dann verwenden Sie wahrscheinlich einen Oracle Client oder einen Oracle JDBC Treiber der...
Nach dem Oktober PSU, erhalten Sie ORA-02002, ORA-55917 und/oder ORA-01456 bei der Verwendung von export?
ie haben gerade Ihre Datenbank mit dem neusten Oktober PSU gepatcht und bekommen jetzt die oben stehenden Fehler bei der Verwendung von export? Dann sind Sie wahrscheinlich in den Oracle Bug 24405048 gelaufen. Der Patch zu dem Bug hat die gleiche Nummer wie der Bug...
Oracle JavaVM Component – Bundle Patch: Windows Patch Konflikt?
Sollten Sie bereits einen Windows Bundle und einen Oracle JavaVM Component Patch installiert haben und versuchen einen neueren Windows Bundle oder Oracle JavaVM Component Patch zu installieren und/oder die Patch Konflikt Überprüfung laufen lassen, dann zeigt ihnen...
ORACLE NEWS
MySQL