我们继续把前面的问题展开一下. 其实我们可以从数据库内部监控shared pool的空间碎片情况. 这涉及到一个内部视图x$ksmsp X$KSMSP的名称含义为: [K]ernal [S]torage [M]emory Management [S]GA Hea[P] 其中每一行都代表着shared pool中的一个chunk首先记录一下测试环境：  
  
SQL> select * from v$version; 
BANNER 
---------------------------------------------------------------- 
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production 
PL/SQL Release 9.2.0.3.0 - Production 
CORE 9.2.0.3.0 Production 
TNS for Linux: Version 9.2.0.3.0 - Production 
NLSRTL Version 9.2.0.3.0 - Production 

  
我们看一下x$ksmsp的结构: 
  

SQL> desc x$ksmsp 
 Name  Null? Type 
 ----------------------------------------- -------- ---------------------------- 
 ADDRRAW(4) 
 INDX NUMBER 
 INST_ID  NUMBER 
 KSMCHIDX NUMBER 
 KSMCHDUR NUMBER 
 KSMCHCOMVARCHAR2(16) 
 KSMCHPTR RAW(4) 
 KSMCHSIZ  NUMBER 
 KSMCHCLS VARCHAR2(8) 
 KSMCHTYP  NUMBER 
 KSMCHPAR RAW(4)

我们关注以下几个字段: 
KSMCHCOM是注释字段,每个内存块被分配以后，注释会添加在该字段中. 
x$ksmsp.ksmchsiz代表块大小 
x$ksmsp.ksmchcls列代表类型，主要有四类，说明如下: 
free 
Free chunks--不包含任何对象的chunk,可以不受限制的被分配. 
recr 
Recreatable chunks--包含可以被临时移出内存的对象,在需要的时候，这个对象可以 
被重新创建.例如,许多存储共享sql代码的内存都是可以重建的. 
freeabl 
Freeable chunks--包含session周期或调用的对象,随后可以被释放.这部分内存有时候 
可以全部或部分提前释放.但是注意，由于某些对象是中间过程产生的，这些对象不能 
临时被移出内存(因为不可重建). 
perm 
Permanent memory chunks--包含永久对象.通常不能独立释放. 
我们可以通过查询x$ksmsp视图来考察shared pool中存在的内存片的数量不过注意:Oracle的某些版本(如:10.1.0.2)在某些平台上(如:HP-UX PA-RISC 64-bit)查询该视图可能导致过度的CPU耗用,这是由于bug引起的. 我们看一下测试:  
  
初始启动数据库,x$ksmsp中存在2259个chunk 

SQL> select count(*) from x$ksmsp; 

  COUNT(*) 
---------- 
2259 


执行查询: 

SQL> select count(*) from dba_objects; 

  COUNT(*) 
---------- 
  10491 

此时shared pool中的chunk数量增加 

SQL> select count(*) from x$ksmsp; 

  COUNT(*) 
---------- 
2358