Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: SGA_MAX_SIZE on Solaris

Re: SGA_MAX_SIZE on Solaris

From: Tim Johnston <tjohnston_at_quallaby.com>
Date: Fri, 12 Mar 2004 10:11:24 -0500
Message-ID: <4051D31C.5030404@quallaby.com>


Someone just pointed out the following to me... When I performed this test on my system, the following message was in my alert log...

WARNING: -------------------------------
WARNING: oradism not set up correctly.
  Dynamic ISM can not be locked. Please
  setup oradism, or unset sga_max_size.
  [diagnostic 0, 16, 4074]

Oops... Guess I should have checked that...

:-)

I'll try and do some more investigation on this when I get a chance...

Tim

Tim Johnston wrote:

> Ah ha... Excellent info in the note... This bit explains the
> behavior I saw...
>
> Solaris limitation
>
> -------------------
>
> Keep in mind that on most Unix platforms, Oracle9i will allocate
> sufficient shared memory segment(s) to have a total sized at, or just
> above the size specified by SGA_MAX_SIZE when the instance is started.
> The default behavior on Solaris platforms is to lock this/these shared
> memory segment(s) into physical memory by forcing the use of ISM
> (Intimate Shared Memory). This is the default behavior of Oracle and
> is due to the operating system limitation in the shared memory
> management area. It is not recommended to disable this behavior as a
> serious performance penalty will be incured.
>
> In Solaris 8, thanks to DISM support (Dynamic Intimate Shared Memory),
> it is possible to avoid the above limitation and allocate the shared
> memory segmentsuch that only the active granules in the SGA are
> located in physical memory. All unused granules will be stored in
> swap until needed.
>
>
> Thanks Sten....
>
> Rognes, Sten wrote:
>
>> Be careful with using sga_max_size on Solaris (I am assuming that's your
>> platform). There is a Solaris bug which is claimed to can cause up to
>> a 90%
>> performance degradation, bug#4675878. This bug affects both Solaris 8
>> and
>> earlier releases of Solaris 9. Although there are a Solaris 8 patch
>> available or in the works for this, I would not recommend using this
>> feature
>> unless you are on Solaris 9 update 2(4/03) where large page support is
>> introduced for DISM segments and DISM and ISM performance is similar.
>> There are some notes on Metalink that will answer your questions below,
>> check out # 151222.1.
>>
>>
>> Sten
>>
>> -----Original Message-----
>> From: DENNIS WILLIAMS [mailto:DWILLIAMS_at_LIFETOUCH.COM] Sent:
>> Thursday, March 11, 2004 2:08 PM
>> To: 'oracle-l_at_freelists.org'
>> Subject: SGA_MAX_SIZE on Solaris
>>
>>
>> Has anyone experimented with SGA_MAX_SIZE? Does Oracle request that
>> amount
>> of memory on startup? If memory of the components like
>> SHARED_POOL_SIZE and
>> DB_CACHE_SIZE are smaller than SGA_MAX_SIZE, does Oracle only request
>> enough
>> memory for the components? If the size of one of the components is
>> reduced
>> dynamically, does Solaris eventually reclaim that space?
>> I have a test system with many Oracle9i instances. Most are little
>> used,
>> and I allocate only a small amount of memory. However, now and then a
>> development group will start pounding an instance. Often they run out of
>> memory. So I have to audit the memory settings of all instances, then
>> notify
>> developers on other instances that I need to bounce their instance to
>> retrieve some memory. A hassle for everyone concerned.
>> I'm wondering if I can set the SGA_MAX_SIZE high on all instances, but
>> then just allocate a small amount of memory. Then if an instance
>> needs more
>> memory, I could allocate it dynamically, and also dynamically reduce the
>> memory allocated in other instances.
>> Any thoughts appreciated.
>>
>> Dennis Williams
>> DBA
>> Lifetouch, Inc.
>> dwilliams_at_lifetouch.com
>> ----------------------------------------------------------------
>> Please see the official ORACLE-L FAQ: http://www.orafaq.com
>> ----------------------------------------------------------------
>> To unsubscribe send email to: oracle-l-request_at_freelists.org
>> put 'unsubscribe' in the subject line.
>> --
>> Archives are at http://www.freelists.org/archives/oracle-l/
>> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>> -----------------------------------------------------------------
>> ----------------------------------------------------------------
>> Please see the official ORACLE-L FAQ: http://www.orafaq.com
>> ----------------------------------------------------------------
>> To unsubscribe send email to: oracle-l-request_at_freelists.org
>> put 'unsubscribe' in the subject line.
>> --
>> Archives are at http://www.freelists.org/archives/oracle-l/
>> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>> -----------------------------------------------------------------
>>
>>
>

-- 
Regards,
Tim Johnston
Tel: 978-322-4226
Fax: 978-322-4100


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Fri Mar 12 2004 - 09:08:29 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US