Message-ID: <BAY103-DAV127013567982B1E24015AD2C30@phx.gbl>
From: "Binh Pham" <binhpham15@hotmail.com>
To: <careljan@dbalert.eu>,
 <oracle-l@freelists.org>
References: <20070911133643.B8CFF1158CC@ws1-7.us4.outblaze.com> <46E80CA3.8030709@gmail.com>  <05de01c7f587$3ad81be0$46fc4e89@jpl.nasa.gov> <1189634345.1671.69.camel@lagavulin.dbalert.eu> <062e01c7f598$5cf39590$46fc4e89@jpl.nasa.gov> <1189680276.1671.110.camel@lagavulin.dbalert.eu>
Subject: RE: Veritas Volume Replicator instead of DataGuard
Date: Thu, 13 Sep 2007 07:57:07 -0700
Message-ID: <067601c7f616$5a81d500$46fc4e89@jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <1189680276.1671.110.camel@lagavulin.dbalert.eu>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: binhpham15@hotmail.com

CJE,

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


-----Original Message-----
From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org]
On Behalf Of Carel-Jan Engel
Sent: Thursday, September 13, 2007 3:45 AM
To: oracle-l@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:
	
	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@freelists.org
[mailto:oracle-l-bounce@freelists.org]
	On Behalf Of Carel-Jan Engel
	Sent: Wednesday, September 12, 2007 2:59 PM
	To: binhpham15@hotmail.com
	Cc: oracle-l@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