RE: Veritas Volume Replicator instead of DataGuard
- From: "Binh Pham" <binhpham15@xxxxxxxxxxx>
- To: <careljan@xxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 13 Sep 2007 07:57:07 -0700
CJE,
Thank you for your information, which are valuable information for me to do
further evaluation.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Carel-Jan Engel
Sent: Thursday, September 13, 2007 3:45 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Veritas Volume Replicator instead of DataGuard
On Wed, 2007-09-12 at 16:55 -0700, Binh Pham wrote:
CJE,
I'm sure Veritas will counter with:
1. Don't care about bandwidth since there is a dedicated network
for the
transfer.
Bandwidth needed for storage replication easily mounts up to 30 or more
times the amount needed for Data Guard. Whatever dedicated network you have,
I can't mark that as 'not an issue', neither can Veritas.
2. They have 2 modes of synchronization: Synchronous and
Asynchronous in
which case, delays can be configured to take care of the issues of
logical
corruption caused by applications or DBA's...
Synchronous replication might be what you need to prevent data loss. Data
Guard can do both: Synchronous replication of redo (at much less bandwidth
requirements than storage replication) AND have a delay of as much time as
you like (1 hour, 1 day?) in applying the redo. You have protected ALL
commited transactions (the redo is safe at the standby, ready to get applied
to the database there) AND a delay (because redo can be applied later). You
do not have to open the database 'resetlogs' after an incomplete recovery,
but can simply open it read only, recover/restore whatever table you have
(or your developer has) dropped accidently, and resume managed recovery. You
can have the database open in read only mode for reporting during the day,
apply archives overnight and be read only again the next day.
3. This one, a good one, Veritas needs to tell me if they have
integrity checking on the standby side(s). BTW, they also allows 1
to many
and many to 1 replications.
They might be at disk block level, but definitely not on redo vector level.
Sometimes (very rare) Oracle software has a bug. An invalid redo entry will
be discovered by the Managed Recovery process.
4. They can also have slower storage on the standby site with
Asynch
mode.
Yes, but still slower, and definitely Veritas. So, more vendor lock-in.
Any other information?
Storage replication often gives you worse granularity: either all databases
fail over, or none. Depending on 'architecture' (app.servers, webservers,
clients) DG allows you to fail/switch over an individual database easily.
When the replication gets broken, a 'resilvering' might be very expensive,
bandwith-wise spoken. When I have to re-instantiate a Data Guard standby I
often use rsync: Just modified blocks get transfered. That can speed up a
re-instantiate tremendously.
A failover often can be executed by just the DBA. The less kingdoms (Storage
Department, Network Department, Database Department, Application
Departtment) involved the faster, easier and less complex the disaster
mitigation processes will be.
Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
Thanks for the input.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Carel-Jan Engel
Sent: Wednesday, September 12, 2007 2:59 PM
To: binhpham15@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Veritas Volume Replicator instead of DataGuard
Hi Binh,
In my opinion, there are numerous arguments to favour Data Guard
over
disk/san/volume replication. Just to mention a few:
1. Much less bandwidth reuired: just redo vectors get sent
over, not a
full block/cluster/track for every redo wrtite, data file write,
archive
write, control file write.......
2. Configuring a delay in applying archives at the DR site
protects for
'logical' errors as well. That has saved some asses of customers in
the past
3. Applying the archives at the standby implies a sanity check
of the
archives themselves: a bit fallen over (whatever rare it is) in a
disk block
gets detected.
4. Independency of storage architecture: you can afford to have
a
smaller/slower/older SAN at the DR site, as long as you can store
all
database files. You can even afford to have no SAN but JBOD/NAS/DAS
at the
DR site, or just no SAN at all at both ends.
Of course there are some arguments in favour of disk/san/volume
replication
as well:
1. No Oracle license required at the DR site if you do not do
the
sanity checks more often than at 10 days per year.
2. One 'topic of expertise' needed for DR
I can't think of more right now, but maybe my mind is a little
biased ;-)
HTH
Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
On Wed, 2007-09-12 at 14:52 -0700, Binh Pham wrote:
Any one who has used Veritas Volume Replicator in place of
DataGuard
for
disaster recovery or failover setups?
Any issues or problems? Pro's and con's?
Thanks.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
