RMAN restore redo logs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RMAN restore redo logs

Roshan
Oracle database 19c Exadata.

Hello Erman,

we have 1 database production(A) running on Exadata machine. The redo logs are located on RECOC1. I tried to restore the backup of prod database on same Exadata machine under a different instance(B).

pfile entry:

*.db_file_name_convert='+DATAC1/SEYPROD/DATAFILE','+DATAC2/T24SEY/DATAFILE'
*.control_files='+DATAC2/T24SEY/CONTROLFILE/control01','+RECOC2/T24SEY/CONTROLFILE/control02'
*.log_file_name_convert='+RECOC1/SEYPROD/ONLINELOG','+RECOC2/T24SEY/ONLINELOG'

When I restored the databased and recovery completed, I noticed the redo logs where pointing to old RECOC1. Why is it pointing to RECOC1 instead of RECOC2. log_file_name_convert was set.

Regards,
Roshan
Reply | Threaded
Open this post in threaded view
|

Re: RMAN restore redo logs

ErmanArslansOracleBlog
Administrator
There is a common mis-conception regarding the DB_FILE_NAME_CONVERT parameter.
It is used to rename the datafiles being restored from the target backups into an "auxiliary" instance.

This parameter is usually used in the following cases;

"DUPLICATE TARGET DATABASE FOR STANDBY"
"DUPLICATE TARGET DATABASE TO "
"RECOVER TABLESPACE 'blabla' UNTIL"

In all the above cases the datafiles are restored to the location mentioned in
the parameter DB_FILE_NAME_CONVERT.
Once the files are restored then the "auxiliary"(/duplicate/clone/..)
controlfile is created and the files are renamed to the location specified by the parameter.

But! this is not the case with a manual restore.
In such a case, those files are restored to location specified in the controlfile.. In such a case DB_FILE_NAME_CONVERT is not used!