自动化分析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的效率会大大降低，而搜索期间会持