RE: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?

  • From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
  • To: "'Hameed, Amir'" <Amir.Hameed@xxxxxxxxx>, "'mzito@xxxxxxxxxxx'" <mzito@xxxxxxxxxxx>, "'Jeremy.Sheehan@xxxxxxx'" <Jeremy.Sheehan@xxxxxxx>, 'Oracle L' <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 27 Aug 2009 09:39:10 -0500

We're getting off track here a bit...I'm not really interested in EMC SRDF.   I 
targeting the HP Continous Access (CA) product on an EVA 8x00 SAN.

I'm hoping someone "out there" is doing this and is on this list :)



Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205
Office: 615-517-3355
Cell: 615-354-4799
Email: chris.taylor@xxxxxxxxxxxxxxx<mailto:chris.taylor@xxxxxxxxxxxxxxx>

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and 
may also be privileged. If you are not the named recipient, please notify the 
sender immediately and delete the contents of this message without disclosing 
the contents to anyone, using them for any purpose, or storing or copying the 
information on any medium.


________________________________
From: Hameed, Amir [mailto:Amir.Hameed@xxxxxxxxx]
Sent: Thursday, August 27, 2009 9:36 AM
To: mzito@xxxxxxxxxxx; Jeremy.Sheehan@xxxxxxx; Taylor, Chris David; Oracle L
Subject: RE: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?

SRDF is a nice technology but comes with a premium. To replicate 1TB of 
storage, a total of 4TB is required (source + R1 + R2 + target); something to 
be kept in mind. It also requires a higher bandwidth when compared to other 
replication technologies like Symantec's VVR and EMC's Recover Point.

________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Matthew Zito
Sent: Thursday, August 27, 2009 9:59 AM
To: Jeremy.Sheehan@xxxxxxx; ChrisDavid.Taylor@xxxxxxxxxxxxxxx; Oracle L
Subject: RE: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?



I agree that there are a lot of concerns around synchronous replication of 
datafiles, but certainly, this is pretty much the gold standard in large 
database shops.  Probably every one of my large customers uses something like 
SRDF for their DR.

I think that Data Guard offers many advantages over storage level replication, 
but it is indeed reliable, time tested, and works across any application 
technology, making it easy to sign off on as a DR solution.

Matt


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of SHEEHAN, JEREMY
Sent: Thu 8/27/2009 9:51 AM
To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx; 'Oracle L'
Subject: RE: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?

We use EMC's SRDF method for replication/backups/refreshes.  I'm fairly new to 
it, but as far as I can see, it's reliable and unbelievably fast.  I've seen  a 
full refresh of a 1.7 TB database finish in less than 2 hours.  The refresh was 
taken from a running instance.

Cons - It's expensive....

Jeremy

P Consider the environment. Please don't print this e-mail unless you really 
need to.

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Taylor, Chris David
Sent: Thursday, August 27, 2009 9:43 AM
To: 'Oracle L'
Subject: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?

Any of you guys/gals replicating LIVE datafiles from one SAN to another in a 
remote location?

We're looking at using HP's CA tool to replicate LIVE datafiles across a WAN to 
another SAN.  The replication is block based, so any block that changes on the 
primary LUN is immediately replicated to the remote LUN at the remote site.

Is anyone doing anything similar to this?  Pros? Cons?  I have a hard time 
imagining that this is a good idea but perhaps it is doable.

Thoughts?

Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205
Office: 615-517-3355
Cell: 615-354-4799
Email: chris.taylor@xxxxxxxxxxxxxxx<mailto:chris.taylor@xxxxxxxxxxxxxxx>

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and 
may also be privileged. If you are not the named recipient, please notify the 
sender immediately and delete the contents of this message without disclosing 
the contents to anyone, using them for any purpose, or storing or copying the 
information on any medium.


Other related posts: