Re: from veritas: Best Practices for Multiple Oracle Instance

netcomradeNSPAM_at_bookexchange.net (NetComrade) wrote in message news:<416ae033.8706298_at_localhost>...

> .For each SID to be configured, create Linux accounts with DBA
> privileges.
>
> ---i see on benefits, unless each db is maintained by separate DBAs.

me neither. for the same reasons.

> I'd rather SAME, and move DB via standby, or maintenance window, if I
> need to move to a different server (which shouldn't happen, if
> carefully planned)

*if*. It never is. Use different groups and SAME within each group. Can be done with disk farms.

> .Define the system parameters such that the allocation of semaphore
> and shared
> memory is appropriate on all systems.

or else it won't start. Jeez, that one is *basic*...

> .Use a dedicated set of binaries for each Oracle instance, even if
> each instance uses the
> same Oracle version.
>
> --Why? So that i'd spend 1hr per instance instead of 1hr per server on
> patch upgrades? Patch testing should be done in test environemnt?
> Probably could apply for folks running 3rd party 'software', that
> requires certain versions of Oracle.

Overkill, IMHO. I can understand two sets of binaries, one for develop/test, another for prod. So that you can install/test new patches/versions without getting your knickers in a twist over production. But one for each instance? Only if you are running radically different and incompatible apps in each, which would force you to upgrade/patch to different levels. Other than that, sheer overkill.

>
> .If your configuration uses the same Oracle version for all instances,
> install a version
> on the root disk or preferably on a secondary disk. Locate the pfiles
> in the default
> location and define several listener processes to ensure clean
> failover.
>
> ---prefer keeping all oracle stuff on disk group

Prefer not to use pfiles if at all possible.

> .If your configuration has different versions of Oracle, create a
> separate
> $ORACLE_HOME for each Oracle version.

How could it be done otherwise? Without breaking OFA and the default install, I mean.

> .Make sure that each listener listens to a different virtual address.
> Also, assign different
> names to listeners and make sure that they do not listen to the same
> port.

or else nothing will pretty much work...

> .If you create a single user named oracle and define the variables
> required by Oracle,
> you must redefine at minimum the $ORACLE_HOME and $ORACLE_SID
> variables
> every time you want to invoke svrmgrl.

and why so many do not use *oraenv* still baffles me. Get rid of the last *if/fi* inside it, then just use the darn thing: works perfectly and one can always export ORAENV_ASK=NO if the silly message is objectionable. Of course it better have a /etc/oratab setup the right way. But that is not much to ask.

I keep finding sites with elaborate script arrangements to do precisely what oraenv does and very little more. Invariably the reason given is "Oracle's scripts are badly written"! What a waste of resources...

> --That's why you keep the binaries in the same disk group as the data
> files, so you don't have maintanability nightmares like this. Or use
> spfiles.

Or just put the binaries in one single shared f/s?

> We use Oracle 8.1.7.4 on Solaris 2.7 boxes
> remove NSPAM to email

Dude, time to start thinking about upgrades. 9ir2(patch 4) is solid and worth every minute of it. And a long way from being dropped. Another year or so and 10g will also be the same... Received on Thu Oct 14 2004 - 07:33:46 CDT