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-12545 – Connect failed because target host or object does not exist
1.) TEXTE AUS OERR UNTER LINUX 12545, 00000, „Connect failed because target host or object does not exist“ // *Cause: The address specified is not valid, or the program being // connected to does not exist. // *Action: Ensure the ADDRESS parameters have been entered...
RMAN-05557, RMAN-05537, ORA-19602, ORA-17627 – DUPLICATE TARGET DATABASE FROM ACTIVE DATABASE
Bei unterschiedlicher Verzeichnisstruktur und abweichenden Namen (zwischen target und auxiliary)+ SPFILE Clause kommt es zuRMAN-05557: Target instance not started with server parameter fileLösung: wenn die target-DB nicht per spfile gestartet wird und zugleich die...
RMAN-5001 duplicate Database returns error even with SET NEWNAME
Fehlerbeschreibung:RMAN duplicate command fails with following error on several files:RMAN-05001: auxiliary filename ……… conflicts with a file used by the target databaseduplicate output log in file ab.log shows errors:.RMAN-05001: auxiliary filename...
RMAN-10038, RMAN-05501: active duplicate fails with error
betrifft: Oracle Database – Enterprise Edition – Version 11.2.0.4 and later – jede Plattform Fehlerausgabe:Command is: DUPLICATE TARGET DATABASE TO CPLBDV01 FROM ACTIVE DATABASE SKIP TABLESPACE XXJLP_TS_ARCHIVE; The failure occurs after all of the datafiles have been...
OPatch Apply Fails with Error Code 20 during Oracle Home Discovery Phase
betrifft: Oracle Database – Enterprise Edition – Version 11.2.0.1 and later – alle Plattformen /RAC-Systeme Fehlerausgabe:opatch apply online -connectString RACDB1:sys:test:ORACLERAC1,RACDB2:sys:test:ORACLERAC2Oracle Interim Patch Installer version 11.2.0.3.4Copyright...
ORACLE NEWS
MySQL