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-12719 operation requires database is in RESTRICTED mode
1.) TEXTE AUS OERR UNTER LINUX // *Cause: This command can only be run when the database is in RESTRICTED mode// *Action: Ensure that the system is in RESTRICTED mode 2.) ERKLÄRUNG Der Fehler ORA-12719 tritt bei einem „DROP DATABASE“ auf, wenn die Datenbank nicht im...
ORA-01103 database name ‚%s‘ in control file is not ‚%s‘
1.) TEXTE AUS OERR UNTER LINUX 01103, 00000, „database name ‚%s‘ in control file is not ‚%s'“// *Cause: The database name in the control file does not match your// database name.// *Action: Either find the correct control file or change your database name....
ORA-03113 end-of-file on communication channel
1.) TEXTE AUS OERR UNTER LINUX // *Cause: The connection between Client and Server process was broken.// *Action: There was a communication error that requires further investigation.// First, check for network problems and review the SQL*Net setup.// ...
ORA-12570 – TNS:packet reader failure
1.) TEXTE AUS OERR UNTER LINUX 12570, 00000, „TNS:packet reader failure“ // *Cause: An error occurred during a data receive. // *Action: Not normally visible to the user. For further details, turn // on tracing and reexecute the operation. If error persists, contact...
ORA-12560 – TNS:protocol adapter error
1.) TEXTE AUS OERR UNTER LINUX 12560, 00000, „TNS:protocol adapter error“ // *Cause: A generic protocol adapter error occurred. // *Action: Check addresses used for proper protocol specification. Before // reporting this error, look at the error stack and check for...
ORACLE NEWS
MySQL