Re: Multiple VMs using the same Oracle binaries
Date: Tue, 17 Jan 2012 11:09:22 +1000
Message-ID: <4F14CA42.3090204_at_tpg.com.au>
One small problem that may arise with an arrangement like this is the files in $ORACLE_HOME/dbs. You must make doubly sure that no instance that shares the remote home has a duplicate name, lest it overwrites some other instance's memory map files or inadvertently reuse password and spfiles.
There are also quite a few locations in the home where logfiles are written, e.g. by the configuration tools. How do you prevent these to become a jumble of different sources? (for a list of obvious locations `sudo find $ORACLE_HOME -type d -name log -print`)
Cheers,
Tony
On 17/01/12 08:36, David Mann wrote:
>> Has anyone done the shared binaries between
>> servers before? What are your thoughts?
> We do this where I currently work. All data files and binaries are on
> NAS/SAN devices and are separate from the db machines.
>
> I thought these folks were crazy but I now 'get' why it is this way.
> We have an OHOMEPROD mount that attaches to /u01/app/oracle and we
> connect that to all our servers so that set of files is available
> everywhere. We also have an OHOMEDEV mount that services dev/test.
>
> Pros:
<snip against overquoting>
> 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 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.
>
> This is what I can remember off the top of my head. If anyone has any
> resources to share on the topic would love to check them out.
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 16 2012 - 19:09:22 CST