In general, shared homes for Oracle Grid Infrastructure (GI) are not recommended and in fact will not be supported in the future. But how about the RDBMS home? In this article, we’ll examine this option.
It is often tempting to think that having a single shared home is the simpler, and therefore better, solution. After all, especially with many nodes in an environment, installing, patching, and running backups can become complex when many copies of the same software are spread across multiple nodes. In addition, configuration and log files are distributed across all nodes, making it more difficult to view, monitor, and maintain them. Having everything in a single, shared home, where installs need to be done only once, with all of these files being centrally available, would seem to be the Nirvana of DBA-dom.
However, as a Maximum Availability Architecture (MAA) DBA, you should be aware of some of the downsides of this type of environment as well—for example, the option to perform a rolling upgrade of your Oracle RAC environment or to apply patches in a rolling fashion are key elements in maximizing your availability, and key components of the Oracle Database grid. If you decide to set up your environment with a shared RDBMS home, it is more difficult to implement rolling upgrades or apply patches in a rolling fashion, since there is only a single copy of the software. In most cases, you must take down the entire software stack across all nodes to patch or upgrade. Another consideration in the same vein is that a shared Oracle home can be a single point of failure in other ways. Any damage to the binaries—whether from a file system corruption, hardware error, or human error of any type (deleting/overwriting of files)—will affect all nodes.
Oracle has recently introduced the concept of hot or online patching, which mitigates this argument for some patches; however, limitations to online patching prevent this from being used in all cases. With respect to rolling upgrades, if a standby database is available, rolling upgrades with a standby database can still be achieved with minimal downtime, even with a shared home. Nevertheless, a shared home still needs careful consideration before implementing your mission-critical environments.
Finally, it’s generally a good idea to be in the mainstream. As of now, the predominant install variant in the user community is to have “homes on a private drive.” If being part of the mainstream is important (which it should be for an MAA DBA), this is the option that gives you the most “company” in the world of the Oracle grid. Of course, over time, things will change and evolve, as always, but for the time being, we would advise going the route of private drives for the Oracle RDBMS home. The Oracle Universal Installer and the Oracle OPatch utility have both evolved to the point at which management of multiple private homes, even for a large number of nodes, is very manageable; the advantages of having separate homes on private drives outweighs the downside of the additional work necessary to manage these homes. The fact that Oracle Enterprise Manager (OEM) makes the control of many homes easy is another final point in favor of such a setup.