简单分析shared pool(一)

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<2;
       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的大小没有一个直观的感受，可以生成一个图来看看就很清楚了。

随着bucket的增长，对应的chunk大小都在递增，绝大多数的bucket中，chunk的大小都在5k以内。只有很小的一部分bucket的支持的chunk size很大，
这个也是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的分配还是一个动态的过程，比如shared pool分为library cache,dictionary cache,如果chunk存放的sql相关的信息时，chunk就属于library cache.
如果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的，只能在根据需要的时候才释放空间。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1320716/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1320716/