Hope you all are doing well.
We are preparing a new Oracle RAC DB (10.2.0.5) on HP-UX platform;
Lets have a look on the environment below:
1. Two node RAC cluster
a. Hardware: HP BL890c i2
b. OS version: HP-UX itanium V3
c. DB version 10gR2(10.2.0.5)
2. File System:
a. shared CFS (managed by MC Service Guard)
b. Local Filesystem (LUNs are coming from SAN)
1. which option should we choose to install Oracle Database and CRS Software. Please mention the pros and cons of each options.
a) Install software on local (SAN). In this case we shall have separate ORACLE_HOME and CRS_HOME for each node.
b) install software on shared CFS (SAN). In this case we shall have a shared ORACLE_HOME and CRS_HOME for both nodes.
I have read the following article but still need a solid reason behind choosing anyone of them. http://prodlife.wordpress.com/2008/06/19/oracle_home-to-share-or-not-to-share/ http://www.orafaq.com/node/66
Why use private home?
Easier rolling upgrades. If you need to patch your DB you can patch first one node and then the other, allowing for 0 downtime patches. You can have rolling upgrades on shared home as well, but it is a longer procedure and not supported automatically by OPatch.
You can’t lose your entire cluster by a careless delete. Never underestimate the impact of human errors.
With shared home, mistakes done in ORACLE_HOME impact the entire cluster.
With private homes – mistakes impact just one node.
Add node / Delete node procedures are somewhat simpler (but take longer) on private homes. Especially when doing delete node, you don’t run the risk of deleting the shared oracle home by mistake. Very scary!
Starting 10.2.0.4 Oracle demands that at least the oraInventory will be local.
Oracle recommends local home. Sometimes, that’s a good enough reason.
=====>Agree 100% Agree for production setup
Why use shared home?
Quicker installs and upgrades, because there is no need to copy all files twice, over the interconnect.
If your shared storage is advanced enough to support snapshots, you have the ability to take a snapshot of ORACLE_HOME before applying a patch and simply restoring the snapshot if the patching went wrong.
You can really easily migrate nodes or entire DBs from server to server that way.
No version compatibility issues between different nodes on cluster. You know that all your nodes are always running exactly same version, patches, etc.
You don’t have to ssh from server to server while trying to track issues in alert logs and dump files.
Shared storage tend to be more stable, have checksum, striping, mirroring and other nice stuff. With ORACLE_HOME on this storage, you are less likely to lose a node to media failure. Agree for test database environment
Local vs. Shared - Use Local - Shared Prevents Rolling upgrade, opatch auto
Why are you installing an almost de-supported version? 10.2.0.5 is the terminal release. Time to upgrade to 11g.
There are hundreds of performance reasons to dump 10g and move on to 11g. ASM on SAN in 11g is a LOT better than file system - my experience is 10-20% without tuning anything. YMMV. The OEM Database control in 11g is Very good and the 12c Grid Control is even better...
The Grid Infrastructure is 11g is infinitely better that the 10g version as well - a LOT more manageable.
Edited by: onedbguru on May 2, 2012 5:20 PM
Thanks a lot for the suggestion. But right now we can not upgrade the DB to 11g because the version is not yet certified by the application(telecom billing system) will be running over there.
I would have your company force the billing software company to bring their code up-to-date. I can probably guess which company to which you are referring and they were notorious for lagging on their version certs. Running un-supported vendor code (in this case Oracle 10) makes your entire system unsupported and places your company at great risks. Just my $.02 worth.