Home » RDBMS Server » Backup & Recovery » Disaster recovery test (oracle 10g in HP UX)
Disaster recovery test [message #376845] Thu, 18 December 2008 20:11 Go to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
Hi,
We are planning to do a disaster recovery test. We have servers in two different geographical locations and there is replication on the hardware level. During the test we are planning to stop the replication and bring up the database on the disaster recovery site. When I do that, do I need to do database recovery? or else I should be able to bring up the database?
Thanks
Re: Disaster recovery test [message #376883 is a reply to message #376845] Fri, 19 December 2008 00:55 Go to previous messageGo to next message
Frank Naude
Messages: 4502
Registered: April 1998
Senior Member
The database should start immediately with normal instance recovery.

PS: What replication technology are you guys using (EMC's SRDF, HP's CA, etc)?
Re: Disaster recovery test [message #377032 is a reply to message #376883] Fri, 19 December 2008 09:28 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
We are using SRDF
Re: Disaster recovery test [message #377036 is a reply to message #377032] Fri, 19 December 2008 09:34 Go to previous messageGo to next message
Frank Naude
Messages: 4502
Registered: April 1998
Senior Member
Well, in that case you should be OK. Just ask the EMC engineers to check that replication is working and that I/Os are not queued before the test.
Re: Disaster recovery test [message #377042 is a reply to message #377036] Fri, 19 December 2008 10:24 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
So,once the replication process is stoped by the EMC storage admin, I just need to do
SQLPLUS> startup mount; and
SQLPLUS> alter database open;

or

SQLPLUS> startup mount;
SQLPLUS> recover database;
SQLPLUS> alter database open;

can you tell me which one will be required?
Thanks
Re: Disaster recovery test [message #377045 is a reply to message #377042] Fri, 19 December 2008 10:53 Go to previous messageGo to next message
Frank Naude
Messages: 4502
Registered: April 1998
Senior Member
I would assume (1) will be sufficient. However, (2) won't be that bad either (as long at it doesn't take too long). Is your archive destination also replicated? When will you be performing the test?
Re: Disaster recovery test [message #377053 is a reply to message #376845] Fri, 19 December 2008 11:25 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
Yes archivelog destination is also replicated and we will be performing the test in next 3 hrs
Re: Disaster recovery test [message #377055 is a reply to message #377053] Fri, 19 December 2008 11:59 Go to previous messageGo to next message
Frank Naude
Messages: 4502
Registered: April 1998
Senior Member
Best of luck! Let us know how it goes.
Re: Disaster recovery test [message #377075 is a reply to message #377055] Fri, 19 December 2008 21:19 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
Hi,
I was able to bring up the DB just by
SQLPLUS> startup mount;
SQLPLUS> alter database open;

after stopping the SRDF replication process
Thanks
Re: Disaster recovery test [message #377077 is a reply to message #377075] Fri, 19 December 2008 21:48 Go to previous messageGo to next message
ebrian
Messages: 2794
Registered: April 2006
Senior Member
I assume you had the primary database shutdown during this process ?
Re: Disaster recovery test [message #377171 is a reply to message #377077] Sun, 21 December 2008 03:48 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
No, primary database was up and running all the time
Re: Disaster recovery test [message #377172 is a reply to message #377171] Sun, 21 December 2008 04:15 Go to previous messageGo to next message
Frank Naude
Messages: 4502
Registered: April 1998
Senior Member
This is so much easier than data guard (Oracle standby). OK, that is probably not fair, data guard is a bit more sophisticated. However, pushing the work to the lowest possible layer (storage cabinets) is probably a good idea performance wise. Not to mention the storage administrators will do all the hard work for you Smile
Re: Disaster recovery test [message #377197 is a reply to message #377171] Sun, 21 December 2008 10:23 Go to previous messageGo to next message
ebrian
Messages: 2794
Registered: April 2006
Senior Member
caprikar wrote on Sun, 21 December 2008 04:48
No, primary database was up and running all the time

Did you do anything to the primary to prepare for the split ?
Re: Disaster recovery test [message #377216 is a reply to message #377197] Sun, 21 December 2008 21:43 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
I didn't do anything to the primary DB
Re: Disaster recovery test [message #377217 is a reply to message #377216] Sun, 21 December 2008 21:45 Go to previous messageGo to next message
caprikar
Messages: 226
Registered: March 2007
Senior Member
Only thing is the IP address on the DR server is different than the Primary DB server
Re: Disaster recovery test [message #377223 is a reply to message #377217] Sun, 21 December 2008 23:11 Go to previous message
ebrian
Messages: 2794
Registered: April 2006
Senior Member
The primary database or tablespaces should me put in backup mode prior to a planned split.

On a previous project I was on, some self-proclaimed EMC "engineers" were misguided in thinking they could perform a planned snap without any preliminary actions on the primary and it actually corrupted the DR database. Sure the databases started up fine, however upon further investigation, it was determined that the database was corrupt. You may have instances where the split occurs without corruption, however you are taking a risk. Almost like taking a backup of the database while it is up and running without putting it into backup mode or using RMAN. In addition, it is best to use a BACKUP CONTROLFILE during this process instead of the controlfile created during the split.

When I convinced them that the database was corrupt, we went back and put the database into backup mode prior to the split and the process worked without issue and without corruption of the DR database.
Previous Topic: active data guard
Next Topic: How to recover the fullbackup sets and incremental bkp sets ?
Goto Forum:
  


Current Time: Wed Dec 07 18:51:44 CST 2016

Total time taken to generate the page: 0.11475 seconds