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

From: Matthew Zito <mzito_at_gridapp.com>
Date: Thu, 27 Aug 2009 12:20:33 -0400
Message-ID: <C0A5E31718FC064A91E9FD7BE2F081B101D4BA1E_at_exchange.gridapp.com>

It's worth noting that there is an option for most storage platforms to do end-to-end checking of blocks, at least from the HBA to the disks on the array. Oracle has some internal initiatives that would go from memory all the way to the array, but they haven't been fully baked yet.

I tend to recommend storage based replication for folks with "elegant" (read: easy to manage, easy to configure, lots of functionality) storage arrays and not as strong a DBA bench, and recommend Data Guard for folks with strong DBA teams and storage limitations or a weak storage team.

Matt

-----Original Message-----

From: oracle-l-bounce_at_freelists.org on behalf of Tanel Poder Sent: Thu 8/27/2009 11:52 AM
To: Richard.Goulet_at_parexel.com
Cc: ChrisDavid.Taylor_at_ingrambarge.com; Oracle L Subject: Re: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?  

With storage level replication, corruptions coming from Oracle/OS software or host/HBA hardware get replicated to DR site. With Data Guard, many corruptions in redo stream would be detected and not propagated to DR database, thanks to checksums and sanity checks.

Also, human errors, such accidential datafile deletion, overwriting or formatting wrong device etc get replicated without a question and ability to roll it back.

In my mind the biggest benefit of storage level replication would be that you can offload most of your replication to OS/Storage team, without having to come up with different strategy for each database/application in house.

But for Oracle purposes I prefer data guard due all the extra flexibility.

--

Tanel Poder
http://blog.tanelpoder.com

On Thu, Aug 27, 2009 at 11:05 PM, Goulet, Richard <Richard.Goulet_at_parexel.com> wrote:

        Chris,          

            Pros:          

1. For you it's extremely easy to set up. You just sit back and watch the Unix admin do all of the work. I like that.
2. If there is a problem with the solution your not on the carpet for it.
3. If and when you upgrade of patch the remote system gets the update as well, less work. Assuming that ORACLE_HOME is replicated as well.

            Cons:          

1. If the DR database doesn't start for any reason you know who's to blame. You of course.
2. If your database expands onto new luns they may or may not be included in the replication works.
3. Adding a new lun in some products requires downtime because you have to rebuild the remote system.
4. You need a LARGE network pipe between the sites and it HAS to be reliable.
5. If you do have a network issue between the sites your database can hang because the replication software is bogged down. Not likely to occur immediately or in the event of a short outage, but longer outages will get there sooner or later.

            As for expense, yes these solutions are expensive. There's the cost of two identical SANs, the network connection, and the software. But Oracle EE isn't a drop in the bucket either. On the other hand if you've already got EE then replicating via Data Guard may be more cost effective, especially if your not using the standby database as a reporting instance and the network pipe isn't large or reliable.                  

--

http://www.freelists.org/webpage/oracle-l Received on Thu Aug 27 2009 - 11:20:33 CDT