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-06512 – ORA-06512 at %sline %s
1.) Texte aus oerr unter Linux 06512, 00000, „at %sline %s“ // *Cause: Backtrace message as the stack is unwound by unhandled // exceptions. // *Action: Fix the problem causing the exception or write an exception // handler for this condition. Or...
ORA-28273 – No mapping for user nickname to LDAP distinguished name exists
1.) Texte aus oerr unter Linux 28273, 0000, „No mapping for user nickname to LDAP distinguished name exists.“ // *Cause: ORACLE server cannot map the given user nickname to LDAP // distinguished name. // *Action: Make sure user entries in LDAP are correctly...
ORA-29278 – SMTP transient error: %s
1.) Texte aus oerr unter Linux29278, 00000, „SMTP transient error: %s“// *Cause: A SMTP transient error occurred.// *Action: Correct the error and retry the SMTP operation.2.) ErklärungMit dem Package UTL_SMTP wurde versucht, E-Mails aus der Datenbank heraus zu...
ORA-0165
a) Texte aus oerr unter Linux 01653, 00000, „unable to extend table %s.%s by %s in tablespace %s“// *Cause: Failed to allocate an extent of the required number of blocks for// a table segment in the tablespace indicated.// *Action: Use ALTER TABLESPACE...
ORA-39070 Unable to open the log file
1.) Texte aus oerr unter Linux 39070, 00000, „Unable to open the log file.“// *Cause: Errors were detecting while opening the log file. Subsequent// messages will detail the problems.// *Action: Fix the problems outlined in the secondary messages. 2.)...
ORACLE NEWS
MySQL