[Update 2009-11] http://www.itpub.net/thread-1240926-1-1.html message #4: Extent is the same as granule. You can change the granule size and check extent size. They always match. E.g. --My current extent and granule size are both 4194304. Let me double it. alter system set "_ksmg_granule_size" = 8388608 scope = spfile; startup force oradebug dump heapdump 2 $ grep xsz ora11r2t1_ora_7822.trc parent=(nil) owner=(nil) nex=(nil) xsz=0x0 heap=(nil) parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil) parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil) parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil) parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil) 0x800000 is 8388608. I just read Tom Kyte's article. http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:4974546899844 he says the chunk size is 4k. On my Windows XP Oracle 9.2.0.1, I did a heap dump (oradebug dump heapdump 2) for a fairly new session. The trace file shows many 4248 byte chunks. (The concept of extent still exists. Each extent in the trace file is 4M size. I believe that's what the DSGA granule size is, which is 4M if SGA < 128M. That's the dynamic SGA (DSGA for short) allocation size.) The trace also shows many smaller (e.g. 32 or even 16 byte) and larger (like 3990200 byte) chunks. I guess those 4k chunks are still not atomic. I.e. if a SQL needs 3k, I believe 1k will be left free. One test may be keep dumping heaps while you load all kinds of SQLs and PL/SQLs. The test may also show that right before ORA-4031 whether two free chunks are coalesced (the addresses are in the second column). I don't know. On closer look, I realized most if not all those 4248 byte chunks have a ds (descriptor) but they don't have a latch. The lines with latch= are different sizes like 32, 312, 756, etc. I checked one latch. It happens to be child #1 library cache latch (v$latch_children.addr matches it).