oracle中的shared pool很重要，但是感觉知之甚少。今天想在原来的认识上能够有一点更深入的了解。
简单做了一个总结。
首先是转储一下shared pool共享内存的内容。
SQL> alter session set events 'immediate trace name heapdump level 2';
Session altered.
这个步骤会得到一个trace文件。简单的换算一下，就得到了trace文件的大体信息。
SQL> select sid from v$mystat where rownum SID
----------
24
SQL> select sid,serial# ,paddr from v$session where sid=24;
SID SERIAL# PADDR
---------- ---------- ----------------
24 83 00000000727B03B0
SQL> select spid from v$process where addr='00000000727B03B0';
SPID
------------------------
18155
SQL> host
简单验证一下，对应的process是否存在。
[ora11g@rac1 ~]$ ps -ef|grep 18155
ora11g 18155 18106 0 06:00 ? 00:00:02 oracleTEST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
ora11g 19326 19167 0 06:21 pts/0 00:00:00 grep 18155
在trace文件目录下查看日志文件是否存在。
[ora11g@rac1 trace]$ ls -l *18155*.trc
-rw-r----- 1 ora11g dba 6900360 Nov 4 06:11 TEST01_ora_18155.trc
对于shared pool来说，存储单位是chunk,多个chunk组成一个链表，也叫做bucket.
每个bucket都对chunk的大小都有一定的范围，是一个连续的值，没有交叉。
在10g，11g中都设置了255个bucket。
简单通过trace文件来看一下。
[ora11g@rac1 trace]$ grep Bucket *18155*.trc
Bucket 0 size=32
Bucket 1 size=40
Bucket 2 size=48
Bucket 3 size=56
Bucket 4 size=64
Bucket 5 size=72
...
Bucket 250 size=12352
Bucket 251 size=12360
Bucket 252 size=16408
Bucket 253 size=32792
Bucket 254 size=65560
可能对于bucket的大小没有一个直观的感受，可以生成一个图来看看就很清楚了。
这个也是oracle在不断的改进中得到的一个最优值，按照比例来划分，保证每次访问需要的chunk大小都能够合理的分配，尽量减少冗余。
同时不是每个bucket里面都是有chunk的，这个chunk的分配还是根据进入shared pool以后申请chunk大小紧密相关，bucket中的chunk数目可不是平均的。
如果想看看shared Pool比较细节一下的信息。可以参考x$ksmsp
这个基表中还是包含了不少的信息值得我们去学习。首先x$ksmsp里面的每一条记录代表一个chunk
SQL> select count(*)from x$ksmsp;
COUNT(*)
----------
53317
如果你马上执行了一个其它的查询，再来看x$ksmsp的条数，就很可能发生变化。
SQL> select count(*)from all_objects;
COUNT(*)
----------
13225
SQL> select count(*)from x$ksmsp;
COUNT(*)
----------
53363
如果chunk存放的信息时dictionary cache的话，chunk就属于dictionary cache.
按照大多数对象的生命周期，chunk的情况也大体如此，可能在不同的数据库版本中会略有不同。
比如在11gR2中的结果会和10g有一些不同。chunk的状态可能有多种，但是大体还是可以理解为4类，free,recr,perm,freeable
KSMCHCLS COUNT(*)
-------- ----------
freeabl 20196
recr 26469
perm 581
R-freea 134
R-free 60
R-perm 4
free 5918
R-recr 1
首先,可以分配空间的chunk,这种类型的chunk是free,
如果某个session执行的sql语句，同时另外一个session也执行了同样的sql语句，在shared pool中这种类型的chunk就可以临时移出内存，因为可以在需要的时候进行重建。这种chunk就是recreatable的。
如果某个session执行的sql语句都是不同的，或者没有绑定变量，导致在执行的时候生成的sql_id都不同，这种类型的chunk是不能临时欲出内存的，只能在需要的时候进行释放。这种chunk就是freeable的。
如果某个对象通过dbms_pool给直接pin在了shared pool里面，那么对应的chunk就是permanent的，只能在根据需要的时候才释放空间。
