RE: Veritas Volume Replicator instead of DataGuard

From: Binh Pham <binhpham15_at_hotmail.com>
Date: Thu, 13 Sep 2007 07:57:07 -0700
Message-ID: <BAY103-DAV127013567982B1E24015AD2C30@phx.gbl>
Message-ID: <067601c7f616$5a81d500$46fc4e89@jpl.nasa.gov>

CJE, Thank you for your information, which are valuable information for me to do further evaluation.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Carel-Jan Engel
Sent: Thursday, September 13, 2007 3:45 AM To: oracle-l_at_freelists.org
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:

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]
	On Behalf Of Carel-Jan Engel
	Sent: Wednesday, September 12, 2007 2:59 PM
	To: binhpham15_at_hotmail.com
	Cc: oracle-l_at_freelists.org
	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.
		
		--
		http://www.freelists.org/webpage/oracle-l
		
		
	
	
	
	--
	http://www.freelists.org/webpage/oracle-l

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

Received on Thu Sep 13 2007 - 09:57:07 CDT