One of my clients is restoring their database backup to another server for some testing. They do it periodically so we can also verify that the backup is good (which is great!). In a few cases, after the restore I saw that the restored database has an incarnation that the original database doesn’t have (and not the one created by the “open resetlogs” after the recovery). This actually caused a problem during the restore, but this restore has a few issues (I started a post about that as well).
After opening an SR about that, the engineer said that Oracle automatically catalogs any archive logs located in the FRA and have the same DBID. In my case, we use the same server each time we restore a database. Before I restore the database I drop the old one (using “drop database”), but I see some orphan archive logs in the FRA (ASM in my case). I didn’t care about them until now, but apparently Oracle sees them, registers them in the control file and creates another database incarnation because of that.
If you do the same, make sure there are no archive logs in the FRA before restoring the database.
Did You Know #25 – Archives in FRA
Categories:
Interesting, thank you Liron.
I wonder what the logic is behind this?
I was wondering the same. My response to the support engineer was “seriously?” 🙂
Yes, Yesterday I tried restore one of out prod backup to test server and my backup path mounted on test server is different and i forgot to catalog the new mounted backup path and started restore.
initially when restore started it crosschecked objects (which are listed in controlfile ) and catalogged.
Thanks for sharing. Need your help to restore DB – ABC TO NEW SERVER with new NAME-XYZ.
I tried using set DBID of source DB in target server but after restoring control file, DB giving error to open in mouth state.
Error- control file have new name, name mismatch. But recovery process says you can set DBID and then, restore parameter file and change the new name there or use new pile with new name then restore CF from backup and mount and restore DF and recovery.
Please suggest.
Hi,
As far as I know you can’t restore a database to a completely new name like that. The DB_NAME is in the control file and it won’t work if the DB_NAME in the init file is different. You can use DB_UNIQUE_NAME if as the DB_NAME under the diagnostics dest and the DB_NAME with Oracle Managed Files will use the DB_UNIQUE_NAME.
If you need a completely new DB_NAME, I would say you need to restore it with the old name and then change the name using DBNEWID utility.
Good article. Thanks.
Here’s an amateur question, did you drop the database from rman using the “including backups” clause ? The archivelogs should get deleted automatically in this case.
Also, if Oracle automatically catalogs archivelogs with same dbid from FRA, then when does one see an ‘orphaned’ archivelog. Just curious.
Mahesh
Good points Mahesh:
1. You are corrent, the “including backups” option would probably solve this issue, but in this case it’s Oracle 11.2 and I think this option is new in 12.1
2. I understand the confusion. What I meant is that after I dropped the database, the archive logs were not deleted, so they were “orphaned”. After I restored the database again, they are registered in the control file, so at this point they are not orphaned anymore, but they created a new incarnation.
I hope this is clear and thanks a lot for the comment.
Liron
Got it now Liron. Thanks for the reply.
Mahesh