RE: EMC's SRDF vs Oracle DataGuard

  • From: "Smith, Steven K - MSHA" <Smith.Steven@xxxxxxx>
  • To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 23 Jan 2008 16:53:03 -0700

First - we are currently using physical standby for the OLTP.  It has worked 
well.  We are migrating the HW from Teradata to Oracle and the business 
requirements are that both the OLTP and the WH environments be available 
remotely and be able to continue to be updated remotely.  Congress gets antsy 
if we tell them that they have to wait for their information after a fatality 
because we have to rebuild the database (think: Sago Mine accident in 2006).

With the warehouse being partially sourced directly by the OLTP system through 
materialized views, how, using DataGuard, can you keep both sites current in 
both environments?  I know you can set up data guard OLTP(local) -> 
OLTP(remote) and WH(local) -> WH(remote).  Or, OLTP(local) -> OLTP(remote) and 
both the local and remote WH refreshing from the local OLTP.  The difficulty, 
as I see it, is getting the WH(remote) to sync with the OLTP(remote) when/if 
that situation occurs.

It appears that SRDF would easliy allow that remote WH sync to remote OLTP to 
continue should it be needed.  I'm not sure data guard would support that 
transition as easily.

Steve Smith
Desk: 303-231-5499
Fax: 303-231-5696

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Baumgartel, Paul
Sent: Wednesday, January 23, 2008 2:50 PM
To: oracle-l
Subject: RE: EMC's SRDF vs Oracle DataGuard

I second Jeremiah's comments.  The decision to use SRDF here was made by others 
(probably non-DBAs) a long time ago.  I'd prefer DataGuard for the reasons 
cited.


Paul Baumgartel
CREDIT SUISSE
Information Technology
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
USA
Phone 212.538.1143
paul.baumgartel@xxxxxxxxxxxxxxxxx
www.credit-suisse.com


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jeremiah Wilton
Sent: Wednesday, January 23, 2008 4:14 PM
To: 'oracle-l'
Subject: RE: EMC's SRDF vs Oracle DataGuard

Baumgartel, Paul wrote:

> ...you must consider the hit your write performance will take, especially
given the 
> great distance between locations.  The laws of physics dictate a delay
proportional 
> to the distance the bits have to travel

I think the advantages of DataGuard over SRDF are pretty overwhelming.
First of all, with Dataguard, you can create a decoupled, asynchronous
duplicate site that is almost completely recoverable to the present point in
time.  With SRDF, in order to assure that the database will even open, you
need to be in synchronous mode, which imposes a network penalty for every
single logfile and datafile write.  For heavy OLTP applications the impact
could be dramatic.

SRDF will not protect you against a wide variety of failures that DataGuard
will, such as:

- An errant process that writes over, deletes, or corrupts Oracle datafiles

- User/admin errors and logical corruption: Dataguard can run with an apply
delay

In addition, with Dataguard you have the ability to query and easily back up
the standby with no impact to the primary.  There have got to be a half
dozen other advantages to DG over SRDF that I haven't thought of.  Hopefully
if my SRDF experience is outdated, those with more contemporary experience
will correct me.

Best of all, a DG deployment will survive any future migration to another
storage vendor.  With SRDF you lock yourself in with EMC.

Hope this helps,

Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net

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




==============================================================================
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

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


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


Other related posts: