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

I'm afraid this is incorrect. To be clear, such an architecture is possible, and is usually used for snapshotted replication - i.e. you have a source, a BCV pair that is your R1, you synchronize BCVs periodically, and snap them, which is how you would do point in time replication in a Symmetrix environment.

However, equally valid is to have your primary hypers be the R1 configuration, with the R2s at a remote site. Indeed, this is the recommended/default configuration for the Symmetrix, since it offers continuous protection.

As far as the other solutions you mention - RecoverPoint is nice, but requires a very specific configuration, and is definitely off the mainstream. As far as the bandwidth utilization - I'm not sure how RP would offer lower bandwidth, except if you've custom integrated your database with their solution and were using it for point in time snapping.

VVR offers no benefits over DataGuard, except that you can replicate the Oracle home as well. Beyond that, it runs on a host level, so you still have additional CPU cycles being spent on replication housekeeping, and it requires similar storage configurations on both sides in order to function properly.

The way I look at it, replication at a storage array level pros:
- Replicate anything - replicate not just your datafiles, but your oracle_home, your scripts, your backup locations, your third-party agents, everything. When I was at EMC, I even had a customer replicate their entire datacenter by running diskless servers booting off of a Symmetrix where everything was replicated to a remote datacenter

• Storage admins problem - the DBAs don't have to worry about care, feeding, housekeeping, the storage team manages it
• Very time-tested and reliable - even outside of SRDF, storage based replication technologies have all been proven to work time and time again

Storage level replication cons:
- Like swinging a very big hammer - it's a heavy tool, not a finesse solution - you get very few controls over what happens, limited number of supported configs, it can be bandwidth inefficient, and can require a lot of infrastructure

• Often requires dedicated infrastructure - dedicated WAN links, SAN switches, DWDM, etc. etc.

Application level replication pros:
- More efficient - since the application is doing the replication, it knows more about what needs to be pushed where, and hence can use less bandwidth/infrastructure resources

• Finesse solution - things like apply delays, multipoint delivery, opening the database read-only, all very elegant options that are not usually available with storage level replication

Application level replication cons:
- Cost - you have to pay for application licensing for the target side, something you typically don't have to do for storage replication

• More DBA work - now you are responsible for the care and feeding of the replication, and I can tell you, DataGuard is vastly harder to set up than SRDF or SnapMirror
• Higher CPU utilization - after all, your host now has to push those byes around, instead of a dedicated box or storage array.

Just my .02.

Matt
-----Original Message-----
From: Hameed, Amir [mailto:Amir.Hameed_at_xerox.com] Sent: Thu 8/27/2009 10:35 AM
To: Matthew Zito; Jeremy.Sheehan_at_fpl.com; ChrisDavid.Taylor_at_ingrambarge.com; 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Matthew Zito
	Sent: Thursday, August 27, 2009 9:59 AM
	To: Jeremy.Sheehan_at_fpl.com; ChrisDavid.Taylor_at_ingrambarge.com; 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_at_freelists.org on behalf of SHEEHAN, JEREMY
	Sent: Thu 8/27/2009 9:51 AM
	To: ChrisDavid.Taylor_at_ingrambarge.com; '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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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_at_ingrambarge.com<mailto:chris.taylor_at_ingrambarge.com>
	
	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.
	
	
	

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