Comme tous le monde le sait, RMAN est beaucoup plus intelligent que SQL*Plus… Et bien l’exemple ci-dessous, montre qu’on a pas toujours intérêt à être trop intelligent. Vous ferez sans doute rapidement le lien avec une situation réelle mais en gros, la séquence de commandes ne restore qu’un sous-ensemble d’une base de données tente d’en faire le recover après avoir mis le datafile 5 offline:

RMAN> restore datafile 1,2,3,4;

Starting restore at 16-JAN-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=154 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/BLACK/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/BLACK/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/BLACK/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/BLACK/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/BLACK/7hk4utqi_1_1

channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/BLACK/7hk4utqi_1_1 tag=TAG20090116T120849
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:55
Finished restore at 16-JAN-09

RMAN> sql 'alter database datafile 5 offline drop';
sql statement: alter database datafile 5 offline drop

RMAN> recover database;

Starting recover at 16-JAN-09
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/16/2009 12:25:18
RMAN-06094: datafile 5 must be restored

Et c’est ici que RMAN est peut-être trop intelligent ou moi trop bête pour ne pas trouver la correcte syntaxe, choisissez ! Toujours est-il que la seule façon de faire le recover que j’ai trouvée pour l’instant dans la doc, c’est RECOVER DATABASE SKIP TABLESPACE qui oblige à lister tous les tablespaces que vous ne voulez pas restaurer. D’un autre côté, si vous utilisez SQL*Plus à partir de cette étape:

SQL> recover database until cancel;
ORA-00279: change 49042462037 generated at 01/16/2009 12:08:50 needed for
thread 1
ORA-00289: suggestion : /u01/app/oracle/oradata/BLACK/1_426_666110942.dbf
ORA-00280: change 49042462037 for thread 1 is in sequence #426


Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 49042462166 generated at 01/16/2009 12:12:05 needed for
thread 1
ORA-00289: suggestion : /u01/app/oracle/oradata/BLACK/1_427_666110942.dbf
ORA-00280: change 49042462166 for thread 1 is in sequence #427
ORA-00278: log file '/u01/app/oracle/oradata/BLACK/1_426_666110942.dbf' no
longer needed for this recovery

WooHoo!

Remarquez, la conviction mène souvent plus loin que l’intelligence, comme dirait Leeroy Jenkins ;-).