Video Screencast Help

how VVR can provide the data integration for oracle database files

Created: 25 Aug 2012 • Updated: 25 Aug 2012 | 5 comments

Hi all:

one of my customer want to build a disart recover cluster for oracle db on WAN. They choose an opensource DRBD  solution before, but they got some trouble on it . We sugguest them to choose VVR to do this. But we are wondering how VVR can provide the data integration for oracle database files like control file and redo log in async mode.  In DRBD async mode, when the primary node failed, sometimes the oracle database file (control file or redo log) on backup node  will be corrupt because some block  transmission lost. 

Comments 5 CommentsJump to latest comment

mikebounds's picture

VVR ensures data is consistent for any application/database as it using an SRL (Storage Replicator Log) to store the writes in the order they were written, so in async mode it simply drains the wites so the data at the secondary site will always be a point-in-time copy of the primary and if the bandwidth is sufficient then the data will often be sub second up-to-date, depending on the latency of the replication network link.  For a database you just put everything (excluding temp if this is used a lot) under VVR control (control file, redo logs, archive logs, data files)

With VVR, the secondary is only ever inconsistent (corrupt) during a DCM replay/resync, but this is manually initiated, so you can take a snapshot before you initiate a  DCM replay/resync so that you aways have a consistent copy. See post https://www-secure.symantec.com/connect/forums/where-can-i-verify-consistent-data-under-vvr for more details.  

Note one downside of VVR is that it replicates a lot more data than Oracle Data Guard (ODG) as ODG just effectively replicates redo logs, but VVR replicates redo logs, archive logs, datafiles and rollback segments so on average replicates 3 times the amount of data, so you need more bandwidth if you use VVR.  Advantages of VVR is that it is easier to manage, it integrates better with VCS and is better for copy-on-write (COW) snapshots at secondary site so you can do a firedrill (bring database up on a snapshot to verify data is ok at secondary).  With ODG, if you do a snapshot, I believe updates to the real data are transferred, but not applied while the snapshot is in place (this doesn't happen in VVR) which means if you had a disaster while snapshot was there you would have to wait while changes were applied.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Jamesb_china's picture

Thanks for your advice. But I still have wondering.   If We get the following situation

 

Primary                       Secondary                            SRL

X Y Z                           X B C                                   Y Z                    

D E F                          D E F 

 

In file system level , it may be consistent and up to date. But in oracle data file level ( control file or redo log) , can it ensure to be consistent ? 

mikebounds's picture

As long as all volumes are in the same diskgroup, then VVR makes sure each volume is consistent with the others so if the writes are in this order:

X is written to oracle data file on filesystem /oracle/datafiles
Y is written to oracle redo log on filesystem /oracle/redo
Z is written to oracle data file on filesystem /oracle/datafiles
 

then VVR will not write Z until it has written Y, so VVR doesn't just make sure  /oracle/datafiles is consistent, but that it is consistent with  /oracle/redo and all other filesystems in the diskgroup.  It does this as there is only one SRL for all the filesystems in the diskgroup which contains writes, X, Y & Z in order.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Jamesb_china's picture

I test oracle on DRBD, and the following error occurs, 

 

 

ORA-00214: control file '/oradata/orcl/control01.ctl' version 79111
inconsistent with file '/oradata/flash_recovery_area/orcl/control02.ctl'
version 79104
 
 
that means when X is written to control01.ctl, Y is written to control02.ctl, but when x is completely transmitted, and network broken, oracle on secondary node can not be start normallly. 
 
How does VVR do to avoid this situation? 
mikebounds's picture

This is the same as the server crashing, so suppose Oracle writes X to control01.ctl, but before writing Y to control02.ctl, the server crashes, then Oracles may not start "normally" when the server comes back, but Oracle should be able to recover to a consistent state and the same will happen with VVR.  Where Oracle may not be able to recover is if Y is written and not X, and this will not happen with VVR, but may happen with DRBD as I had a quick look at DRBD at there does not seem to be any equivalent to SRL so I can't see how DRBD can keep data consistent is async mode.

Mike 

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below