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 <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
