Re: from veritas: Best Practices for Multiple Oracle Instance

NetComrade wrote:

> I browsed upon the 'following recommendations' in Veritas docs, and
> wanted to see what you think, since I don't follow 50% of their
> recommendations. My comments start with --
>
> Pulled from VERITAS Cluster Server
> Enterprise Agent 4.0
> for Oracle
>
> Best Practices for Multiple Oracle Instance
> Configurations
> This appendix lists some Best Practices for VCS using multiple Oracle
> instances in a VCS
> environment.
> .For each SID to be configured, create Linux accounts with DBA
> privileges.
>
> ---i see on benefits, unless each db is maintained by separate DBAs.
>
> .Make sure that each Oracle instance has a separate disk group and is
> configured as a
> separate service group.
>
> ---ok, this localizes disk 'failures' to just one db. (however, in
> certain configurations, I've seen one disk failure affecting the whole
> array, or multiple arrays in the same FC "loop") it would be easier
> to failover 'one database group' to a different machine, however, i
> think you'll need a lot of 'spindles' for this to work. Not worth it,
> 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)
>
> .Define the system parameters such that the allocation of semaphore
> and shared
> memory is appropriate on all systems.
>
> .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.
>
> .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
>
> .If your configuration has different versions of Oracle, create a
> separate
> $ORACLE_HOME for each Oracle version.
>
>
> .Follow the Optimal Flexible Architecture (OFA) standard (/uxx/<SID>).
> In cluster
> configurations, you could adapt the standard to make it more
> application-specific. For
> example, /app/uxx/<SID>.
>
> .Listeners accompanying different versions of Oracle may not be
> backward-compatible. So, if you want to create a single listener.ora
> file, you
> must verify that the listener supports the other versions of Oracle in
> the cluster. You
> must also create a separate Envfile for each version of Oracle.
>
> .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.
>
> .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.
>
> .The pfiles must be co-ordinated between systems. For the same
> instance of a database,
> ensure that the pfiles referenced are identical across the nodes.
>
> --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.
> .......
> We use Oracle 8.1.7.4 on Solaris 2.7 boxes
> remove NSPAM to email

As 8.1.7.4 begins desupport in just 2.5 months I think best practice is to dump Solaris, dump Veritas, purchase some comodity hardware and then run 10g on RedHat Linux.

You asked. ;-)

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)