Re: Multiple VMs using the same Oracle binaries
- From: De DBA <dedba@xxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 17 Jan 2012 11:09:22 +1000
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.
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
