I blogged earlier about heap dump shared pool heap duration and was curious to see how the inmemory – 188.8.131.52 new feature – is implemented. This is a short blog entry to discuss the inmemory area heap.
I have set the initialization parameters sga_target=32G and inmemory_size=16G, meaning, out of 32GB SGA, 16GB will be allocated to inmemory area and the remaining 16GB will be allocated to the traditional areas such as buffer_cache, shared_pool etc. I was expecting v$sgastat view to show the memory allocated for inmemory area, unfortunately, there are no rows marked for inmemory area (Command “show sga” shows the inmemory area though). However, dumping heapdump at level 2 shows that the inmemory area is defined as a sub-heap of the top level SGA heap. Following are the commands to take an heap dump.
oradebug setmypid oradebug heapdump 2 -- this command creates an heap dump trace file. oradebug tracefile_name
Reviewing trace file
Trace file shows that the inmemory area is implemented as two sub-heaps namely IMCA_RO and IMCA_RW. Split is not equal between these two sub-heaps and I am not exactly sure about the algorithm for this split, about 12.75GB is allocated for IMCA_RO and the remaining 3.25GB is allocated for IMCA_RW area [ That’s about 80-20:) split ].
$ grep "heap name" *ora_56235*.trc HEAP DUMP heap name="sga heap" desc=0x600013d0 HEAP DUMP heap name="sga heap(1,0)" desc=0x60063740 HEAP DUMP heap name="sga heap(1,3)" desc=0x60068048 HEAP DUMP heap name="sga heap(2,0)" desc=0x6006d490 HEAP DUMP heap name="sga heap(2,3)" desc=0x60071d98 HEAP DUMP heap name="sga heap(3,0)" desc=0x600771e0 ... HEAP DUMP heap name="sga heap(7,0)" desc=0x6009e720 HEAP DUMP heap name="sga heap(7,3)" desc=0x600a3028 HEAP DUMP heap name="IMCA_RO" desc=0x60001130 <--- In memory Read only area? HEAP DUMP heap name="IMCA_RW" desc=0x60001278 <--- In memory Read write area?
You can learn all about SGA heap duration here , only last two lines are interesting to this blog entry and shows that two sub-heaps were allocated for Inmemory area.
The inmemory sub-heaps are split in to memory extents, similar to traditional SGA heap allocations. Each extent has numerous 64MB chunks allocated to it. These chunks are tagged as “cimadrv”. Total heap size is about 12.5GB.
HEAP DUMP heap name="IMCA_RO" desc=0x60001130 extent sz=0x1040 alt=288 het=32767 rec=0 flg=2 opc=2 parent=(nil) owner=(nil) nex=(nil) xsz=0x30600000 heap=(nil) fl2=0x20, nex=(nil), dsxvers=1, dsxflg=0x0 dsx first ext=0x64000000 dsx empty ext bytes=0 subheap rc link=0x64000070,0x64000070 pdb id=0 EXTENT 0 addr=0x363a00000 Chunk 363a00010 sz= 8388304 free " " Chunk 3641ffee0 sz= 65011736 freeable "cimadrv " Chunk 367fffef8 sz= 67108888 freeable "cimadrv " <-- 64MB chunks Chunk 36bffff10 sz= 67108888 freeable "cimadrv " Chunk 36fffff28 sz= 67108888 freeable "cimadrv " Chunk 373ffff40 sz= 67108888 freeable "cimadrv " ... EXTENT 1 addr=0x2e3b00000 Chunk 2e3b00010 sz= 66059528 freeable "cimadrv " Chunk 2e79ffd18 sz= 67108888 freeable "cimadrv " Chunk 2eb9ffd30 sz= 67108888 freeable "cimadrv " … Total heap size =13690208144 <-- Total heap size.
Next heap IMCA_RW is more interesting. This sub-heap also has extents with 64MB of chunks allocated it, however, I see that there are also smaller chunks in the heap. (I am still researching meaning of these chunks and trying to avoid guess work at this time.)
EAP DUMP heap name="IMCA_RW" desc=0x60001278 extent sz=0x1040 alt=304 het=32767 rec=0 flg=2 opc=2 parent=(nil) owner=(nil) nex=(nil) xsz=0x50100000 heap=(nil) fl2=0x20, nex=(nil), dsxvers=1, dsxflg=0x0 dsx first ext=0x790000030 dsx empty ext bytes=0 subheap rc link=0x7900000a0,0x7900000a0 pdb id=0 EXTENT 0 addr=0x80ff00000 Chunk 80ff00010 sz= 17825296 free " " Chunk 810fffe20 sz= 50331672 freeable "cimadrv " Chunk 813fffe38 sz= 67108888 freeable "cimadrv " Chunk 817fffe50 sz= 67108888 freeable "cimadrv " … Chunk 80f8d5ef8 sz= 8296 freeable "cimcadrv-sb " <-- smaller chunks. Most are about 8k or 16k. Chunk 80f8d7f60 sz= 48 freeable "cimcadrv-sbrcv " Chunk 80f8d7f90 sz= 184 freeable "cimcadrv-sblatc" Chunk 80f8d8048 sz= 8296 freeable "cimcadrv-sb " Chunk 80f8da0b0 sz= 48 freeable "cimcadrv-sbrcv " Chunk 80f8da0e0 sz= 184 freeable "cimcadrv-sblatc" … Total heap size =3489660848
So, if this is similar to shared pool heap, is it possible to get an out-of-space error such as ORA-4031 for the shared pool heap?. There is such an error associated with inmemory option🙂.
oerr ora 64356 64356, 00000, "in-memory area out of space" // *Document: NO // *Cause: The in-memory area had no free space. // *Action: Drop the in-memory segments to make space.
In summary, I was expecting inmemory area to be allocated as integral part of buffer_cache buffers, however, that is not the case. Inmemory area size is allocated as sub-heaps very similar to the shared pool sub-heaps (but, NOT part of shared pool heaps though). As the software was released just recently, I need to research further to understand the intricate details.