| Disaster recovery test [message #376845] |
Thu, 18 December 2008 20:11  |
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 #377042 is a reply to message #377036] |
Fri, 19 December 2008 10:24  |
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 |
Frank Naude
Messages: 4579
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 #377223 is a reply to message #377217] |
Sun, 21 December 2008 23:11 |
 |
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.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
