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

NetComrade wrote:

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@x.washington.edu
(replace 'x' with 'u' to respond)

netcomradeNSPAM (AT) bookexchange (DOT) net (NetComrade) wrote in message news:<416ae033.8706298@localhost>...



me neither. for the same reasons.


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


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


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.


Prefer not to use pfiles if at all possible.


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


or else nothing will pretty much work...

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...


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

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...

Noons wrote:
[large snip]

Hehehe, you mean using 10g will be a reason for upgrading 'cause
10gR2 will be out by then and a desupport date for R1 will exist
that preceeds that of 9iR2?

;-)

Holger

On 14 Oct 2004 05:33:46 -0700, wizofoz2k (AT) yahoo (DOT) com.au (Noons) wrote:

Yeah, but that's if you got tons of spindles to spare.. spreading 14
(post-mirror) spindles across 4-5 databases is kind of hard.


When I have only one copy, and start from only one place, I am happy
with them.



9ir2 has been right around the corner for us for about a year now
I want the extra features.

Thanks!
........
We use Oracle 8.1.7.4 on Solaris 2.7 boxes
remove NSPAM to email

On Wed, 13 Oct 2004 19:29:30 -0700, Daniel Morgan
<damorgan@x.washington.edu> wrote:

I haven't researched this at all, but how does 10g spread IO if you
run multiple databases on the same server? Does each db have to own a
'raw' slice?

If that's the case, VxVM is still the way.

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

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@x.washington.edu> wrote