RE: SGA_MAX_SIZE on Solaris
- From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 12 Mar 2004 10:01:26 -0600
Tim, Mike, Sten
Thanks for your help on this issue. I don't think I'll plunge into this
one just yet.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Tim Johnston
Sent: Friday, March 12, 2004 9:11 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: SGA_MAX_SIZE on Solaris
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@xxxxxxxxxxxxx] Sent:
>> Thursday, March 11, 2004 2:08 PM
>> To: 'oracle-l@xxxxxxxxxxxxx'
>> 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@xxxxxxxxxxxxx
>> ----------------------------------------------------------------
>> Please see the official ORACLE-L FAQ: http://www.orafaq.com
>> ----------------------------------------------------------------
>> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
>> put 'unsubscribe' in the subject line.
>> --
>> Archives are at //www.freelists.org/archives/oracle-l/
>> FAQ is at //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@xxxxxxxxxxxxx
>> put 'unsubscribe' in the subject line.
>> --
>> Archives are at //www.freelists.org/archives/oracle-l/
>> FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
