You've made it quite clear and simple
Bill, January 06, 2009 - 4:33 pm UTC
As far as backing up the redo logs comment. I was referring to the archived redo logs. Sorry I wasn't clear on that. Your response did cover it though. I think that my initial setup for the standby database will be maximum performance.
Thank You very much for making this look so easy.
Bill
A reader, February 10, 2009 - 12:04 pm UTC
Hi - Recently we exercised a disaster recovery test and we faced one problem while doing backups. This is the scenario. We currently run backups on our primary production database. During the disaster recovery test, we switched over to the physical standby and started taking backups on the standby site. After the test was complete, we switched back and when our backups were now back to the original primary, we were facing RMAN-06214 errors. Tried to simulate that in our test environment and received the same errors. The list of commands that we run in our backup script are
crosscheck backup;
crosscheck copy;
delete NOPROMPT expired backup;
delete NOPROMPT expired copy;
delete NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'TRUNC(SYSDATE-1)';
delete NOPROMPT obsolete redundancy=2 device type disk;
While doing the delete NOPROMPT obsolete .... command we are facing the following errors
RMAN-06207: WARNING: 4 objects could not be deleted for DISK channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: --------------- ---------------------------------------------------
RMAN-06214: Archivelog /ora.dump/backup/flash_recovery_area/DBSTBY/archivelog/2009_02_09/o1_mf_1_456_4s
0qkt6l_.arc
RMAN-06214: Archivelog /ora.dump/backup/flash_recovery_area/DBSTBY/archivelog/2009_02_09/o1_mf_1_457_4s
0qny0w_.arc
RMAN-06214: Archivelog /ora.dump/backup/flash_recovery_area/DBSTBY/archivelog/2009_02_09/o1_mf_1_458_4s
0qo3q5_.arc
RMAN-06214: Archivelog /ora.dump/backup/flash_recovery_area/DBSTBY/archivelog/2009_02_09/o1_mf_1_459_4s
0qss0y_.arc
The directory structure DBSTBY is on the standby site and on the primary site the directory structure is /ora.dump/backup/flash_recovery_area/DBPRI.
What we are trying to understand is, how to resolve these issues and in such a scenario what is the standard method to do backups.
Thanks.
February 11, 2009 - 9:25 am UTC
I don't know all of the details - I don't know if you switched over or failed over (if a switch over, I don't know why you would backup even?)
and did you crosscheck?
A reader, February 11, 2009 - 10:52 am UTC
Yes we did a switch over and we did do a crosscheck ?
You said you dont know why we would do a backup if we did a switchover. What is the reason for that ?
February 11, 2009 - 1:05 pm UTC
you switchover for a relatively short period, why would you do a backup? You switchover to
a) prove you can
b) do some scheduled maintenance on production
shows forethought in plans
Bill Hoffman, February 11, 2009 - 11:47 am UTC
Hi Tom,
I understand that this was a DR test. If can fully understand doing a backup during one of these drills. It's not just "Can I bring up my systems elsewhere". It's "Can I continue business operations elsewhere". Performing a backup during a DR test shows that they are planning for Business Continuity.
Bill
February 11, 2009 - 1:12 pm UTC
I asked what they were doing - in the event of failover - we'd need to discuss what the 'fail back' operations where. In the case of a switchover, not so.
A reader, February 11, 2009 - 2:18 pm UTC
We switched over and stayed in the standby site for about 2 weeks to ensure that we are still operational if a need arises to switch to the standby site. That is why we had to continue to take level 0 backups on the weekend in between and incremental backups during the 2 weeks.
What would you have in such a situation ?
February 11, 2009 - 3:01 pm UTC
what were you backing up to in this case (you see, there are lots of moving pieces). Was it the same place or a new place.
A reader, February 11, 2009 - 3:11 pm UTC
Originally we were backing up to disk on the primary site and after the switchover and for the 2 weeks we were backing up to disk on the standby site.
Both times we were connected to the same recovery catalog.
February 12, 2009 - 10:39 am UTC
well, it is like you simulated a failover (everything was going on the standby for two weeks). The backups you took there were registered in the catalog for that database - but are not available on the production site. So in your case, you would crosscheck to sort of clear out the discrepancies - and get everything 'in sync'
In real life, your backups would have been available on the fail over site - or they should be, so you would have one backup ultimately - that is, if you were doing disk based backups, eventually you get those to tape and the tapes are off site somewhere, they would be made available to the failover so you can disk based backup there, and then add to the tape - so the only thing that really gets out of sync would be the disk based stuff.
But you see the issue - the backups on each location were not/are not visible to the other. The way you have it, they are completely separate 'chains'
A reader, February 12, 2009 - 1:43 pm UTC
Would you consider this as a feasible option - take backups of one site (either primary/standby) and continue to backup the same site even when the role changes ?
February 12, 2009 - 4:45 pm UTC
well, that would not have accomplished their goal in this case - that of making sure the secondary site could do everything the primary site does - in the event of total loss.
but yes, you could
A reader, February 12, 2009 - 6:48 pm UTC
Does anything have to change in order to backup a physical standby ? Is backing up a physical standby a good strategy ? I read that enabling block change tracking will not work for a physical standby till Oracle 11g. In that case, what is the impact of implementing backups in physical standby. would you consider that as a good option ?