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-01460 – unimplemented or unreasonable conversion requested
1.) Texte aus oerr unter Linux 01460, 00000, „unimplemented or unreasonable conversion requested“ // *Cause: // *Action: 2.) Erklärung Dieser Fehler tritt auf, wenn eine Konversion von Daten mit den Funktionen TO_CHAR, TO_DATE oder TO_NUMBER durchgeführt werden soll,...
ORA-01461 – can bind a LONG value only for insert into a LONG column
1. Texte aus oerr unter Linux 01461, 00000, „can bind a LONG value only for insert into a LONG column“ // *Cause: // *Action: 2. Erklärung Es wurde versucht, Daten vom Typ LONG in ein Feld anderen Typs einzufügen. Dies ist jedoch nicht möglich. Stattdessen wird diese...
ORA-01465 – invalid hex number
1.) Texte aus oerr unter Linux 01465, 00000, „invalid hex number“ // *Cause: // *Action: 2.) Erklärung Es werden gültige Werte in Hex erwartet. In dem String befinden sich jedoch ungültige Werte. Dieser Fehler kann beim Füllen eines Feldes vom Typ BLOB auftreten. 3.)...
ORA-01728 – numeric scale specifier is out of range (-84 to 127)
1.) Texte aus oerr unter Linux 01728, 00000, „numeric scale specifier is out of range (-84 to 127)“ // *Cause: // *Action: 2.) Erklärung Beim Anlegen einer Tabelle ist die Anzahl der Nachkommastellen bei einem Feld vom Typ number außerhalb des gültigen Bereichs. 3.)...
ORA-02049 – timeout: distributed transaction waiting for lock
1.) Texte aus oerr unter Linux 02049, 00000, „timeout: distributed transaction waiting for lock“ // *Cause: exceeded INIT.ORA distributed_lock_timeout seconds waiting for lock. // *Action: treat as a deadlock 2.) Erklärung Eine Transaktion hatte darauf gewartet, ein...
ORACLE NEWS
MySQL