内存调整之Shared_Pool篇

Shared Pool结构使用来实现SQL共享，减少代码硬解析等，从而提高数据库性能。但是，使用或是管理不当，很可能带来额外的负担或相反的作用。伴随着日常不合理使用的加剧，如数据库中存在大量的硬解析，不停的请求分配Free的Shared Pool内存，Shared Pool会产生很多碎片，从而导致搜索Free List的时间变长。另一方面，不合理的使用也会增加串行的的的Shared Pool Latch的等竞争。这种锁机制也往往成为性能的瓶颈。

所以，可能造成这种性能低下的原因包含(数据仓库环境除外，且鼓励使用literal values来代替绑定变量，从而优化器可以更正确的制定Access Plan)：

1. SQL没有足够的共享；
2. 过度的硬解析；
3. 没有使用绑定变量。

最值得推荐的方法就是通过编写sharable的SQL来使性能的以提高；除此之外，还可以通过设置Cursor_Sharing初始化参数来使SQL共享。这个参数默认的设置为EXACT。顾名思义，系统要求多个需要Share的SQL是严格等价的，这甚至包括字符的大小写以及空格。若要启用强制共享特性，则需将此参数设置为Similar或Force。前者的含义为各语句是相同的，除了那些字符的值存在差异，后者强制Similar的语句共享SQL AREA。除此之外，二者之前需要我们注意的是，FORCE是有可能改变SQL的执行计划，这点是非常危险的。有必要将Cursor_Sharing初始化参数设置为Similar或Force的前提是下面两个条件都满足：

1. Are there statements in the shared pool that differ only in the values of literals?
2. Is the response time low due to a very high number of library cache misses?

由于shared server，parallel query和RMAN等都需要从Shared_Pool中划分大量的内存！为避免对其他应用的影响，如有需要，则可以通过配置Large Pool为上述操作提供特定的内存。

相关的参数可从以下方法中获取--〉

[@more@]

Library Cache Statistics：通过查看V$LibraryCache动态性能视图的相关参数，可以获取在library cache中的内存使用效率。

其中NAMESPACE列中的 SQL AREA，TABLE/PROCEDURE，BODY，TRIGGER这四行记录反映了SQL语句或PL/SQL的相关活动。Reloads和Invalidations均应接近0，代表经常执行的相关指令基本不需硬解析而直接从内存中获得。

计算Librarycache命中率的公式为：

Library Cache Hit Ratio = sum(pinhits) / sum(pins)

调整Librarycache的另一个目标就是在保证上面诸如命中率等各项指标优异的前提下，尽量减少空闲内存的存在，避免资源浪费。

计算空闲内存可通过查询V$SGASTAT实现：

SELECT * FROM V$SGASTAT
WHERE NAME = 'free memory'
AND POOL = 'shared pool';

关于设置不同部分的SIZE的预估可以通过查询以下视图来获得：

V$SHARED_POOL_ADVICE，V$LIBRARY_CACHE_MEMORY

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/404722/viewspace-927201/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/404722/viewspace-927201/