Je  pensais pouvoir restaurer sereinement  ma base de données TEST  à partir d’une sauvegarde RMAN base fermée que j’avais archivée avant de supprimer la base  et toutes ses sauvegardes y compris d’archivelogs.

Hélas par un fatal hasard je n’avais pas conservé la bonne sauvegarde qui était en réalité une sauvegarde réalisée base ouverte et active et dont je n’avais pas conservé les sauvegardes d’archivelogs générés durant la sauvegarde.
Heureusement, un paramètre « caché » de l’instance Oracle m’ à permis de m’en sortir, voici le déroulement des opérations : (la version de la database est 10.2.0.4)
Je commence par restaurer la sauvegarde du controlfile courant  réalisée après la sauvegarde après avoir démarré l’instance en mode NOMOUNT à partir d’un fichier init.ora conservé par ailleurs tout comme le fichier de mot de passe orapwTEST

SQL> startup nomount pfile='/u01/app/oracle/product/10.2.0/db/dbs/initTEST.ora'
Instance ORACLE lancee.

rman target /

RMAN> restore controlfile from '/distrib/rman/TEST/CTLFILE_05osjkv5_1_1';

Starting restore at 17-DEC-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:06
output filename=/u01/app/oracle/oradata/TEST/control01.ctl
output filename=/u01/app/oracle/oradata/TEST/control02.ctl
output filename=/u01/app/oracle/oradata/TEST/control03.ctl
Finished restore at 17-DEC-13

Puis je restore les fichiers de la base de données  après avoir monté la base :

RMAN> mount database;
database mounted
released channel: ORA_DISK_1
RMAN> restore database;
Starting restore at 17-DEC-13
Starting implicit crosscheck backup at 17-DEC-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 2 objects
Finished implicit crosscheck backup at 17-DEC-13
Starting implicit crosscheck copy at 17-DEC-13
using channel ORA_DISK_1
Finished implicit crosscheck copy at 27-DEC-13
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/app/oracle/oradata/TEST/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/TEST/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/TEST/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/TEST/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/TEST/example01.dbf
channel ORA_DISK_1: reading from backup piece /distrib/rman/TEST/DF_03osjkqg_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/distrib/rman/TEST/DF_03osjkqg_1_1 tag=COLD_BKP_BAD
channel ORA_DISK_1: restore complete, elapsed time: 00:01:57
Finished restore at 17-DEC-13

Jusque là, pas de problèmes tout va bien !
Maintenant je veux ouvrir la base en resetlogs puisque je n’ai pas les redologs courants ni archivés :

sqlplus / as sysdba
Connecte a :
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERREUR a la ligne 1 :
ORA-01194: le fichier 2 necessite plus de recuperation pour etre coherent
ORA-01110: fichier de donnees 2 : '/u01/app/oracle/oradata/TEST/undotbs01.dbf'

Aie  : ORA-01194 – impossible d’ouvir la base !
Notez d’ailleurs que l’erreur aurait aussi pu être du type ORA-01113 suivant selon les conditions du backup:

ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u01/app/oracle/oradata/TEST/system01.dbf'

Alors , que faire ?

Heureusement il existe une solution sous la forme d’un paramètre d’instance caché c’est à dire non documenté et précédé d’un underscore :
_ALLOW_RESETLOGS_CORRUPTION
Bien entendu  ce type de paramètre ne devrait jamais être utilisé sur une base de production sans instruction du support Oracle ou bien uniquement pour des cas désespérés. N’utilisez pas ce paramètre pour contourner habituellement  une logique de sauvegarde défaillante.
Ce paramètre va permettre d’ouvrir la base en ignorant les erreurs de cohérence dans les segments UNDO, il faut cependant l’utiliser avec un mode de gestion de UNDO de type MANUAL en positionnant temporairement le paramètre UNDO_MANAGEMENT à MANUAL dans le fichier d’initialisation de l’instance.
A partir de l’état précédent, arrêtez votre instance:

shutdown immediate

Et modifiez le  fichier init.ora de l’instance comme suit :

• Changez UNDO_MANAGEMENT de AUTO à MANUAL

UNDO_MANAGEMENT=  MANUAL

• Ajoutez le paramètre suivant

_ALLOW_RESETLOGS_CORRUPTION = TRUE

Redémarrez ensuite l’instance normalement :
SQL> startup
Instance ORACLE lancee.
Total System Global Area  281018368 bytes
Fixed Size                  2083336 bytes
Variable Size              88081912 bytes
Database Buffers          184549376 bytes
Redo Buffers                6303744 bytes
Base de donnees montee.
Base de donnees modifiee.
Et voilà , la base est ouverte !
Il reste à présent à supprimer le tablespace UNDO éventuellement corrompu et à le recréer. Pour cela créez un autre tablespace UNDOTBS2

create UNDO tablespace UNDOTBS2 datafile '/u01/app/oracle/oradata/TEST/undotbs02.dbf' size 1024M;

Arrêtez l’instance et modifiez les paramètres :

• UNDO_MANAGEMENT=  AUTO

• UNDO_TABLESPACE=UNDOTBS2

Et surtout, supprimez le paramètre _ALLOW_RESETLOGS_CORRUPTION

Vous pouvez maintenant démarrer l’instance normalement, supprimer le tablespace corrompu UNDOTBS1

drop  tablespace UNDOTBS1 including contents and datafiles

Enfin l’étape la plus importante : réalisez immédiatement une sauvegarde cohérente !