Re: 20 Instances 1 Machine

On Solaris (even 32-bit Solaris, i.e. 2.5.1 or 2.6) the shared memory limits are per process, not system-wide. We had 64 GB systems running 2.5.1 that could support instances using as much of that 64 GB as wanted for shared memory. With the 64-bit OS (Solaris 7, 8 or 9) the same is true.

A single 32-bit application can only map to 4 GB of address space of which you can dedicate about 3.9 GB for shared memory if you want. You may need to relink the Oracle binary to get above 2 GB (see the installation guide about genksms).

Dave Miller

>X-Unix-From: jmorrow_at_warthog.com Thu Aug 1 20:54:24 2002
>Date: Thu, 01 Aug 2002 18:23:21 -0800
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>X-Comment: Oracle RDBMS Community Forum
>X-Sender: "James J. Morrow" <jmorrow_at_warthog.com>
>From: "James J. Morrow" <jmorrow_at_warthog.com>
>Subject: Re: 20 Instances 1 Machine
>X-ListServer: v1.0g, build 71; ListGuru (c) 1996-2001 Bruce A. Bergman
>Mime-Version: 1.0
>Content-Transfer-Encoding: 7bit
>
>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
>
>"The reasonable man adapts himself to the world: the unreasonable man
> persists in trying to adapt the world to himself. Therefore all progress
> depends on the unreasonable man." -- George Bernard Shaw
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: James J. Morrow
> INET: jmorrow_at_warthog.com
>
>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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: David Miller
  INET: dm32840_at_bachelor.West.Sun.COM

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