RE: 20 Instances 1 Machine

Thanks for the comments, all were good and James makes some good points (your right up the road from me by the way). I personally like the blade systems. I have only seen Egenera's Linux based system but I guess HP and others have some systems out. How does the cost on these systems look? Anyone seen anything they think is something worth looking at?

Ethan Post
perotdba (AIM), epost1 (Yahoo)

-----Original Message-----
Sent: Thursday, August 01, 2002 9:23 PM
To: Multiple recipients of list ORACLE-L

Your biggest problem is not going to be physical RAM or disk space (either of
those could simply be purchased large enough). However, you *will* encounter a
problem with "Shared Memory".

32-bit (and even 64-bit) operating systems have a finite amount of "shared memory" addressable for use by 32-bit applications (namely the RDBMS shipped

with the Oracle Applications). This number is 1.7GBytes on HP/UX and, I think,
2GBytes on Solaris. This "Shared Memory" limitation is systemwide. The Oracle
RDBMS uses shared memory heavily for major components of the SGA. As a result,
if you're running a 32-bit version of Oracle, this number represents the sum of
all SGA's running on that machine at the time. (So, at 500M/instance, you'll
run out somewhere between 3 and 4 instances).

Possible solutions would be:
1) Use a 64-bit version of the Oracle RDBMS as certified for your platform.

    A 64-bit version of Oracle would address shared memory from a much larger

    total pool (most likely an absurdly large number), thus avoiding this 32-bit

    "Shared Memory" problem.
2) Consider using something like Sun's "System Domains" to partition a big box

    into multiple "virtual machines". Each of these Domains would have it's own

    shared memory pool.
3) Consider using seperate machines.

Personally, I'd vote for seperate machines. I tend to prefer only one production system exist on any given host as it tends to eliminate much of the
performance-oriented fingerpointing that is bound to come up. Additionally,

running a large number of production instances on a single host can be alot like
putting all of your eggs into one basket. It may be cheaper, but if something
happens to that basket, everything's hosed.

As far as hardware:

        Lots of disk, plenty of I/O channels, and plenty of CPUs. Without actually
knowing the nature of your applications, I'd say you're probably looking in the
SunFire 6800 or SunFire 15k range (if you're looking at Sun equipment).

Post, Ethan wrote:
> I got a request to spec out a machine that could handle 20 separate Oracle
> instances on a single UNIX server. SGA should total about 500 MB per
> instance. We have some hosts here with 6-8 instances but never tried 20
> before. Wondering what types of things I should be worried about,
obviously
> having enough memory but are there any other limitations I can expect?
> Anyone had to do this?
>
> Thanks,
> Ethan

• James

  ---

  James J. Morrow E-Mail: jmorrow_at_warthog.com Senior Principal Consultant Tenure Systems, Inc. McKinney, TX, USA

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Post, Ethan
  INET: Ethan.Post_at_ps.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).