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-06502 – PL/SQL: numeric or value error%s
1.) Texte aus oerr unter Linux 06502, 00000, „PL/SQL: numeric or value error%s“ // *Cause: An arithmetic, numeric, string, conversion, or constraint error // occurred. For example, this error occurs if an attempt is made to // assign the value NULL to a...
ORA-01843 – not a valid mont
01843, 00000, „not a valid month“ // *Cause: A date specified an invalid month.// Valid months are: January-December, for format code MONTH, and Jan-Dec, for format code MON. // *Action: A date specified an invalid month.// Valid months are: January-December, for...
ORA-12154 – TNS:could not resolve the connect identifier specified
1.) Texte aus oerr unter Linux 12154, 00000, „TNS:could not resolve the connect identifier specified“ // *Cause: A connection to a database or other service was requested using // a connect identifier, and the connect identifier specified could not // be resolved into...
Hochverfügbare Datenbanksysteme? dbaservices!
Neu Isenburg 14. Februar 2014, dbaservices bietet mit “DB 24/7″ einen Premiumdienst für echte Hochverfügbarkeit Ihrer Datenbanken: Daten und deren Verfügbarkeit genießen maximale Priorität. Hochverfügbare Datenbanksysteme? dbaservices! Sie erreichen die dbaservices...
ORA-1652, ORA-1653, ORA-1654, ORA-1655, ORA-1658, ORA-1683, ORA-1688, ORA-1691, ORA-1692, Platzprobleme?
Eine Checkliste für die Erweiterung bei Platzproblemen Alle der oben genannten Fehlermeldungen weisen auf Platzprobleme in einem Tablespace in Ihrer Oracle Datenbank hin. In der Regel bedeutet dies, das ein Objekt keinen weiteren Platz allokieren kann, bis der...
ORACLE NEWS
MySQL