Configuring Oracle Home

[David Totsch]

I have seen Oracle Home (binaries location)
configured into clusters one of two ways:
1) the Oracle Home contained within the package, or 2) each adoptive node
has a private copy of the Oracle Home. Both
of those configurations have their advantages
and disadvantages. However, I am faced with a
customer that has rejected both of those options
for the following: multiple Oracle Homes
configured into separate packages with one of
these Oracle Home packages running on each
adoptive node. Other than adding complexity
to the cluster and a package dependency, I am
having a difficult time listing advantages
and disadvantages of such a configuration.
So, I have a two-part question:

1) have any of you deployed a similar
configuration?

2) any thoughts on the advantages
and/or disadvantages placing muliple
Oracle Homes in separate packages?

Thanx,
-dlt-

[Victor BERRIDGE]

Hi David,
I have no serviceguard...
but I have on an IBM-SP2 4 nodes incluster with HACMP (similar then no?)
I have an independant oracle home on each node, with a user dbaXXX owner of each instances (8).
I can tell by connecting on a node and notice there has been a takeover:
oracle on each node is prefixed by nodenumber:
node 1:
/n1/opt/oracle...

so if I connect to (just like now...) node4
and see:
/n4/opt/oracle...
/n3/opt/oracle
I know I will not be at home for supper...

other advantages: easy to find out the semaphores owner for ipcrm...
Easier updating etc...
only disadvantage is: disk consuming

Best regards
Victor

[Leila Maria Rebel]

David,

I have implemented your option #2: one ORACLE_HOME for each adoptive node.

But I can't see any advantage of having them as a package: when will take place a package switch, once each node has already its own ORACLE_HOME?

Unless you keep there specific configuration files, such as init files, listener configuration, and so on. I have these files out of ORACLE_HOME and those that need to be there, I created a link to an external file system.

Leila

[Ovidiu D. Raita]

Well ... that's a little bit too much.

Let's list the main advantages for both NORMAL solutions:
1. common ORACLE_HOMEs
- main adv. - no need to maintain two different sets of binaries. The advantage vanishes if you maintain two ORACLE_HOMEs in two different packages (as your customer proposed)

so you'll have to consider the second one

2. separate ORACLE_HOMEs
- main adv. - you can upgrade one node, fail the package over and after the everybody agrees that it works, upgrade the second node and fail it back.

If you implement the solution that you customer proposed how do you decide wich set of binaries to use normally and wich during the upgrade? I don't even want to think further. It just doesn't make sense at all.

Complicated cluster implementations ask for more downtime than a stand alone system. Keep it simple and try to convince the customer that the simplicity is the way to go with Service Guard.

Even the idea behind Service Guard is fairly simple: SG monitors some resources and you provide scripts for start, stop, service monitoring and ... whatever.

I'm (We all are) with you,
Ovidiu

[David Totsch]

Thanx to everyone for input. This was not one of the more simple questions on the ITRC forums.

Due to the quick turnaround required, I activated several resources: The HPADM listserver, the Interex HA listserver, the ITRC and some HP contacts.

Here is the pooling of our knowledge:


PRO a. Multiple copies of a required resource.
PRO b. Any adoptive node can run any of the Oracle Home packages. This may be advantageous during Oracle upgrades.
PRO c. The required shared volume group could more easily be dedicated to another cluster purpose.
PRO d. Oracle re-links can happen in a rolling upgrade fashion.

CON a. Additional packages in a cluster contribute to the complexity of the cluster, and, therefore, to maintainability.
CON b. Synchronization of information.
CON c. Changes in an inactive copy of the binaries may render package(s) useless.
CON d. Increases disk space requiremnts.
CON e. Increased work for DBAs to manage multiple copies of every Oracle version.
CON f. It is possible that not all applications in the cluster will be compatible with all Oracle Service Packs.
CON g. Introduces another reason the Oracle binaries may not be available on an adoptive node (halted package).
CON h. MC/ServiceGuard does not monitor disk availability. For proper operation, the package should have a monitor. Configuring the monitors will increase the complexity of the cluster.
CON i. Consumes additional shared volume groups.
CON j. Introduces a package dependency.
CON k. Package testing must test each copy of Oracle binaries.
CON l. During a failover or startup, how does the database package ensure that the Oracle binaries package is running before the database startup is initiated.
CON m. If the Oracle binaries package on the node running a database is halted, it would be the same as a catastrophic failure for the database.
CON n. Careful and possibly complex implementation would be required to prevent failures due to an Oracle binaries package attempting to start on a node that already has one. Not only will the mounts fail, but the normal failure portion of a package?s mount configuration attempts to unmount (by killing processes if necessary ? it could attempt to kill the database to unmount filesystems).
CON o. If more than one database is using an Oracle binaries package on a particular node and the Oracle binaries package files due to a monitor or is halted, the actions will impact more than one database package. To prevent this, each Oracle version would have to be a separate package, increasing the number of packages and the cluster complexity.

I have not been able to verfiy the technical reasons, but I have been told that Oracle Parallel Server may require option #2.

Some of these issues depend on how many Oracle packages you will have in your environment.

BTW: Ultimately, the customer chose configuration option #2.

-dlt-

[Alexander M. Ermes]

Hi David.
I have handled this a different way on a N4000
cluster.
I have one Oracle package on each machine
with an ORACLE_HOME on each machine.
In the package on machine A i have two databases installed with two ORACLE_HOME directories on the disks belonging to the package.
On machine B there is only one database installed on the disk belonging to the second package. If you need to contact me, go for
Alexander_Ermes@web.de

Rgds
Alexander M. Ermes