浅析Shared Pool

内存结构：主要是包含以下三部分

free cache

library cache

row  cache

Free Cache

作用：管理管理free块,Free List按不同size划分Bucket

内存结构：主要有Chain（链）组成，链下面挂载上不同大小的Chunk（块）。

Free cache中包含多条链，每天链都有挂载不同大小的块

例如：

1号链（1k~4k）

2号链（4k~8k）

........

每个链上都挂着该范围内，不同大小的块。

当我们发出SQL，server process解析了后，去library cache中寻找是否存在一直的plan，如果没有，此时就需要去free cache中申请可用的空闲块，将占用的块又挂载到library cache上。

但是此时就会出现我们常见的ORA-4031错误，出现该错误的原因是我们去申请空闲块的时候，申请的块可能没有跟我大小一致匹配的块，只能去寻找合适大小的块，往往是大于我们需要的块，申请的块大了，就会剩下很多小块，Oracle将剩下的小块有重新挂载到对应范围的链上，随着时间的积累，大块消耗的更多，残留的小块越来越多，到最后一个较大的SQL执行时，需要大块，而此时链上全是比他需要的小，此时就会出现ORA-4031错误。

例如：在解析后我们没有找到适合执行计划，这个就需要chunk来存储这个新的计划，大小是10K，而我们在对应的链上只找到了一个适合其大小11K的数据块，Oracle就会占用它10K的空间，剩下的1K大小的数据块重新又挂到对应范围的chain上，以这种方式发展下去，总有一天free cache中全是留下一些小的块，假如当我在需要一个10K的数据块时，free cache中没有能满足这个空间的数据块，这是就会产生ORA-4031错误。

如何解决4031错误呢？

1：alter database flush shared_pool; 清空共享池，重新分配各类结构。但是在生产中，这是一个不可取的方式，清空后会产生大量硬解析，消耗大量的CPU

2：SQL共享，编写SQL时多使用绑定变量。这个是建议的方法，实现SQL的共享后，减少了硬解析，减少了CPU的消耗，提高了数据库的性能。

3：划分保留区：在shared_pool中专门为SQL大对象划分一个区域来存储们，这样就会减少对free cache的消耗，从而避免4031错误；

Library Cache

作用：用来存放SQL的执行计划

内存结构：与free cache类似，都是以链的方式来存放数据

上面的圆圈中就是用来存放SQL计划的，当用户发出SQL以后，server process接受到SQL并对其进行解析，解析后会得到一个相应的结果，而这个结果对应着我们library cache中的链编号，Oracle会根据这个结果去对应的链上查询是否有相应的SQL执行计划，如果没有，就会发生硬解析；反之，就会使用这个计划，发生软解析。

在硬解析的时候，也是最消耗内存的（耗费大约70%），所以我们在编写SQL时，尽量使用绑定变量，实现SQL的共享，减小硬解析。

查询SQL的解析情况：

row cache

作用：用来存放各类数据字典信息。因为我们在SQL解析的时候有三个过程：解析（语法、语义、权限）、执行（获取数据）、返回（结果）。

在解析的时候会涉及到用户权限等的问题，而我们的这些数据都记录在数据字典中，为了减少解析去数据字典中寻找这类数据发生的物理I/O，而造成的性能下降，所以在shared pool中会分配一个row cache来缓存数据字典的信息。