Re: from veritas: Best Practices for Multiple Oracle Instance

We use those best practices quite well.

Veritas VCS is for clustering, so I sure hope your software is on the same box as the datafiles :-).
No to mention the backup directories.

Why so many users? I know it is a pain, it is for me too, but it works just fine with VCS and each
user has just the right .cshrc (or .kshrc etc.). We keep the listener.ora and other networking files synchonized between servers manually just like
the crontabs. We have a defined process and we follow it.

VCS is best used with SAN.

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1097721057.92956_at_yasure...
> 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)
>
Received on Sun Oct 17 2004 - 11:40:50 CDT