shared pool的物理结构和逻辑结构
从物理角度上看Oracle shared pool，它是由多个内存块组成。这里的内存块相当于数据文件中的数据块，是最小的分配单位。这个最小分配单位称为chunk，它里面的内存字节是连续的。但每个chunk的大小是不固定的。shared pool的内存分配由heap（堆）来实现。heap的个数由隐含参数”_kghdsidx_count “来决定。
每个heap下又有多个sub-heap，他们之间的关系称为高级堆和副堆。他们的结构大致相同。
heap由一个或多个extent和heap header组成，而extent又由若干个chunk和extent header组成，而chunk由chunk header和chunk body组成。
每个extent的体积是若干个granule（有文档说是一个，但dump出来看不只一个）。granule是shared pool逻辑角度上的组成单位。这个granule是固定值，不同的SGA下大小不同，如10g中SGA_MAX_SIZE<=1024MB，则granule 的值为4MB ；SGA_MAX_SIZE>1024MB ，则granule 的值为16MB。可以通过v$sgainfo去查证。
从视图select ksmchcls,count(*) from x$ksmsp group by ksmchcls;中可以看到shared pool的每个chunk的类型。
KSMCHCLS
COUNT(*)
free
3299
freeabl
13634
no acce
17
perm
43
R-free
31
R-freea
76
recr
18519
free：这种类型的chunk不包含有效的对象，可以不受限制地被分配。
recr：意味着recreatable，这种类型的chunk里包含的对象可以在需要的时候被临时移走，并且在需要的时候重新创建。比如对于很多有关共享SQL语句的chunk就是recreatable的。
freeabl：这种类型的chunk包含的对象都是曾经被session使用过的，并且随后会被完全或部分释放。这种类型的chunk不能临时从内存移走，因为它们是在处理过程中间产生的，如果移走的话就无法被重建。
perm：意味着permanent，这种类型的chunk包含永久的对象，大型的permanent类型的chunk也可能含有可用空间，这部分可用空间可以在需要的时候释放回shared pool里。
(miki西游 @mikixiyou 原文链接: http://mikixiyou.iteye.com/blog/1667933)
使用”heapdump at level 2”将shared pool空间dump出来，可以看到heap的组成。
使用的SQL如下：
alter session set events 'immediate trace name heapdump level 2';
dump出来的结果如下：
******************************************************HEAP DUMP heap name="sga heap" desc=0x2000002c extent sz=0x32c8 alt=108 het=32767 rec=9 flg=-126 opc=0 parent=(nil) owner=(nil) nex=(nil) xsz=0x0******************************************************HEAP DUMP heap name="sga heap(1,1)" desc=0x2001b598 extent sz=0xfc4 alt=108 het=32767 rec=9 flg=-126 opc=0 parent=(nil) owner=(nil) nex=(nil) xsz=0x1000000EXTENT 0 addr=0x9d000000 Chunk 9d000038 sz= 24 R-freeable "reserved stoppe" Chunk 9d000050 sz= 839576 R-free " "Chunk 9d0ccfe8 sz= 24 R-freeable "reserved stoppe" Chunk 9d0cd000 sz= 10274952 free " " Chunk 9da99888 sz= 796 recreate "KGL handles " latch=(nil) Chunk 9da99ba4 sz= 1036 freeable "parameter table" Chunk 9da99fb0 sz= 96 freeable "library cache " Chunk 9da9a010 sz= 228 recreate "KGL handles " latch=(nil) Chunk 9da9a0f4 sz= 96 freeable "library cache " Chunk 9da9a154 sz= 284 recreate "KQR PO " latch=0x9baaf310 Chunk 9da9a270 sz= 284 recreate "KQR PO " latch=0x9baaf310 Chunk 9da9a38c sz= 540 recreate "KQR PO " latch=0x9baaf568 Chunk 9da9a5a8 sz= 96 freeable "library cache " Chunk 9da9a608 sz= 540 recreate "KGL handles " latch=(nil) Chunk 9da9a824 sz= 540 recreate "KGL handles " latch=(nil) Chunk 9da9aa40 sz= 540 recreate "KGL handles " latch=(nil) Chunk 9da9ac5c sz= 540 recreate "KGL handles " latch=(nil) Chunk 9da9ae78 sz= 540 recreate "KGL handles " latch=(nil)
在chunk的 header中，有一个16字节的固定区域，保存分配该heap内存的原因或者说是注释，如”KGL handles”、”KQR PO”等等。
Oracle shared pool中这些物理内存的分配、管理都是由一个叫做KGH Heap Manager的C程序来实现的。Heap Manager预先分配所有的shared pool所定义的内存空间。Heap Manager还管理PGA内存，但这个操作需要经常同操作系统交互来分配和回收内存。
从逻辑角度看Oracle shared pool，它主要分为library cache、dictionary cache和control structure三个部分。
Shared pool的library cache主要保存了已执行的SQL语句和PL/SQL对象，以及它们的执行计划等等。
采用hash table对这些对象进行管理。例如一个SQL在经过hash算法分析后得到一个hash值。hash table下由若干个hash bucket，hash bucket下又有若干个library cache handle组成。这些handle的组成部分包括name,namespace,lock owners,lock waiters,pin owners,pin waiters,flags,heap 0(object)。其中heap 0保存的是指向object的指针。因此这个heap 0也称为object。如下图所示：
http://dl.iteye.com/upload/picture/pic/117407/409cfee7-5b16-392b-9bc3-13ff0d2ac771.gif
根据library cache的结构，延伸到heap 0这个级别上。heap 0的组成部分包括object type,object name,flags,tables,data blocks。其中tables和data blocks又进一步延伸。
tables的组成部分包括dependency table，child table，translation table，authorization table，access table，r-o dependency table，schema name table。
data blocks的组成部分包括object, source,diana,pcode,mcode,errors,sql context。其中source也称为heap 1用于存储sql文本,sql context称为heap 6用于存储SQL执行计划。如下图所示：
http://dl.iteye.com/upload/picture/pic/117411/cd711ea8-cd44-35af-a7ab-ba12eac57e1e.gif
library cache中不同bucket的library cache object handle是有不同类型的。可以根据object handle中的namespace进行区别。不同object handle之间可能采用双向链表的形式相互关联。
如namespace为CRSR的，有parent cursor和child cursor，分别在不同的bucket中的object handle里。
使用”library_cache level 11“将library cache的内存dump出来。
使用的SQL如下：
alter session set events 'immediate trace name library_cache level 11';
dump出来的结果如下：
BUCKET 5944: LIBRARY OBJECT HANDLE: handle=1895899e8 mtx=0x189589b18(1) cdp=1 name=select* from sys.obj$ where obj#=:x hash=8cd0bd4dbb09ea7c3d007f1ce9b01738 timestamp=08-21-2012 10:02:35 namespace= CRSRflags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/ kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=6 hpc=0002 hlc=0002 lwt=0x189589a90 ltm=0x189589aa0 pwt=0x189589a58 ptm=0x189589a68 ref=0x189589ac0 lnd=0x189589ad8 LOCK OWNERS: lock user session count mode flags -------- -------- -------- ----- ---- ------------------------ 17f72e938 1852c9890 1852c9890 1 N LIBRARY OBJECT: object=1786e6168 type=CRSR flags=EXS pflags= status=VALD load=0 CHILDREN: size=16 child# table reference handle ------ -------- --------- -------- 0 17816fa10 17816f680 144768330 DATA BLOCKS: data# heap pointer status pins change whr ----- -------- -------- --------- ---- ------ --- 0 144773248 1786e6280 I/P/A/-/- 0 NONE 00 BUCKET 5944 total object count=1
LIBRARY OBJECT HANDLE: handle=144768330 mtx=0x144768460(0) cdp=0 namespace=CRSR flags=RON/KGHP/PN0/EXP/ kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=6 hpc=fffe hlc=fffe lwt=0x1447683d8 ltm=0x1447683e8 pwt=0x1447683a0 ptm=0x1447683b0 ref=0x144768408 lnd=0x144768420 CHILD REFERENCES: reference latch flags --------- ----- ------------------- 17816f680 11 CHL LOCK OWNERS: lock user session count mode flags -------- -------- -------- ----- ---- ------------------------ 17f72f1d8 1852c9890 1852c9890 1 N LIBRARY OBJECT: object=178161a10 type=CRSR flags=EXS pflags= status=VALD load=0 DEPENDENCIES: count=1 size=16 dependency# table reference handle position flags ----------- -------- --------- -------- -------- ------------------- 0 17837dae8 17837d828 189addbb8 17 DEP AUTHORIZATIONS: count=1 size=16 minimum entrysize=16 00000000 00000000 00020000 00000000 ACCESSES: count=1 size=16 dependency# types ----------- ----- 0 0009 SCHEMA: count=1 size=262144 00000000 DATA BLOCKS: data# heap pointer status pins change whr ----- -------- -------- --------- ---- ------ --- 0 144e55298 178161b28 I/P/A/-/- 0 NONE 00 6 1786cd5a0 16ece5dc0 I/-/A/-/E 0 NONE 00
页:
[1]