Re: 20 Instances 1 Machine

You also have to consider the OS overhead. Putting 20 instances means hundreds of processes. Just managing all this at the system level can be resource consuming.

Yechiel Adar
Mehish
----- Original Message -----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Sent: Friday, August 02, 2002 5:43 AM

> I have not heard about such limitation for shared memory size on Solaris.
>
> Even if such limitation exists it will be on the process level.
>
> This means 2GB or 4GB for each database instance.
>
> Regards,
>
> Waleed
>
> -----Original Message-----
> To: Multiple recipients of list ORACLE-L
> Sent: 8/1/02 9:23 PM
>
> 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: Khedr, Waleed
> INET: Waleed.Khedr_at_FMR.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: Yechiel Adar
  INET: adar76_at_inter.net.il

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