Oracle and ServiceGuard

[Adam Garsha]

When installing oracle (or when your DBA's install oracle) on a fresh multinode ServiceGuard cluster. What do you do to replicate oracle files that land in non-shared locations (e.g. under /,/var,/usr)?

Namely, I can account for ORACLE_HOME,BASE,TMPDIR, etc... these are all on shared storage that I can fail from one node to another.

However, oracle also can shove stuff in places like /var/opt/oracle and /etc/oracle and... you name it.

What do you folks typically do to replicate this stuff to allow proper startup of packages on virgin nodes (nodes other then the one that the initial install was performed on).

Thanks for any advice or links or best practice docs.

[Peter Godron]

Adam,
please see:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=989327

Or if you want to overkill on info:
search for "Oracle ServiceGuard install"

[Doug O'Leary · Accepted solution]

Hey;

There is no short answer (short of pointing you at another link! :) ). MCSG, or any clustering technology for that matter, comes with constraints that both the system admin and the application admin have to live within if the cluster is going to work as advertised.

That being said, there are two models for clustering packages. Neither is inherently better or worse than the other; they both have their own pros and cons. When creating packages, you and your application team have to pick one of these models and stick with it.

1. All data and binaries required by the application reside within the package. The pros to this is that everything required by the application is in one discreet manageable set. The cons being that it's much harder to patch/upgrade/otherwise manipulate the binaries/configurations w/o affecting the data.

2. Data is in the package; application binares are on local disk. The pros/cons for this one are pretty much the opposite of the first model. You can patch/upgrade the binaries on one node while the application is running on the other, then fail the package over, and repeat the process for the other node. The cons are that you now have two sets of binaries/configuration files that have to be kept in sync.

Even in the second model, though, all the data required by the application *must* be on relocatable disk. If oracle start stashing control files on local disk, then the package will not fail over correctly because the control files on the adoptive node will be out of sync and the databaes will not start.

Shorter answer to your question is it's a training issue. Inform your dbas that anything and everything required to start the database *must* be on relocatable disks.

HTH;

Doug

[Adam Garsha]

(points later)

Most posts assume local-to-the-node ORACLE_BASE. We want to have shared ORACLE_BASE--I don't want to argue merits, assume we've worked both ways and like it shared.

I guess what I am trying to say is: all the links I've found basically install bits on each node locally and let only ORACLE_HOME and db and arch filesystems float between boxes.

I want to share it all baby:) I want it all to float, using CFS for ORACLE_BASE and ORACLE_HOME, and floating packages for single instance db and arch filesystem failover/migration.

i.e. more RAC like. more like Trucluster.

Hence, back to my question about the dangling files.

[Adam Garsha]

Fair enough. I am only being proactive because my DBA's probably won't hit the mark if I don't sheppard them there.

I'll close this post in a day if nobody has any additional pearls. and I'll just figure it out.

Key question again is not the primary oracle stuff (ORACLE_*), but the "side-show" stuff like /var/opt/oracle and /etc/oracle.

[Doug O'Leary]

Hey;

You could create soft links from those files to relocatable disks. I would strongly urge you not to do that, however, as it makes you responsible for ensuring they're updated. The oracle dba can create another control file anywhere he wants w/a simple sql statement.

You have to know about it, move it, and update the link whenever they do that...

Much more efficient to ensure the dbas are aware of the clustering constraints.

Doug