Video Screencast Help

VVR For Oracle with several DGs as part of SF HA/DR

Created: 20 Oct 2012 • Updated: 21 Oct 2012 | 5 comments
yairz's picture
This issue has been solved. See solution.
I know this has been discussed several times in this forum in the past, but I have yet to find an answer that provides sufficient information to my situation.
I am currently setting up a DR configuration for three Linux servers running Oracle 10g - two in the primary site and one in a DR site.
The two servers in the primary site are running Oracle in an SF HA configuration (version 5.1 SP1 RP2) and due to customer request, the Oracle data is split between several Disk Groups - Oracle Data DG, Oracle Archive DG, Oracle Temp DB DG, Oracle Redo A DG and Oracle Redo B DG.
Customer wants to replicate all the above Disk Groups (there's also a backup DG and a software DG which won't be replicated) and has sufficient storage for SRL and network bandwidth to perform the replication in a-sync mode in addition to configuring VCS Global Cluster to control all the configuration during DR failover.
I have completed all the setup required between both sites and have only one question I haven't been able to answer:
I understand how VVR works with SRL to ensure that writes on the secondary are performed in the same order as they were in the primary, and I know that for flat files applications, if the secondary is consistent (which it should usually be) I can failover to the DR site and might have a certain data lose but still be able to bring the application online.
My question is, if I have several DGs for Oracle DB, how can I make sure that the Database at the DR site will be consistent and will be brought online successfully by VCS when the primary crashes or when the network is disconnected between sites (I'm not referring to manual DR failover).
Can I expect to find the DB on the DR site in a status in which I have to manually perform operations with Redo logs or control files checkpoints to bring the DB online?
Is there any special attributes in VCS I should make sure to configure in order to support said situations?
As I am not a DB admin, I don't fully understand how Oracle behaves in certain situations. 
Any advice would be much appreciated.

Comments 5 CommentsJump to latest comment

mikebounds's picture

The only waythis can possibly work with separate DGs is if you use synchronus mode so that VVR is never behind, but if you have a network outage then during when VVR catches up, you will be inconsistent.  In asynchronus mode, there is no way to keep the data consistent with multiple DGs - see which links to for more information.  There is nothing in VCS which will help with this.

But there is no need to have multiple DGs.  Some DBAs still believe you need to put data, redo, etc on separate LUNs and even though this makes little diffence these days,but this is OK, you can still keep data, redo on separate LUNs in the SAME diskgroup.  So you should join your diskgroups and all this means is if you need to extend filesystems in the future you just specify LUNs to extend on to to make sure data, redo, etc stays separate.

To join diskgroups you can use vxdg join so something like (will need to be done offline while Oracle is down and filesytem umounted):

vxdg join redodg datadg
vxdg join archdg datadg
vxdg deport datadg
vxdg import -n oradg datadg

The last 2 commands are required if one of the existing diskgroup names is not an appropiate name for a diskgroup containing all Oracle files so you need to rename diskgroup.  You will also probably have to add new LUNs to your diskgroup for the SRL.

To use vxdg join you will need an Enterprise licence.  You may be able to "borrow" an enterprise demo license from Symantec as it is only a one off operation or if you have a spare server on the SAN, you could install VxVM 6.0 on it which comes with demo licenses built in, then import diskgroups, join them and then reimport on your 5.1 systems (only join DGs, do not create any new ones on 6.0 system as this would not be compatible with 5.1 unless you create with "-T" flag to specify 5.1 DG version).


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

yairz's picture
Thanks for the information Mike.
Unfortunatley for me, those DBAs you were referring to are like the ones I'm working with on this project.
I tried talking them into putting everything into one DG when we started the project, but they wouldn't even consider it. A little old-fashoined, IMO.
I sure wish the information you gave me was in the documentation somewhere, that would have helped me prevent the situation I'm in right now.
Also, I assumed that since data is written to the Redo log first and only then to the data files, it will be sent to the Redo log in the DR site before it will be sent to the data DG of the DR site, and that will help ensure DB-level consistency at the DR site.
as far as you understand from my configuration, can I expect to have an unrecoverable DB at the DR site in case of crash in the primary site, or will Oracle be able to recover automatically (or manually for that manner)?
mikebounds's picture

Hi Yair,

It is unlikely you will be able to recover Oracle automatically or manually because the data files and redo files are unlikely to be at exactly the same point in time because they are in effect independent.  It is fair enough for DBAs to say where they want the data on the LUNs, but this has absolutey no bearing on whether the LUNs are in in different diskgroups or in the same diskgroup - this is a logical arrangement of the data and has no effect on the physical arrangement of the data and therefore it is nothing to do with the DBAs and will not effect the DBAs in anyway if you change to one diskgroup.  You cannot use async VVR with multiple diskgroups as it does not provide a usable DR as it is likely the data will be unrecoverable, so you have to convince the DBAs to use a single diskgroup and I know this is hard because I have been in the situation and really you just need to ask why and the answer is usually they want to keep data separated and this is fine - separate diskgroups are not required for this.  If your diskmedia names do not contain the name of diskgroup, then I would rename these (and the subdisks) before you join the diskgroups - if you don't know what I mean, please provide output of vxprint for each diskgroup and I will show you what I mean - this helps the DBA's understand what is going on.


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

mikebounds's picture

Just to make it clearer - suppose you have Oracle in a good state and then you write (in time order)

A B C D   (A B are in redo log and C D are in data files)

and then Oracle is in good state and you then write some more

E F G H  (E F are in redo log and G H are in data files)

and then Oracle is is good state

So if VVR in a single diskgroup has written up to E then Oracle can recover this as the data at DR looks like Prod at a particular point in time and it can roll back so that it has "A B C D"

With mulitple diskgroups, you could be in a state where on the DR site you have:


i.e you have redo up to E and data up to C, or you could have:

A    C D


i.e you have redo up to A and data up to G.

In either of this scenarios, the data at DR does not represent any point in time that the Prod was at - it was never like this and therefore Oracle will probably (or maybe certainly) not be able to recover and there is no way to do this manually.


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