Today, a junior DBA created a standby database by copying the controlfile to another host, restoring the 4TB database it serves, and recovering all available logs via RMAN. Sounds good, right? Well, it was until we went into SQL*PLUS and found that a “RECOVER STANDBY DATABASE;” command returned an exception that we were not using a standby controlfile. At this point, we were thinking that we had lost an entire day, when we were already behind on the project.
My initial thought was to issue a “alter database convert to physical standby;”. However, I then found that the DBA had created the controlfile for the standby as a “normal” backup controlfile. Was this a good thing?…yeah, not so much. Oracle will not allow you to convert a backup controlfile to a standby, since a backup controlfile implies you are doing incomplete recovery, which a standby database, by definition, should not be.
To complicate matters, we were putting the datafiles on the standby in ASM, where they were on raw devices on the primary host. As a result, RMAN set newname commands were required.
After copying a “real” standby controlfile to the standby host, I found the set newname commands did not work, as this controfile did not “know” about our previously restored and renamed files into ASM on the standby. Since we obviously did not want to re-restore 4TB of datafiles, we ended up cataloging the datafile copies on the standby host so the new standby controlfile “knew” about them, i.e.,
catalog datafilecopy ‘+ASM_TIER2/XWCBMW/DATAFILE/AEID_LB1_4K.285.621280543’ level 0;
…
This worked, and gave us much joy, as out set newname commands in RMAN now worked, and allowed recovery to commence 🙂