James J. MorrowŁ¬
>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).
>
hi, i believe that you are wrong on this topic. Yes, 32bit oracle has 1.7Gb sga limit, but it is one instance can have 1.7G sga, not all sga summary.Each instance can has its own 1.7GB sga.
And there is also solution for 32bit for large sga support, check the corresponding version and platform.
>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).
Good luck!
chaos
chaospku_at_163.net
zhu chao
DBA of Eachnet.com
86-021-32174588-667
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: chaos
INET: chaospku_at_163.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).
Received on Fri Aug 02 2002 - 01:33:20 CDT
