Stellt sich Oracle beim Datenbank-Recovery etwas umständlich an, so muß man etwas tiefer in die Trickkiste greifen:

Erfahrungsgemäß läuft ein

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

meist damit gegen die Wand, daß Oracle versucht, auf ein nicht existierendes, archiviertes Logfile zuzugreifen. Ergebnis sind in der Regel der Fehler

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '<woauchimmer>system01.dbf'

was aber nicht unbedingt bedeutet, daß sich das Problem tatsächlich auf die eine Datei beschränkt.

Sollte dies der Fall sein, muß für ein erfolgreiches Recovery noch das aktuelle Redo-Log verwendet werden. Hierzu ist zuerst das aktuelle Log zu ermitteln

SELECT member FROM v$logfile , v$log WHERE v$log.status='CURRENT' AND v$logfile.group# = v$log.group#;

anschließend nochmals ein Recovery zu starten, hierbei allerdings weder ‘AUTO’ noch ‘CANCEL’ zu wählen sondern das soeben ermittelte Logfile anzugeben.

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Hat alles geklappt, sollte ein

ALTER DATABASE OPEN RESETLOGS;

zum gewünschten Erfolg führen.

Das Einspielen der Critical Patch Updates (CPUs) in eine Oracle-Datenbank erfolgt mittels des Oracle-eigenen Utilities “OPatch”, welches standardmäßig im Verzeichnis “$ORACLE_HOME/OPatch” zu finden ist. Eine Übersicht der Funktionsweise und Bezugsquellen von OPatch findet sich in der “OPATCH FAQ” im Oracle Metalink.

Grundlegende Informationen zur eingesetzen Datenbank lassen sich im laufenden Betrieb über eine einfache SQL-Abfrage ermitteln:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Solaris: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

Eine Auflistung aller bisher einsgespielten Patches gibt es über den Befehl

opatch lsinventory

ermitteln, der aber leider nur die Patch-Nummern, nicht aber die Klartextnamen (wie z.B. “CPU April 2008”) ausgibt. Wer nur die letzte große Änderung an seiner Datenbank wissen will - mittels einer SQL-Abfrage wie

SQL> select action_time, comments, id from dba_registry_history;

ACTION_TIME                   COMMENTS                    ID
------------------------------------------------------------
20-JUN-07 02.31.54.218693 PM  CPUApr2007             5901891

gelangt man an die Information.

Weiterlesen