Si vous avez mis en place du dataguard, il vous est certainement déjà arrivé de constater des désynchronisations dues à la corruption d’un dbf ou plus rarement à sa disparition inopportune. Sur des bases de petite taille, on peut se permettre de reconstruire la base standby; sur des bases de taille plus conséquente et dans le cas de la perte de quelques fichiers, on souhaiterait n’avoir à récupérer que les fichiers en question.
Rman nous permet cela et voici comment procéder.
 
 
La corruption de fichiers étant détectée, on a un message du type suivant dans le fichier alert.log

Completed: alter database recover managed standby database using current logfile disconnect from session
Tue Dec 15 17:19:36 2015
Errors in file /u01/app/oracle/diag/rdbms/…
ORA-00600: internal error code, arguments: [3020], [3], [2340], [12585252], [], [], [], [], [], [], [], []ORA-10567: Redo is inconsistent with data block (file# 3, block# 2340, file offset is 19169280 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 3: '/u02/oradata/MaBdd/undotbs01.dbf'

Le fichier /u02/oradata/MaBddstandbt/undotbs01.dbf est corrompu, il faut le récupérer depuis la base active.
Première étape, s’assurer que le fichier /u02/oradata/MaBddstandbt/undotbs01.dbf est absent du système de fichier. Dans le cas présent, on est sur du FS classique, mais se serait la même chose sur de l’ASM.
Si le fichier est toujours présent, on le renomme :

mv /u02/oradata/MaBddstandby/undotbs01.dbf /u02/oradata/MaBddstandbt/undotbs01.old

Une fois cela fait, on se connecte à RMAN pour récupérer le fichier en question.
Dans l’exemple suivant, je pars du principe que l’on peut passer par le réseau pour faire transiter les blocs à copier.

target sys/syspassword@Mabddprimaire auxiliary sys/ssyspassword@Mabddstandby

run
 {
  allocate channel tgt1 type disk ;
  allocate auxiliary channel dup1 type disk;
  allocate auxiliary channel dup2 type disk;
  backup as copy datafile 3 auxiliary format '/u02/oradata/MaBddstandby/undotbs01.dbf;
 }

Une fois la copie terminée sans erreur, sous sqlplus lancer la commande suivante :
 

sqlplus / as sysdba
alter database recover managed standby database using current logfile disconnect from session;

 
S’il n’y a pas d’autres fichiers corrompus, on peut constater dans le fichier alert.log que l’application des logs est bien relancée.