PerformanceTuning 笔记4 v$librarycache的分析-CSDN博客

调优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语句