Doesn't it rather depend on what you call a machine?
A Sun E450 my only run one or two instances of Oracle, but an E10000 could
run quite a few more.
George Barbour.
"Alan" <alainrtv_at_yahoo.com> wrote in message
news:fbee32ac.0206171913.70c92708_at_posting.google.com...
> Suppose I want to install 30 instances on one host?
> I decided to write up some thoughts.
>
> If any of you have some thoughts...
> Please share.
>
>
>
> Many Oracle Instances On One Host
>
> This page discusses some trade-offs related to running many Oracle
> instances on one host. The format is based on a typical user asking
> some questions and some possible answers he/she would hear from
> a team of experienced DBAs.
>
> Q: Why would I want to run 20 or 30 instances on a single host?
> A: It depends. Licensing is an issue. Some licenses allow you an
> unlimited number of instances on a single host. Data separation would
> likely be another compelling reason. The need for Data separation
> comes in many varieties. For example, many shops need separate
> environments for Development, Testing, and Production. An ASP might
> separate instances as an easy method to separate its customer's data.
> Some Data separation reasons hold less water with enhanced Virtual
> Private Database functionality in Oracle9i.
>
> Q: If I run 20 or 30 instances on a single host, what are some
> best practices I should follow?
>
> A: It would be a good idea to implement most parts of Oracle Flexible
> Architecture. A link to the OFA specification is listed below:
>
>
http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/A97297_01/
html/appg_ofa.htm#i633068
>
>
> Some of the ideas presented in the above specification make poor sense
> and should be avoided. An experienced DBA will have the common sense
> to avoid them or see through some of the faulty logic behind them.
>
> For example, OFA asks the DBA to place software on a mount point
> separate from the data mount points. The faulty logic behind this is
> that it will separate I/O and thus boost performance. The truth is
> that the software mount point will generate relatively little I/O; the
> software mount point would be quiet and the data mount points would be
> busy. So, a DBA following this advice would not optimize the I/O
> potential of the host.
>
> The OFA advice on mount points also holds little water when viewed
> from the perspective that on most decent sized UNIX boxes, I/O
> spreading is now done inside the storage array. The days of having a
> mount point logically connected to a disk partition's address are
> gone. OFA was written for systems built before the proliferation of
> disk volume management software like Veritas.
>
> Q: Okay, so some parts of OFA are "clunky"; what parts are good for
> helping
> me manage the 30 instances I have on my v880?
>
>
> A: The good parts of OFA are the sections which describe naming
> conventions and location conventions. For example, OFA will tell the
> DBA to create a directory which corresponds to the variable
> ORACLE_BASE.
> OFA dictates we have these directories under ORACLE_BASE:
>
> $ORACLE_BASE/admin
> $ORACLE_BASE/doc
> $ORACLE_BASE/local
> $ORACLE_BASE/product
>
> Any DBA (moderately familiar with OFA) off the street will know what
> kind of files reside in the above directories. All the software files
> and the configuration files for the 30 instances will reside in a
> logical place in the above directories. For example, the init.ora for
> instance, "X21", will be here:
>
>
> $ORACLE_BASE/admin/X21/pfile/initX21.ora
>
> One bad naming convention in OFA is this:
>
>
>
> If you install an OFA-compliant Oracle Server, the Oracle home
> directory is
> $ORACLE_BASE/product/release_number.
>
>
> The above convention restricts the DBA from running 2 instances (or
> 30!)
> of the same release on one host.
>
>
> A better naming convention is this:
>
> The Oracle home directory is:
> $ORACLE_BASE/product/$ORACLE_SID which is either a directory or a soft
> link.
> If it is a soft link it should be pointing to this:
> $ORACLE_BASE/product/release_number
>
>
> The second convention offers the DBA an architecture more flexible
> than OFA with no significant loss of useful structure. Also it
> eases some burdensome tasks associated with upgrades. For example, if
> we upgrade and are constrained by OFA, we will be forced to change the
> value of every file which makes reference to $ORACLE_HOME. The second
> convention frees us from this editing chore.
>
> Q: If I run 30 instances on one host, how should I handle UNIX
> ownership
> of the processes and the Oracle software?
>
> A: I see 3 possible answers to this question:
>
> Option a: All 30 instances owned by one account (oracle probably)
> Option b: Divide the intances into classes and assign a uid to each
> class
> Option c: Each instance assigned its own uid
>
>
> Option "a" would be easiest on the DBA. It would, however, put each
> instance at greater risk of getting its data corrupted by other
> instances (due to a wide variety of DBA error scenarios).
>
>
> Option "c" would impose some burdens on the DBA. It would force UNIX,
> however, to place a safety net of sorts around all the databases. If
> instance A tried to write over files owned by instance B, UNIX would
> prevent it. This option would lessen the ability of DBA to allow the
> instances to share software. Certain parts of Oracle software are
> sensitive to who owns them. For example, $ORACLE_HOME/bin/oracle
> needs
> to be suid to the owner of the instance.
>
> Option "b" represents the middle ground between Option "a" and Option
> "c" though in practice I suspect it would be closer to Option "c" than
> Option "a".
>
>
> Q: Suppose a DBA has 30 instances on one host; what is the best way
> for a DBA to manage the 30 sets of env variables for the instances?
>
>
> Q: Suppose a DBA has 30 instances on one host; what is the best way
> for a DBA to manage shutdown/startup of one instance, several
> instances, all the instances?
>
>
> Q: Suppose a DBA has 30 instances on one host; what is the best way
> for a DBA to track what is connected to what?
>
> Q: Suppose a DBA wants to install 30 instances on a host from scratch;
> what is the best way to handle that task?
>
>
> Q: Suppose a DBA has 30 instances on one host; what is the best way
> to back everything up?
>
>
> Q: Suppose a DBA has 30 instances on one host; should he use raw
> devices or ufs?
>
> Q: Suppose a DBA has 30 instances on one host; what tools are helpful
> for
> managing a large number of instances?
>
> Q: Suppose a DBA has 30 instances on one host; does Solaris or Oracle
> have any
> features which allow him to assign priorities to different instances
> when
> contention occurs for CPU, RAM, or I/O?
Received on Tue Jun 18 2002 - 09:27:26 CDT
