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

Reply via email to