RE: Replicating Live Oracle DataFiles/LUNs to remote site via SAN tool?
- From: "Matthew Zito" <mzito@xxxxxxxxxxx>
- To: <tanel@xxxxxxxxxx>, <Richard.Goulet@xxxxxxxxxxx>
- Date: Thu, 27 Aug 2009 12:20:33 -0400
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@xxxxxxxxxxxxx on behalf of Tanel Poder
Sent: Thu 8/27/2009 11:52 AM
To: Richard.Goulet@xxxxxxxxxxx
Cc: ChrisDavid.Taylor@xxxxxxxxxxxxxxx; 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@xxxxxxxxxxx>
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.
Other related posts:
