这就是由于shared pool中进行sql解析，请求空间，进而导致请求free空间,分配、分割从而产生了更多，更细碎的内存chunk
由此我们可以看出，如果数据库系统中存在大量的硬解析，不停请求分配free的shred pool内存除了必须的shared pool latch等竞争外，还不可避免的会导致shared pool中产生更多的内存碎片(当然，在内存回收时，你可能看到chunk数量减少的情况)我们看以下测试:

首先重新启动数据库:

SQL> startup force;
ORACLE instance started.

Total System Global Area47256168 bytes
Fixed Size  451176 bytes
Variable Size 29360128 bytes
Database Buffers16777216 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.

创建一张临时表用以保存之前x$ksmsp的状态:

SQL> CREATE GLOBAL TEMPORARY TABLE e$ksmsp ON COMMIT PRESERVE ROWS AS
  2  SELECTa.ksmchcom,
  3  SUM (a.CHUNK) CHUNK,
  4  SUM (a.recr) recr,
  5  SUM (a.freeabl) freeabl,
  6  SUM (a.SUM) SUM
  7FROM (SELECTksmchcom, COUNT (ksmchcom) CHUNK,
  8DECODE (ksmchcls, ’recr’, SUM (ksmchsiz), NULL) recr,
  9DECODE (ksmchcls, ’freeabl’, SUM (ksmchsiz), NULL) freeabl,
 10SUM (ksmchsiz) SUM
 11 FROM x$ksmsp GROUP BY ksmchcom, ksmchcls) a
 12  where 1 = 0
 13  GROUP BY a.ksmchcom;

Table created.

保存当前shared pool状态:

SQL> INSERT INTO E$KSMSP
  2  SELECTa.ksmchcom,
  3  SUM (a.CHUNK) CHUNK,
  4  SUM (a.recr) recr,
  5  SUM (a.freeabl) freeabl,
  6  SUM (a.SUM) SUM
  7FROM (SELECTksmchcom, COUNT (ksmchcom) CHUNK,
  8DECODE (ksmchcls, ’recr’, SUM (ksmchsiz), NULL) recr,
  9DECODE (ksmchcls, ’freeabl’, SUM (ksmchsiz), NULL) freeabl,
 10SUM (ksmchsiz) SUM
 11 FROM x$ksmsp
 12GROUP BY ksmchcom, ksmchcls) a
 13  GROUP BY a.ksmchcom
 14  /

41 rows created.

执行查询:

SQL> select count(*) from dba_objects;

  COUNT(*)
----------
  10492
  
比较前后shared pool内存分配的变化:

SQL> select a.ksmchcom,a.chunk,a.sum,b.chunk,b.sum,(a.chunk - b.chunk) c_diff,(a.sum -b.sum) s_diff
  2  from
  3  (SELECTa.ksmchcom,
  4  SUM (a.CHUNK) CHUNK,
  5  SUM (a.recr) recr,
  6  SUM (a.freeabl) freeabl,
  7  SUM (a.SUM) SUM
  8FROM (SELECTksmchcom, COUNT (ksmchcom) CHUNK,
  9DECODE (ksmchcls, ’recr’, SUM (ksmchsiz), NULL) recr,
 10DECODE (ksmchcls, ’freeabl’, SUM (ksmchsiz), NULL) freeabl,
 11SUM (ksmchsiz) SUM
 12 FROM x$ksmsp
 13GROUP BY ksmchcom, ksmchcls) a
 14  GROUP BY a.ksmchcom) a,e$ksmsp b
 15  where a.ksmchcom = b.ksmchcom and (a.chunk - b.chunk) <>0
 16  /

KSMCHCOMCHUNK  SUM CHUNK  SUMC_DIFF  S_DIFF
---------------- ----------   ----------   ---------- ---------- ----------
KGL handles 313  102080302 98416 11 3664
KGLS heap274  365752270  360424  4 5328
KQR PO 389  198548377  192580 12 5968
free memory93 2292076 90 2381304  3  -89228
library cache  1005398284965  381416 4016868
sql area  287547452269  490052 1857400

6 rows selected.  
 
我们简单分析一下以上结果: 首先free memory的大小减少了89228(增加到另外五个组件中),这说明sql解析存储占用了一定的内存空间
而chunk从90增加为93，这说明内存碎片增加了. 在下面的部分中,我会着手介绍一下KGL handles, KGLS heap这两个非常重要的shared pool中的内存结构.