自动化分析Oracle shared pool争用因素

Oracle SHARED POOL上的性能问题比BUFFER POOL上的要严重得多。本文将进一步地探讨SHARED POOL上的优化思路。
首先，需要确保SHARED POOL的大小足够。到Oracle 11.2.0.3为止，存放在SHARED POOL中的组件越来越多，对SHARED POOL的要求也越来越高。如果数据库升级，建议适当扩大SHARED POOL。当SHARED POOL内存不够时，相关组件会由于内存不足而产生争用，尤其是ROW CACHE争用可能会导致严重的性能问题。如果SHARED POOL内存紧张，可能会导致CURSOR失效或者频繁地被交换出SHARED POOL，可以使用DBMS_SHARED_POOL.KEEP将重要的CURSOR固定在SHARED POOL中。
注意使用SUB POOL。从Oracle 9i开始，Oracle推出了SUB POOL技术，即在SHARED POOL中分出了多个子池，每个子池拥有独立的SHARED POOL 等LATCH。从理论上来说SUB POOL技术提高了SHARED POOL的并发能力，但SUB POOL技术相当于逻辑地分割了SHARED POOL内存，将SHARED POOL的大内存分割成了几个内存片，服务器进程在其中一个SUB POOL中分配不到内存的时候，不会无限制地去另外的SUB POOL中寻找空闲内存，所以SUB POOL技术增大了ORA-04031错误发生的概率。
对于内存，够用就行。这是在性能优化时始终需要记住的一个准则。在操作系统内存足够的情况下，很多DBA喜欢一次性给SHARED POOL分配足够大的空间，如30GB。Oracle会尽可能地利用SHARED POOL中的内存，即在SHARED POOL中缓存CURSOR信息，当SHARED POOL设置过大时，Oracle搜索其CURSOR的效率会大大降低，而搜索期间会持有各类的MUTEX或者LATCH，进而导致数据库性能下降。所以也需要注意在自动内存管理的情况下，SHARED POOL过度自动扩张的情况。
注意内存碎片。当SHARED POOL中出现内存碎片时，不能贸然刷SHARDE POOL操作，严重时会HANG住整个实例。不要对对象进行频繁的DDL、赋权、收集统计信息等操作，该类操作会无效化SHARED POOL中的相关CURSOR，CURSOR无效化则会加剧ROW CACHE和LIBRARY CACHE的负担，降低数据库的性能。
尽可能使用软解析。SHARED POOL上的性能问题很大程度上是由于并发引起的，所以如果存在大量的硬解析就应该引起足够重视。当发生大量的硬解析时，最好能够从应用层面修改代码，如果应用层面无法修改，则建议设置CURSOR_CHARING参数为FORCE（设置为SIMILAR可能存在较多的BUG，需要引起注意），并根据应用设置SESSION_CACHED_CURSORS和OPEN_CURSORS参数。根据经验，如果CURSOR信息能够从PGA中找到，即设置SESSION_CACHED_CURSORS有效，能大大降低SHARED POOL的压力，大幅度地提高系统的并发能力和性能。
注意绑定变量窥视（BIND PEEKING）。如果SQL中的选择谓词存在柱状图，其上又有绑定变量，那么就需要注意绑定变量窥视的问题。绑定变量窥视容易引起执行计划不稳定。在RAC系统中，可能会导致节点之间SQL执行计划不同的情况。
注意SQL高版本（HIGH VERSION），高版本的SQL会导致服务器进程搜索HANDLE的时间增长，进而加大LATCH:LIBRAYR CACHE争用的概率。Oracle BUG往往会导致SQL的版本莫名升高。
不要收集无谓的柱状图。如果SQL执行计划稳定，那么收集过多的柱状图反而会增加ROW CACHE的压力，严重时会引起ROW CACHE OBJECTS LATCH争用。
注意Oracle BUG。由于Oracle不断地往SHARED POOL中引进新特性，新特性往往会带来新BUG，当SHARED POOL出现莫名的性能问题时，需要查验是否是由BUG引起的。
如何自动化分析Oracle shared pool争用因素，
详见下图