"No expert"? Hardly! Tanel, just how the heck do you KNOW all this stuff?
--- Tanel Poder <[EMAIL PROTECTED]> wrote: > Hi! > > As I understand, when shared pool heap is allocated, half of it's > memory is > actually "hidden" at first. Oracle just allocates one big permanent > type > chunk for that. > The rest of memory is put on shared pool freelist. Initially this is > just > one big free chunk as well, but starts shrinking as space requests > are done > from it. One space request might result in multiple allocated chunks, > if > there's not enough free space in one memory extent for example. > > When a new chunk is allocated, the allocator will specify size and > type of > chunk it wants: > - permanent type is permanent, unpinnable and unfreeable chunk. > Permanent > chunks exist until the whole heap is deallocated. > - freeable type chunks can explicitly be freed by allocator (there's > also > special type of freeable chunks, called freeable with a mark, which > can be > freed implicitly, depending on memory usage in heap) > - recreatable type chunks are pinned ("in use") right after > allocation and > they can't be freed until they are explicitly unpinned. > > So, when allocating a recreatable type chunk, first freelists are > searched > for suitably sized free chunks. A heap freelist actually consists of > 255 > different lists, one for each size range of free chunks (smallest > size range > starts from 16 bytes, largest is about 64k+). This allows the > freelist to be > scanned faster. When no exactly matching free chunk is found, the > next > largest will be taken and is split. The leftover free chunk is placed > to > appropriate range in freelist. Memory allocations & deallocations in > shared > pool are protected by shared pool latch (by shared pool child latch > starting > from 9i - you can separate shared pool to several heaps for better > concurrency in 9i). AFAIK, Oracle is also able to coalesce adjacent > free > chunks when they're freed. > > When a recreatable chunk is allocated, it is marked as "pinned" - > meaning > currently in use. Thus noone can free it until it is explicitly > unpinned by > it's allocator (for example, several chunks might be pinned in shared > pool > during SQL parse and execution, but get unpinned right after the > statement > has finished). Here comes the LRU list into play. When a recreatable > chunk > is unpinned first time, it is put into MRU end of *transient* LRU > list, > since Oracle doesn't know whether it's needed ever again. When it is > pinned > next time, then of course it's taken off from LRU list at first, but > the > chunk itself is marked recurrent and is put in *recurrent* LRU list > when > unpinned again. > (Note that I'm not sure how this LRU list internal structure looks > like, > whether there are really two LRU lists for each heap or is there a > single > one with two ends). > > Now, when a new space request is done, first freelists are scanned, > but if > there is no sufficient space there, transient LRU list is scanned and > if big > enough unpinned recreatable chunk is found, it is freed and returned > to free > list. > Ok, but what happens if no suitable chunk is found from neither > freelists > nor LRU list? Oracle will then release "hidden" free space, which is > allocated as permanent chunk during startup and is not in any > freelists. The > reason behind that might be that it is good to have less available > memory > during database startup, dictionary cache population and various > applications initialization operations - that way more transient > recreatable > chunks can be reused and LRU lists don't get that long and there's > less > fragmentation in shared pool before "real work" starts. Long LRU and > freelists are one reason for shared pool latch contention, that's why > one > should consider reducing of shared pool in case of this latch problem > instead of usual "more memory is better" approach (as mentioned > above, in 9i > it's possible to split shared pool into several heaps to improve > concurrency). > > And if even hidden memory is used up, then we get ORA-4031. > > Ok, this was a tiny part of heap management in Oracle, there is > actually > much more, such reserved list for shared pool reserved area and what > happens > free chunk split leftovers which are smaller than 16 bytes etc. Since > I'm > not expert on SGA, please correct if I'm wrong. > > Tanel. > > ----- Original Message ----- > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Friday, September 26, 2003 3:17 PM > > > > ...long long way to go ..... b4 i reach x$ tables. > > > > Tanel, can u brief me about transient chunks & recurrent chunks > > that u were discussing with Steve ? > > > > Jp. > > > > > > 26-09-2003 19:54:48, "Tanel Poder" <[EMAIL PROTECTED]> wrote: > > > > >I'd suggest, when possible, not to use any x$ views, but stich > with plain > > >old documented ways. That way you'll probably avoid a lot of > confusion, > > >especially when database versions might change.. > > > > > >Tanel. > > > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Prem Khanna J > > INET: [EMAIL PROTECTED] > > > > 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: [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.net > -- > Author: Tanel Poder > INET: [EMAIL PROTECTED] > > 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: [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). __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Paul Baumgartel INET: [EMAIL PROTECTED] 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: [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).