成就无边界 IT 服务
www.shsnc.cn
1
Latch Free、Library cache 伪游标(pseudo cursor)之间的那些
事
作者:林印豪,新炬网络高级技术专家。
一、Latch Free 很头疼
“57.8 这套系统 CPU 又 100%啦,新炬同事赶紧帮忙看一下。”远处传来了客户的声
音。
我不慌不忙的打开终端,轻叹口气道:“唉,又是这套库,自从我来这边,已经查了 2
遍了,而且其他人也查过好几遍了,问题很难定位啊!“
前面我查了几次都觉得是 SQL 硬解析的问题,可是把这个事情反馈过去之后。他们给
我们发了以前的 statspack 报告,发现硬解析过去是 300 次/秒,现在下降到了 60 次/
秒,Latch free 却增加了不少,着实摸不着头脑。”通过前期的排查基本上定位出了 Latch
Free 的争用是由于 library cache 引起的。当系统出现大量的 Library cache 争用的时候,
CPU 就会达到 100%。但是原因?最重要的原因一直未找到。我认为是硬解析导致的,也
有同事认为是 shared pool 太小导致的。还有同事认为是几条逻辑读较高的语句导致的。
众说纷纭,也没有一个准。基本上这些方法客户都尝试过了,仍然未能解决这个问题。
二、从 Library cache 入手走下去
前期的排查让我们确信的一点是 CPU 的消耗是在 Library cache 争用上面,那么
Library cache 里面情况又是如何的呢?为了一探究竟,我决定在出问题期间直接查询
v$libarycache 视图,找寻根源。
SQL> select NAMESPACE,GETS,GETHITS,GETHITRATIO,PINS,PINHITS,PINHITRATIO from v$librarycache;
NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITS PINHITRATIO
RELOADS
--------------- ---------- ---------- ----------- ---------- ---------- ----------- ---------
SQL AREA 2681757300 2466988687 .91991497 2526130229 636861692 .252109604
145268976