RE: How do you perform a DR test?

  • From: Michael Dinh <mdinh@xxxxxxxxx>
  • To: "'development@xxxxxxxxxxxxxxxxx'" <development@xxxxxxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 18 Nov 2011 08:29:30 -0800

I have done this using Snapshot Standby Database.

The entire stack is replicated to DR, the application is brought up at DR, and 
customers can use the application and see the data.

NOTE: everything done in DR will be loss and they know this. The objective is 
to show that it works.

We allow for a few hours to do this then snapshot standby goes back to physical 
standby

HTH

http://download.oracle.com/docs/cd/E11882_01/server.112/e25608/manage_ps.htm#SBYDB4801

Michael Dinh

Disparity Breaks Automation (DBA)

Confidence comes not from always being right but from not fearing to be wrong - 
Peter T Mcintyre
 
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Martin Bach
Sent: Friday, November 18, 2011 1:47 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: How do you perform a DR test?

Good morning listers,
an interesting question has surfaced recently at my customer. In short: 
how do you perform a DR test? To add a little complication, this is 
/not/ application specific-in other words, the test is against the 
Oracle release, not an application. I know it's wrong but I can't help it.

In the past, it has been agreed that a DR test includes the following 
scenarios:

  * SRDF/A replication: split of the mirror, restart of the database on
    the DR server. Check that everything comes up, do block check
    verification (dbv) and connect applications
  * Data Guard - maximum performance: same procedure, manual and broker
    initiated switchover. The second test included a manual and broker
    initiated failover
  * Data Guard - maximum protection (don't ask, it's a requirement).
    Same test as with max performance.

For some reason there are parties who doubt that Data Guard Maximum 
Protection doesn't do what it says on the tin. How can you prove them 
wrong? Pointing to the documentation not allowed!

So rather than running a synthetic benchmark with next to nil 
probability of proving that no data was lost after a failover, I created 
a number of jobs (150) that all insert into a table in 1 second 
intervals, using a timestamp and job_id. After failing over I flash all 
databases back to the standby_became_primary_scn and compare the table I 
have been inserting to on both side. Unsurprisingly they are identical. 
Is there a better way to do this?

Martin Bach

-- 
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach



--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: