from veritas: Best Practices for Multiple Oracle Instance

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 Received on Mon Oct 11 2004 - 14:47:52 CDT