简单分析shared pool(一) (r3笔记46天)

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的，只能在根据需要的时候才释放空间。