HELP Mr Clay Stephenson - on Apps 11i + MC service guard

[Lee Yam Fong]

Hi Clay,

I've asked this question on Oracle support forums but without success. I found this HP site by chance and found
you were very helpful and just replied a question similar to my problem, so I ask here.

I'm going to install Oracel Apps 11i on HP platform with 2 N class servers running in primary/standby mode in the database tier and another N class node as the application server.

How should I install the database nodes? Can I install all
executables and database on shared vols in the primary
node first and then configure MC service guard later on?
When the primary fails, the standby node can mount the shared volumes and restart the database engine using
binaries on the shared vols.

The benifit of this approach is I keep a single copy of
executables and database, it is easier to sync versions
by applying applications patches once only.

Local Oracle support recommends installing database engine locally on each node and put the database on
shared vol. I wonder how this can be done since
rapidwiz installs BOTH db engine and database together
(giving me 2 databases?). And there is the question of
applying apps patches, most apps patches update
executables + database. If I apply patch in primary
node and then the standby node, the database will
be updated twice!!!

HELP please!

[Carsten Krege]

You should refer to this thread. It gives you some suggestions.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x1f6a87dc4d7dd5118ff00090279cd0f9,00.html

Carsten

[Lee Yam Fong]

Carsten,

Thanks for your feedback.
I've already read this thread before.
I need suggestions specific to the installation of
Oracle applications rel 11i on MC cluster.


Joe

[melvyn burnard]

The point smade in the thread that Carsten points you to ar estill valid. If you have a shared executable set, to make any changes the entire application must be halted.
You are far better off have separate local executables, as this gives you more flexibility in patching/testing etc.

[Magdi KAMAL]

Hi Lee,

You better install Oracle engine on internal disk as recommanded by Oracle Corp. You may play around of disk unavailability if there is a problem with the shared volume that you try to intend using it as a commun volume.

You may next congigure MC Service/Guard to define a package which will has the primary server as server1 and the alternate as server2.

This package will have the responsability to mount the volume group where the Databases are: If the primary server goes down, the package can still start on the alternate server and mount the shared volumes ( with Logical Volume Manager).

Planing steps:
1. Oracle engine on internal disks on the two N class server.
2. Configuring MC / SG to start a database package which consider primary and alternate server ( server 1 and server 2 ).
3. Databases are on shared volume groups.
4. It is the responsability of the database package to mount the shared volume group.


I would say that the process of installing the application executables is not difficult ( normally with swinstall, otherwise with remote shell ).

HTH
Magdi

[Manuel Abellan]

Hi Lee,
I saw your note and was wondering if you ever managed to put the oracle Apps 11i on serviceguard. I will be trying next week and was curious to know how it went.

[A. Clay Stephenson]

Hi:

I don't really have a hard and fast answer for you. I've certainly installed Oracle both ways and both have advantages and disadvantages. The main advantage of moving the Oracle binaries with the package is , as you noted, one set of executables to keep in sync. The downside, is that, unless you are VERY careful about patching both hosts (especially shared libraries) then there is a chance that the executables may not execute when switched to the other node. I will say that most of the time, I do move the binaries (including it's own listener) with the package. I always run identical hosts and always keep them patched exactly the same. I also always have a test environment on other hosts that let's me test everything before deployment in production.

If you are going to move the binaries with the package, make certain that your executables filesystem has plenty of free space so that you can install the next Oracle version there as well. I'm not just talking about enough room for a minor release but enough room to install a major release and keep your current version. That way you can install a newer release plus a demo database so that you know you have a viable install before doing the database conversion. I have never had a problem installing a new version in package filesystem while keeping the current Oracle instance in production. Bear in mind that it is not the install of a new Oracle version that leads to a significant amount of downtime but rather the time required to upgrade the database.

I will say the one kind of configuration to avoid at all costs is the one where Oracle is tuned differently when the package runs on one hosts as opposed to when it runs on another. This is not as crazy as it sounds because often your main host might be a fast N-box with lots of resources and your failover might be a small D-box with limited resources. It's a way to save money but you have to have separate init.ora's for both cases (at least if you want to take advantage of the bigger box's resources). The problem is keeping the two init.ora's up to date AND being able to test both.

I've really not given you an answer because, again, it depends.

Food for thought, Clay