This content has been marked as final. Show 6 replies
Hi,1 person found this helpful
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 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
Please share if anyone have others opinion.
Local vs. Shared - Use Local - Shared Prevents Rolling upgrade, opatch auto1 person found this helpful
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
I second the above comment on moving on to 11g.
I would avoid using the shared Oracle_Home.
As the advantages of HA override the space usage and time saved during patching etc.
Use local Oracle Homes
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.