Shared Oracle Homes

Pros:
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 root.sh 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.

Cons:
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 root.sh 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.

References
Oracle Home : To Share or Not To Share

Oracle Homes in an Oracle Real Application Clusters Environment