第四讲--shared pool内存块组成结构及4031错误产生原因分析

我们只能设置shared pool的大小，不能设置里面librarycache和row cache的大小。

 

Free的内存结构：

Free空间由一个个小的内存块（chunk，图中圆圈）组成，然后用链（chain）把内存块挂到链上。图中所示的三个链由上到下所挂的内存块的大小越来越大。

硬解析时根据SQL执行计划的大小，从free区中分配合适的内存块给执行计划，并把内存块移到library cache里。

假设一种情况：上图由上到下三个链的大小是4K、8K、12K，此时一个执行计划需要10K，那么就从12K的链上取出一块内存，分成两半，一半10K给执行计划，另一半2K挂到更小的链上。

过多的硬解析容易造成碎片，虽然free区有很多空间但是都是小碎片，不能使用。如果SQL找不到合适大小的内存块（chunk），这是会报ORA-4031错误。

ORA-4031错误产生的原因：

1.      大量的硬解析；

2.      大量硬解析产生大量小碎片以后突然又来了一些比较长的SQL语句，长SQL需要大空间，这个时候空间就不够了；

链：可以把内存块串起来；所有的内存块都挂在链上，链可以遍历；oracle大量使用链技术，链由锁（latch）来保护

 

library cache的内存结构：

跟free一样也是由链组成，但是挂载链上的内存块写的有内容。内容就是SQL语句以及对应的执行计划（plan）。

 

硬连接发生时，free上的chunk挂到library cache上的过程：

1.      SQL语句所有的字母被server process解析成ASCII码值，SQL语句被变成一串数字了；

2.      然后对这一串数字进行运算，得到一个数字，这个数字就是library cache中链的编号；

3.      Server process把SQL语句以及对应的执行计划挂到算出编号的链上；

4.      当再次执行这条SQL语句时，server process执行步骤1-2，得到链编号，链上挂着很多chunk，server process用锁（latch）把链锁上，遍历链，找到chunk以后就是软解析了；

查看shared pool里面有多少个chunk：

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

发生一次硬解析：

> select count(*) from dba_indexes;
 
 COUNT(*)
----------
     2344

 

然后再查chunk数：

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

 

清空library cache和row cache：

<pre name="code" class="sql">SQL> alter system flushshared_pool;
System altered.

清空之后执行任何一条语句都会发生硬解析，同时ORA-4031错误立马减少。