ORACLE_HOME – to share or not to share

When setting up a RAC system, one of the questions that tend to come up is whether to have one ORACLE_HOME per node on local disk, or to have one ORACLE_HOME for both instances on the shared storage. These approaches are sometimes called “private home” vs. “shared home”.

Oracle have an amazing white paper on the topic, which I’ve been reading for the last two days: http://www.oracle.com/technology/products/database/clustering/pdf/oh_rac.pdf

We have both types of systems here (because we have two teams of DBAs with somewhat conflicting procedures), and I worked on both. As with many questions, there are pros and cons to each approach, and you decide based on your priorities. The paper (highly recommended!) covers almost all the pros and cons in lots of details. However, I still want to give here a short summary, based on my experience.

Why use private home?

1. 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.
2. You can’t lose your entire cluster by a careless delete. Never underestimate the impact of human errors.
3. With shared home, mistakes done in ORACLE_HOME impact the entire cluster. With private homes – mistakes impact just one node.
4. 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!
5. Starting 10.2.0.4 Oracle demands that at least the oraInventory will be local.
6. Oracle recommends local home. Sometimes, that’s a good enough reason.

Why use shared home?

1. Quicker installs and upgrades, because there is no need to copy all files twice, over the interconnect.
2. 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.
3. You can really easily migrate nodes or entire DBs from server to server that way.
4. No version compatibility issues between different nodes on cluster. You know that all your nodes are always running exactly same version, patches, etc.
5. You don’t have to ssh from server to server while trying to track issues in alert logs and dump files.
6. 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.

---