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-01690 „sort area size too small“
a) Texte aus oerr unter Linux01690, 00000, „sort area size too small“// *Cause: sort area size too small to fit two records in memory// *Action: increase sort_area_size b) ErklärungDieser Fehler tritt auf, wenn die Sort Area size zu klein ist.c) LösungDen Wert des...
ORA-01792 „maximum number of columns in a table or view is 1000“
a) Texte aus oerr unter Linux01792, 00000, „maximum number of columns in a table or view is 1000“// *Cause: An attempt was made to create a table or view with more than 1000// columns, or to add more columns to a table or view which pushes// it over...
ORA-02142 „missing or invalid ALTER TABLESPACE option“
a) Texte aus oerr unter Linux02142, 00000, „missing or invalid ALTER TABLESPACE option“// *Cause: A valid option was not present.// *Action: Use one of the valid options: add, rename, default, online,// offline, read only, read write, begin, end, no,...
ORA-02143 „invalid STORAGE option“
a) Texte aus oerr unter Linux02143, 00000, „invalid STORAGE option“// *Cause: An option other than INITIAL, NEXT, MINEXTENTS, MAXEXTENTS, or// PCTINCREASE was specified in the STORAGE clause.// *Action: Specify only valid options. b) ErklärungDieser Fehler tritt auf,...
ORA-02154 „a tablespace with the name ‚%s‘ is found“
a) Texte aus oerr unter Linux02154, 00000, „a tablespace with the name ‚%s‘ is found“// *Cause: An attempt to rename a tablespace to a new name failed because// the new name is already used by some other tablespace.// *Action: Retry with a different...
ORACLE NEWS
MySQL