2.shared pool的内存结构
    从一个逻辑层面来看，shared pool由library cache和dictionary cache组成。shared pool中组件之间的关系可以用下图一来表示。从下面这个图中可以看到，当SQL语句（select object_id,object_name from sharedpool_test）进入library cache时，oracle会到dictionary cache中去找与sharedpool_test表有关的数据 
   
                                            图一
    字典信息，比如表名、表的列等，以及用户权限等信息。如果发现dictionary cache中没有这些信息，则会将system表空间里的数据字典信息调入buffer cache内存，读取内存数据块里的数据字典内容，然后将这些读取出来的数据字典内容按照行的形式放入dictionary cache里，从而构造出dc_tables之类的对象。然后，再从dictionary cache中的行数据中取出有关的列信息放入library cache中。

    从一个物理的层面来看，shared pool是由许多内存块组成，这些内存块通常称为chunk。Chunk是shared pool中内存分配的最小单位，一个chunk中的所有内存都是连续的。这些chunk可以分为四类，这四类可以从x$ksmsp（该视图中的每个行都表示shared pool里的一个chunk）的ksmchcls字段看到：
1) free：这种类型的chunk不包含有效的对象，可以不受限制的被分配。
2) recr：意味着recreatable，这种类型的chunks里包含的对象可以在需要的时候被临时移走，并且在需要的时候重新创建。比如对于很多有关共享SQL语句的chunks就是recreatable的。

3) freeabl：这种类型的chunks包含的对象都是曾经被session使用过的，并且随后会被完全或部分释放的。这种类型的chunks不能临时从内存移走，因为它们是在处理过程中间产生的，如果移走的话就无法被重建。

4) perm：意味着permanent，这种类型的chunks包含永久的对象，大型的permanent类型的chunks也可能含有可用空间，这部分可用空间可以在需要的时候释放回shared pool里。

    当chunk属于free类型的时候，它既不属于library cache，也不属于dictionary cache。如果该chunk被用于存放SQL游标时，则该chunk进入library cache；同样，如果该chunk被用于存放数据字典的信息时，则该chunk进入dictionary cache。
在shared pool里，可用的chunk（free类型）会被串起来成为可用链表（free lists）或者也可以叫做buckets（一个可用链表也就是一个bucket）。我们可以使用下面的命令将shared pool的内容转储出来看看这些bucket。
alter session set events 'immediate trace name heapdump level 2';
然后打开产生的转储文件，找到“FREE LISTS”部分，可以发现类似如下图二所示的内容。 

   
      图二
     这是在9i下产生的bucket列表，9i以前的可用chunk的管理方式是不一样的。我们可以看到，可用的chunk链表（也就是bucket）被分成了254个，每个bucket上挂的chunk的尺寸是不一样的，有一个递增的趋势。我们可以看到，每个bucket都有一个size字段，这个size就说明了该bucket上所能链接的可用chunk的大小尺寸。

    当一个进程需要shared pool里的一个chunk时，假设当前需要21个单位的空间，则该进程首先到符合所需空间大小的bucket（这里就是bucket 2）上去扫描，以找到一个尺寸最合适的chunk，扫描持续到bucket的最末端，直到找到完全符合尺寸的chunk为止。如果找到的chunk的尺寸比需要的尺寸要大，则该chunk就会被拆分成两个chunk，一个chunk被用来存放数据，而另外一个则成为free类型的chunk，并被挂到当前该bucket上，也就是bucket 2上。然而，如果该bucket上不含有任何需要尺寸的chunk，那么就从下一个非空的bucket上（这里就是bucket 3）获得一个最小的chunk。如果在剩下的所有bucket上都找不到可用的chunk，则需要扫描已经使用的recreatable类型的chunk链表，从该链表上释放一部分的chunk出来，因为只有recreatable类型的chunk才是可以被临时移出内存的。当某个chunk正在被使用时（可能是用户正在使用，也可能是使用了dbms_shared_pool包将对象钉在shared pool里），该chunk是不能被移出内存的。比如某个SQL语句正在执行，那么该SQL语句所对应的游标对象是不能被移出内存的，该SQL语句所引用的表、索引等对象所占用的chunk也是不能被移出内存的。当shared pool中无法找到足够大小的所需内存时，报ORA-4031错。当出现4031错的时候，你查询v$sgastat里可用的shared pool空间时，可能会发现name为“free memory”的可用内存还足够大，但是为何还是会报4031错呢？事实上，在oracle发出4031错之前，已经释放了不少recreatable类型的chunk了，因此会产生不少可用内存。但是这些可用chunk中，没有一个chunk是能够以连续的物理内存提供所需要的内存空间的，从而才会发出4031的错。

     对bucket的扫描、管理、分配chunk等这些操作都是在shared pool latch的保护下进行的。如果shared pool含有数量巨大的非常小的free类型的chunk的话，则扫描bucket时，shared pool latch会被锁定很长的时间，这也是8i以前的shared pool latch争用的主要原因。而如果增加shared pool尺寸的话，仅仅是延缓shared pool latch的争用，而到最后，就会因为小的free chunks的数量越来越多，争用也会越来越严重。而到了9i以后，由于大大增加了可用chunk链表（也就是bucket）的数量，同时，每个bucket所管理的可用chunk的尺寸递增的幅度非常小，于是就可以有效的将可用的chunk都均匀的分布在所有的bucket上。这样的结果就是每个bucket上所挂的free类型的chunk都不多，所以在查找可用chunk而持有shared pool latch的时间也可以缩短很多。

    对于非常大的对象，oracle会为它们单独从保留区域里分配空间，而不是从这个可用chunk链表中来分配空间。这部分空间的大小尺寸就是由初始化参数shared_pool_reserved_size决定的，缺省为shared_pool_size的5%，这块保留区域与正常的chunk的管理是完全分开的，小的chunk不会进入这块保留区域，而这块保留区域的可用chunk也不会挂在bucket上。这块保留区域的使用情况可以从视图v$shared_pool_reserved中看到，通常来说，该视图的request_misses字段显示了需要从保留区域的可用链表上上获得大的chunk而不能获得的次数，该字段应该尽量为0。