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: jkstill_at_cybcon.com
> >
> > 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).
> >
>
> --
> Mladen Gogala
> Oracle DBA
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mladen Gogala
> INET: mgogala_at_adelphia.net
>
> 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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jared Still
INET: jkstill_at_cybcon.com
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).
Received on Tue Jan 06 2004 - 14:04:26 CST
