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
ORA-01549 tablespace not empty, use INCLUDING CONTENTS option
1.) Texte aus oerr unter Linux 01549, 00000, „tablespace not empty, use INCLUDING CONTENTS option“// *Cause: Tried to drop a non-empty tablespace// *Action: To drop all the objects in the tablespace, use the INCLUDING// CONTENTS option 2.) Erklärung Es wurde...
ORA-01550 „cannot drop system tablespace“
a) Texte aus oerr unter Linux 01550, 00000, „cannot drop system tablespace“// *Cause: Tried to drop system tablespace// *Action: None b) ErklärungDieser Fehler tritt auf, wenn versucht wird den SYSTEM Tablespace zu löschen.Der SYSTEM Tablespace kann aber nicht...
ORA-01553 „MAXEXTENTS must be no smaller than the %s extents currently allocated“
a) Texte aus oerr unter Linux 01553, 00000, „MAXEXTENTS must be no smaller than the %s extents currently allocated“// *Cause: The number of extents allocated is greater than the MAXEXTENTS// specified.// *Action: Specify a larger MAXEXTENTS value.b) ErklärungDieser...
ORA-01570 „MINEXTENTS must be no larger than the %s extents currently allocated“
a) Texte aus oerr unter Linux // *Cause: The number of extents allocated is smaller than the MINEXTENTS// specified.// *Action: Specify a smaller MINEXTENTS value. b) ErklärungDieser Fehler tritt auf, wenn die Anzahl der bereits allokierten Extents kleiner ist als der...
ORA-01577 „cannot add log file ‚%s‘ – file already part of database“
a) Texte aus oerr unter Linux 01577, 00000, „cannot add log file ‚%s‘ – file already part of database“// *Cause: During CREATE or ALTER DATABASE, a file being added is already// part of the database.// *Action: Use a different file name. b)...
ORACLE NEWS
MySQL