SHARED POOL的优化思路

     SHARED POOL作为一块共享内存区域是SGA的重要组件之一，所以对其优化是有必要的而且是必须的。下面主要是介绍SHARED POOL的优化思路，SGA的组成结构以及每个结构的包括的内容及其作用不做介绍：

 

1.确保shared pool的大小足够：

    随着新版本的推出，存放在oracle中的组件越来越多，对shared pool的要求也就越来越高。如果数据库升级，建议适当的扩大shared pool。当shared pool内存不够的时候，相关的组件会因为内存不足而产生争用，而且如果shared pool内存紧张，还可能导致cursor失效或者频繁的被交换出shared pool，可以使用dbms_shared_pool.keep将重要的cursor保存在shared pool中。

 

2.使用sub pool：

    从Oracle9i开始，Oracle推出了sub pool技术，即在shared pool中分出多个子池，每个子池独立的拥有shared pool latch。从理论上来说sub pool技术提高了shared pool的并发能力，但是sub pool相当于分割成了几个内存片，服务器进程在其中一个sub pool中分配不到内存的时候，不会无限制的去另外的sub pool中去寻找空闲的内存，所以sub pool技术增大了ora-04031的错误发生概率。

 

3.对于shared pool，够用就行：

   如果shared pool过大，oracle就会尽可能的利用shared pool中的内存，当其搜索cursor时的效率会大大降低，搜索期间会持有各类的mutex和latch，从而导致数据库的性能下降。所以也需要注意在自动内存管理的情况下，shared pool过度扩张的情况。

 

4.注意内存碎片：

   当shared pool中出现内存碎片的时候，不能贸然的flush shared pool，严重的时候会hang住整个实例。不要对对象进行频繁的DDL、赋权、收集统计信息等操作，这些操作会使shared pool中相关的cursor失效，cursor无效则会加剧row cache和library cache争用，降低数据库的性能。

 

5.尽可能的使用软解析：

   shared pool上的性能问题很大程度上是由并发引起的，当发生大量的硬解析的时候，最好能够从应用层修改代码，如果应用程序无法修改，则建议设置cursor_sharing参数为force（设置为similar可能存在较多的bug，需要注意），并根据应用设置session_cached_cursors和open_cursors参数。

 

6.注意绑定变量窥视：

   如果sql中的选择谓词存在柱状图，其上有有绑定变量，那么就需要注意绑定变量窥视的问题了。绑定变量窥视容易引起执行计划不稳定。在rac系统中，可能会导致节点之间sql执行计划不同的情况。

 

7.注意sql高版本：

   高版本的sql会导致服务器进程搜索handle的时间变长，从而加大了library cache latch的争用的概率。oracle bug 往往会导致sql的版本莫名的升高。

 

8.不要收集无意义的柱状图：

   如果sql的执行计划稳定，那么收集过多的柱状图反而会增加row cache的压力，严重时会引起row cache objects latch争用。

 

9.注意Oracle bug：

   由于Oracle不断的往shared pool中引入新特性，新特性往往会带来新的bug，当shared pool出现莫名的性能问题时，需要检查是否是由bug引起的。

 

 

 

 

注：摘录自《DBA实战攻略》