In releases prior to 11g each database has an associated DBID when using the RMAN utility. It just so happens that all physical standby databases have the SAME DBID as the primary so the RMAN catalog gets confused when doing any command against that DBID.
Recommendation to tag your backups with the NODENAME to uniquely identify this HOST/SID/DBID combination:
I have an understanding of the bug and the workaround, I have these final questions. I maybe asking some questions you have already answered, but I want to bring closure to this SR.
1. Will this be fixed in 10g or is this fixed in 11g?
It is marked as fixed in 11g release 2.
2. We are looking at issuing full RMAN backups (datafiles and logs) on both the Primary and the Standby. Our RMAN backup script has a ‘LIKE’ command for the Archive logs on both sides. I reviewed the use of TAGs to make sure the RMAN knows which backup came from which server. Do we need to change our RMAN script and add TAGS on both the datafiles and the archive log backups?
No, the known problems with backup of standby/primary is associated with archivelogs only. RMAN catalog sometimes gets confused with on which server the archivelog files were backed up. These issues have been addressed in 11g.
3. As you are aware, we have the soft links present on both sides (primary, standby) servers, which prevents the bug that is documented for this SR, to occur. Now if we are performing restores (ex, data file) for a Standby that has a full backup performed on a Standby,
3a. Is the same soft link that prevented the bug on restore database validate, going to cause an invalid restore or prevent a successful restore? If so, what is the workaround?
The link should not cause an issue with the restore. The workaround would be to explicitly use ‘set newname’ based on which server you are doing the restore.
3b. If we used a TAG statement for our backups, would this resolve the issue?
Ex. Bbackup database include current controlfile tag='<server name used in BACKUP command
>’;Ex. RESTORE DATABASE FROM TAG ‘<server name used in BACKUP command>’;
No, because the issue was not in finding the backup, it is in realizing which location to place the datafiles.
4. I am getting some resistance on implementing your work around from a previous SR where you recommended the ‘LIKE’ command for archivelog backups. Ex. backup archivelog like ‘$ORACLE_BACKUP_DIR/$ORACLE_SID/archlog_backup/%’ delete input;
If we continue to use the archivelog backup using the (backup archivelog all delete input;), do we need to use TAGs for each backup site, in order to perform (ex. datafile) restores on the Standby?
No, again, the use of ‘like’ is resolve some of the maintenance issues associated with archivelog files in a standby/primary environment. When the restore occurs the files are in backupsets and RMAN will simply restore to the location based on the server on which the restore is being performed.
You may be interested in: