ITPub博客

首页 > 数据库 > Oracle > PerformanceTuning 笔记4 v$librarycache的分析

PerformanceTuning 笔记4 v$librarycache的分析

原创 Oracle 作者:SnowDBA 时间:2014-11-17 11:12:06 0 删除 编辑
调优Library Cache的核心思想就是减少解析(parse)

主要手段:
  • 确保用户使用共享的SQL语句
  • 分配足够多的内存防止已经parse的sql语句被唤出。
  • 避免无效对象的产生。比如drop掉原有的snow.t1表,重建snow.t1表。这样再执行该表的查询操作时,看似表名没有变化但是查询需要重新解析。
  • 为内存需求比较大的SQL保留一部分空间。
  • 将常用的一些应用固定在Library cache中不被唤出。
  • 消除大量的匿名PL/SQL代码块
v$librarycache动态性能视图统计了librarycache性能和活动指标。下面的参数常用来诊断当前library cache
  • Gets:(解析阶段)查找该SQL是否已经解析过了
  • GetsHits:查找命中率
  • Pins:(执行阶段)读取或执行的次数
  • Reloads:(解析阶段)执行期间找到的对象无效了,或者被唤出了,需要重新解析。
  • Invalidations:(解析阶段)如果解析后的对象被改变了,需要重新解析。
v$librarycache的查询示例:



解读Library Cache统计信息:

在动态性能视图v$librarycache中reload的值应该接近0,如果该值很高就需要调整了。表示已经解析过的SQL由于某种原因被唤出了。如果该SQL语句再次执行需要重新解析。因此减少reload的次数是关键。

在动态性能视图v$librarycache中invalidations值应该接近0。如果改制较高,可能是因为DDL操作导致表结构改变,之前解析的结果全部失效。

在动态性能视图v$sgastat中的free memory的值应该尽可能低。如果reload值比较高很可能是因为内存太小导致。为shared pool分配足够的内存可以提升效果。

librarycahce的命中率:下图中由于library cache太小导致很多的parse结果被唤出了(reloads 13105)


reloads值应该小于pins的1%。如果reloads大于1,并且free memory值很低通常是因为library cache太小导致。可以通过扩充shared pool的大小来解决。

SQL> select sum(pins) "executions",sum(reloads) "cache misses",sum(reloads)/sum(pins) from v$librarycache;

executions cache misses SUM(RELOADS)/SUM(PINS)
---------- ------------ ----------------------
   4985760        33921             .006803577

注意该值是数据库运行以来的历史累加值,如果想要取得某个阶段的确切至应该使用AWR报告或者statspack。
或者间隔一个时间段分别执行两次select namespace,gethitratio,pinhitratio,reloads,invalidations from v$librarycache;对比各个字段值的变化。

下面的SQL可以显示正在运行中的SQL语句


根据已知信息查询SQL语句的完整信息

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

请登录后发表评论 登录
全部评论

注册时间:2014-06-21

  • 博文量
    223
  • 访问量
    1633615