Oracle in service gaurd

[ShivKumar_1]

when you have Oracle in a service gaurded environment lets

call the two boxes A and B.
Suppose there is a instance 1 running on Box A and Instance 2 on

Box B, both are sharing the common disk on EMC. Suppose the box B fails will , the instance

be shifted to Box A?
Also frm the UNIX admin point of view, have the file system on A

& B be identical? Even though they r running difft instances?

For Eg

Box A BoxB Mounted
mounted
/dev/vg02/lvol1 /u01/oracle /dev/vg01/lvol1 /u04/oracle22
/dev/vg02/lvol2 /u02/oracle/oracle2 /dev/vg01/lvol2 /u03/oracle25

Say for eg: the instance 3 is on box B , what should be the file system layout on box A or

in other words for the instances running on /u04 and /u03

[Rita C Workman · Accepted solution]

If you have designed and configured your MC/SG packages correctly.....then:

If you have set your pkg controls scripts to allow the package to 'failover' automatically then yes it will. Or you may prefer, as some do, to manually control failover.

Remember, in a properly configured MC/SG environment your volume groups (and what's on them) are being controlled within the 'package'. So if in your 'package' you have put everything you need to run that instance...then yes you should be able to come up on the other node.

You may decide that you only want to run the instance on B when it fails over to A..in that case you would script for that condition within your pkg control scripts and take down the A instance on A, allowing only instance B to run on A.

Like I said...it all depends on how well you have designed and configured your MC/SG environment.

Hope this helps,
Rita

[Brian M Rawlings]

One point of clarification -- both servers may be sharing the "disk", but what they are really sharing is "shared storage". Any given VG can only be activated by one server at a time, with the file systems defined by your package mounted up however you specify in the 'mount' section of the package script.

So, at a high level, as Rita says, it depends on how you set things up. But, supposing you were doing active/active clustering with two nodes, each of which is running one package. Within the package on each node is Oracle, running on file systems that are contained in Volume Groups that are themselves contained in seperate LUNs on your shared storage array.

Then, if node B fails, MCSG notices this, consults the cluster scripts, finds that autofailover is on, and that there is another node available to run package B. So, it activates the VG on node A, mounts the 'oracle' file system per the script, and starts oracle instance B up on node A. Also, the IP address to access Oracle-B also moves over to node A.

Obviously, lots of thought has to go into this, whether the Oracle binaries are in the package, or in root file systems (which don't move). Plus, how do the clients connect, meaning you need to use the 'portable' IP address that follows the package, and not the hostname or host IP. That sort of thing.

Hope this clarifies more than it muddles...

--bmr

[Gary Yu]

if I understand you correctly, I think you should configure 2 Oracle instance on BOTH servers, and on the MC/SG level, you can define which one running on which sever primarily.

and to make things easy, you should configure the 2 oracle instance identically on each server, i.e. instace Ora1's table space on /u01 and /u02, instance Ora2's table space on /u03 and /u04, in your MC/SG package you can define /u01 and /u02 mounted to HostA where Ora1 runs, /u03 and /u04 mounted on HostB where Ora2 runs. When a failover happens, /u03 and /u04 can be mounted on HostA, and Ora2 can also started there.

thanks,
Gary

[Rita C Workman]

Yes Gary you could do it that way...

For myself, I like to keep things to a minimum. So for each box I use same mountpoints. Example: /apps and /ora is where is set my binaries. Now each server has these mountpoints...but each is on a different volume group. The developement is /dev/vgdev/lvapps /apps
/dev/vgdev/lvora /ora
The production is
/dev/vgprod/lvapps /apps
/dev/vgprod/lvora /ora

Remember, within the package you take activate/de-activate the volume groups....so when I failover, my mountpoints are still the same, but what is now active is the volume group ! My dev box is running Oracle (with patches being tested), so I don't want to run my production with dev's binaries...ergo when I failover the script takes down the /dev/vgdev...and starts /dev/vgprod - but all to the same mountpoints.

Remember mountpoints are just a hook to hang something on.

Now if you want to create more mountpoints, that's ok...I just like to 'kiss' my systems. (keep it simple 'sweetie').

Just a thought,
Rita

[Brian M Rawlings]

"Sweetie". Nice. Have you considered a career in the diplomatic corps, Rita?

8^)

[Jakes Louw_1]

You have some choices to make:
- Do you want to fail the Oracle binaries over with the instance? We don't, but that's your choice. We use the seperate /app/oracle directories/filesystems on each machine as a method to do a rolling upgrade of Oracle: fail over package A to a server with the latest Ora installed, and then upgrade the instance.
- Do you want to fail over all the INIT.ORA stuff with the instance, or have a non-HA admin filesystem that you need to keep up to date (no prizes for our choice..)

Other things to consider are keeping /etc/oratab and so on up to date on each box, having a generic Oracle HA startup script that uses maybe the output from CMVIEWCL to decide what it needs to do, and so on.