4.4 shared pool的等待事件
4.4.1 library cache latch
对于library cache latch来说，我们可以看看v$latch中按照sleeps排名前5位中是否有它。
我们看到，library cache latch的sleep排名比较靠前。这时，我们在前面已经说过，子library cache latch可能不会在library cache里的整个bucket链条上均匀分布，因此当我们通过查看v$latch发现library cache latch的等待非常高时，先别急着增加latch的个数，或者调整SQL等，而是先去看看v$latch_children中每个子library cache latch的等待是否都比较接近，如果发现这些latch的等待相差很大的话，则说明可能是没有最有效的使用latch。同时注意观察下面的MISSES/GETS列，如果它高于0.01的话，应该调整。
比如，从上面我们可以看到，CHILD#为5的子latch的miss占了整个latch的87%，因此，有可能是该子latch管理了过多的library cache object。我们可以使用下面的SQL语句来看看这个子latch到底管了哪些SQL对象：
select * from v$db_object_cache where child_latch=5 and namespace='CURSOR';
然后，看看该子latch所管理的SQL语句是不是可以改写一下，从而让它关联到其他4个子latch上去。有时候为列添加一个别名或者在where条件子句中添加一个条件“1=1”，就能够将该SQL转换到另外一个子library cache latch来管理，从而通过分散子library cache latch来达到降低该latch等待的目的。
如果所有的子library cache latch都均匀分布的话，则需要按照前面所说的方法检查SQL语句是否使用了绑定变量、是否大小写一致、空格是否相同等。如果这些都没问题，则检查shared pool是否设置过大，如果设置也合理的话，那就需要按照前面所说的，增加隐藏参数：_kgl_latch_count的值，从而增加library cache latch的数量。进入讨论组讨论。 
【深 度 阅 读】 相 关 文 章
4.4.1 library cache latch
对于library cache latch来说，我们可以看看v$latch中按照sleeps排名前5位中是否有它。
SQL> select latch#,name,sleeps from v$latch where sleeps!=0 order by sleeps desc; LATCH# NAME SLEEPS ---------- -------------------- ---------- 4 session allocation 38389 157 library cache 1221 3 process allocation 974 115 redo allocation 841 156 shared pool 755
我们看到，library cache latch的sleep排名比较靠前。这时，我们在前面已经说过，子library cache latch可能不会在library cache里的整个bucket链条上均匀分布，因此当我们通过查看v$latch发现library cache latch的等待非常高时，先别急着增加latch的个数，或者调整SQL等，而是先去看看v$latch_children中每个子library cache latch的等待是否都比较接近，如果发现这些latch的等待相差很大的话，则说明可能是没有最有效的使用latch。同时注意观察下面的MISSES/GETS列，如果它高于0.01的话，应该调整。
SQL> select latch#,child#,gets,round(ratio_to_report(gets) OVER (),2) as gets_radio, 2 misses,round(ratio_to_report(misses) OVER (),2) as misses_radio,misses/gets 3 from v$latch_children where name='library cache'; LATCH# CHILD# GETS GETS_RADIO MISSES MISSES_RADIO MISSES/GETS ---------- ---------- ---------- ---------- ---------- ------------ ----------- 157 5 7187577 0.3 160964 0.85 0.022394751 157 4 4308236 0.18 19943 0.11 0.004629040 157 3 4138652 0.17 2453 0.01 0.000592705 157 2 2458795 0.1 448 0 0.000182203 157 1 5974764 0.25 4619 0.02 0.000773084
比如，从上面我们可以看到，CHILD#为5的子latch的miss占了整个latch的87%，因此，有可能是该子latch管理了过多的library cache object。我们可以使用下面的SQL语句来看看这个子latch到底管了哪些SQL对象：
select * from v$db_object_cache where child_latch=5 and namespace='CURSOR';
然后，看看该子latch所管理的SQL语句是不是可以改写一下，从而让它关联到其他4个子latch上去。有时候为列添加一个别名或者在where条件子句中添加一个条件“1=1”，就能够将该SQL转换到另外一个子library cache latch来管理，从而通过分散子library cache latch来达到降低该latch等待的目的。
如果所有的子library cache latch都均匀分布的话，则需要按照前面所说的方法检查SQL语句是否使用了绑定变量、是否大小写一致、空格是否相同等。如果这些都没问题，则检查shared pool是否设置过大，如果设置也合理的话，那就需要按照前面所说的，增加隐藏参数：_kgl_latch_count的值，从而增加library cache latch的数量。进入讨论组讨论。
【深 度 阅 读】 相 关 文 章
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- (0次浏览)教你怎样在Oracle数据库中高速导出/导入
- (0次浏览)Oracle 10g 启动关闭命令
- (0次浏览)Oracle10G常用维护语句
- (0次浏览)ORA-06512 get_ddl
- (0次浏览)Oracle数据库event事件与dump文件介绍
- (0次浏览)Oracle数据库Spfile学习总结
- (0次浏览)Oracle自增字段的创建
- (0次浏览)解读ORACLE数据库的统一命名与编码规范
- (0次浏览)Oracle定义约束 外键约束
- (0次浏览)ORA-12714错误解决总结
