Yeah I know, did it again. On Tue, 2004-01-06 at 10:19, Mladen Gogala wrote: > The name is Breitling. Wolfgang Breitling. Not to be confused with Bond. James Bond. > On 2004.01.06 12:34, Jared Still wrote: > > * to satisfy curiosity > > * to have a better understanding of how Oracle works > > > > Most DBA's probably don't need to know this stuff. Most > > performance problems will not likely require you to know > > any of this. > > > > If you spend a lot of time solving other people's 'unsolvable' > > Oracle performance problems, as Steve Adams, Jonathan Lewis, > > Cary, Millsap, Gary Goodman, Wolgang Breitling ( Hope I spelled his name > > correctly this time), or many other consultant types on this list > > then this kind of thing will be very useful to you. > > > > Ditto if you have a large number of instances to deal with, and > > run into tricky tuning problems. > > > > Jared > > > > > > On Tue, 2004-01-06 at 08:24, Guerra, Abraham J wrote: > > > Hi all, > > > > > > Why would anybody care about all these heap stuff? How does it help > > > performance.... > > > > > > Thanks. > > > > > > Abraham Guerra > > > -----Original Message----- > > > Sent: Tuesday, January 06, 2004 10:04 AM > > > To: Multiple recipients of list ORACLE-L > > > > > > > > > Well, a heap is just a bunch of memory (allocated in contiguous extents) > > > and you can practically allocate any size of chunk of memory from it > > > (with some restrictions). A regular heap has freelist and LRU list > > > mechanisms for managing space in it as well as memory > > > allocation/releasing routines which you can then call. Oracle uses its > > > generic heap manager code (KGH) for managing it's memory. > > > > > > Once you allocate a chunk from heap it's up to the allocator what he > > > does with it. It can just use it for some kind of static data, but can > > > also create another heap in these chunks it allocated, this heap may use > > > different heap manager code for managing its memory if needed (for > > > example shared pool reserved area and large pool behave a little > > > differently, they don't have LRU list mechanisms). > > > > > > If you take any heapdump using alter session set events 'immediate trace > > > name heapdump level x' ; then top level heaps show parent=00000000 in > > > their descriptors. Note that this "top call heap" has allocated chunks > > > for heap with descriptor address 06B51DB0 (callheap) and also you see > > > that "callheap" has a parent heap with descriptor address 06B52790. > > > > > > HEAP DUMP heap name="top call heap" desc=06B52790 > > > extent sz=0x213c alt=92 het=32767 rec=0 flg=2 opc=2 > > > parent=00000000 owner=00000000 nex=00000000 xsz=0xfffc > > > EXTENT 0 addr=071D0004 > > > Chunk 71d000c sz= 112 perm "perm " alo=112 > > > Chunk 71d007c sz= 65412 free " " > > > EXTENT 1 addr=07170004 > > > Chunk 717000c sz= 232 perm "perm " alo=232 > > > Chunk 71700f4 sz= 60724 free " " > > > Chunk 717ee28 sz= 1352 freeable "callheap " > > > ds=06B51DB0 > > > Chunk 717f370 sz= 1072 freeable "callheap " > > > ds=06B51DB0 > > > Chunk 717f7a0 sz= 1072 recreate "callheap " > > > latch=00000000 > > > ds 6b51db0 sz= 3496 ct= 3 > > > > > > [snipped....] > > > > > > HEAP DUMP heap name="callheap" desc=06B51DB0 > > > extent sz=0x424 alt=32767 het=32767 rec=0 flg=2 opc=3 > > > parent=06B52790 owner=00000000 nex=00000000 xsz=0x53c > > > EXTENT 0 addr=0717EE34 > > > Chunk 717ee3c sz= 1332 freeable "qkkele " > > > EXTENT 1 addr=0717F37C > > > Chunk 717f384 sz= 572 perm "perm " alo=388 > > > Chunk 717f5c0 sz= 444 free " " > > > Chunk 717f77c sz= 36 freeable "qkkkey " > > > EXTENT 2 addr=0717F7BC > > > Chunk 717f7c4 sz= 28 perm "perm " alo=28 > > > Chunk 717f7e0 sz= 956 free " " > > > Chunk 717fb9c sz= 52 freeable "event string " > > > Total heap size = 3420 > > > FREE LISTS: > > > Bucket 0 size=76 > > > Bucket 1 size=268 > > > Chunk 717f7e0 sz= 956 free " " > > > Chunk 717f5c0 sz= 444 free " " > > > Bucket 2 size=1036 > > > Total free space = 1400 > > > UNPINNED RECREATABLE CHUNKS (lru first): > > > PERMANENT CHUNKS: > > > Chunk 717f384 sz= 572 perm "perm " alo=388 > > > Chunk 717f7c4 sz= 28 perm "perm " alo=28 > > > Permanent space = 600 > > > ****************************************************** > > > > > > If making these "full" heapdumps puts too much strain on your system, > > > then it might be easier to use event HEAPDUMP_ADDR which allows to dump > > > heaps only with specified descriptor address. There are other options as > > > well, such is X$KSMHP table to query any heap (which is, blah, highly > > > unsupported) or attaching directly to SGA shared memory segment and > > > reading from there. > > > > > > Sorry for too long post, I'm currently too lazy to do anything useful... > > > Tanel. > > > > > > ----- Original Message ----- > > > To: Multiple recipients of list ORACLE-L > > > Sent: Tuesday, January 06, 2004 3:49 PM > > > > > > > > > Hi, > > > I am getting little confussion how the memory is allocated for > > > top-level heaps and subheaps in shared pool. > > > > > > How can we know what are all the top-level heaps and subheaps and their > > > hierarchy. > > > Is it possible to get it from any X$ tables. > > > > > > Freeable chunks can be flushed out?If yes ,then why there should be > > > another type as recreatable chunks? > > > Please explain. > > > > > > Thanks in advance > > > Syed > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jared Still > > 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). > > > > -- > Mladen Gogala > Oracle DBA > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mladen Gogala > 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: Jared Still 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).
