Re: x$ constructs and memory

> What I have not checked so far is how an ALTER SYSTEM increasing a
parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ...

Hi!

I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance.

Tanel.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).