RE: EMC's SRDF vs Oracle DataGuard

From: Baumgartel, Paul <>
Date: Wed, 23 Jan 2008 16:50:26 -0500
Message-ID: <>

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
Information Technology
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
Phone 212.538.1143

-----Original Message-----
From: [] 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:

> must consider the hit your write performance will take, especially
given the
> great distance between locations.  The laws of physics dictate a delay
> 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


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

Received on Wed Jan 23 2008 - 15:50:26 CST

Original text of this message