* 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).

Reply via email to