Shared Oracle Homes


o Recovering from machine failure - mount the Home and Datafiles mounts on another server, do a little config and you are back up and running.

o Bringing newly installed machines into the 'fold' is a lot easier than firing up OUI and waiting for the install to run. Even if you have it scripted with a response file this can be painful to wait for. Basically we mount the home mount and run for the specific versions of Oracle Database that we want to support on that machine.

o You are guaranteed to be running the same binaries everywhere. If you need to move a DB From one server to another this is a big plus.

o We push a copy of our OHOME mounts to our remote DR site in parallel with the datafile backups so we can easily bring up any DB there as well.

o We have a /u01/app/oracle/script directory with our custom commonly used shell scripts, it is nice to know they are available everywhere and are all the same version no matter where I access them from.


o Learning curve and just getting comfortable with it. I tiptoed around the new-to-me config for a couple of months before I was comfortable.

o OraInventory issues. Your inventory may not be 100% up to date since you are doing an end-run around it to make the Oracle Home available to different servers.

o Once a set of binaries is installed and pached we don't touch it. To patch we create a new Oracle home. When multiple DBs use the same patch level this is great, when they start to diverge it can get unwieldy. Decide on a naming convention with some good descriptive home directory names from the get-go.

o Get familiar with as you will probably need to leverage it to use the binaries for the first time on a new machine/VM.

o Make a mistake in one place and it can bring everyone down. We hit an OUI issue that started deleting all the files from our shared home. One by one groups of systems started dying. We finally found the process, stopped it, an restored our backup... and restarted a few hundred databases... that was a hellish day for sure.

o Getting used to some heavy use of symbolic links. Our /u01/app/oracle/admin/DBxx directories live on the OHOME mount... but it only has symbolic links to directories on the shared storage.

o I would suggest different OHOME mounts for Dev/TEst and Prod. No reason for a testing issue (like mentioned above) affecting Prod when it doesn't need to.

o DB Names can't be used twice for the same home due to config in /dbs directory.

o Put a log management plan into place for the misc logs that have the potential to stack up in various Home directories.


Oracle Home : To Share or Not To Share Oracle Homes in an Oracle Real Application Clusters Environment