ITPub博客

首页 > IT基础架构 > 网络安全 > 内存调整之Shared_Pool篇

内存调整之Shared_Pool篇

原创 网络安全 作者:zildjianzhang 时间:2007-07-20 10:02:27 0 删除 编辑

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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    15
  • 访问量
    206095