oracle占用大量cache,案例:Oracle等待事件library cache latch故障优化处理总结 CPU占用100%...

天萃荷净

生产数据库服务器CPU使用率100%，PS查看进程LOCAL=NO存在几百。library cache latch事件故障优化总结

1.分析产生library cache latch的原因

The library cache latches protect the cached SQL statements and objects' definitions held

in the library cache within the shared pool. The library cache latch must be acquired

in order to add a new statement to the library cache. During a parse, Oracle searches

the library cache for a matching statement. If one is not found, then Oracle will parse

the SQL statement, obtain the library cache latch and insert the new SQL.

每一个sql被执行之前，先要到library cache中根据hash_value查找parent cursor,这就需要先获得library cache latch；找到parent cursor后，就会去查找对应的child cursor,当发现无法找到时，就会释放library cache latch，获得share pool latch分配空间给硬解析后的产生的执行计划；然后再次获得library cache latch进行把执行计划放入share pool,转入library cache pin+lock(null模式)开始执行sql.library cache latch 的个数有限(与CPU_COUNT参数相关)，当数据库中出现大量硬解析的时候，某一个sql无法得到library cache latch就会开始spin,达到spin count后还没得到，就会开始sleep,达到sleep时间后,醒来还再次试图过的library cache latch得不到就在spin再得不到又sleep…依此类推.

综上可知:在sql执行的过程中可以看出在出现High Versions Count和Hard Parse的情况下都有可能出现library cache latch等待.

关于Hard Parse见:shared pool latch 等待事件

关于High Versions Count见:关于High Versions Count总结

2._KGL_LATCH_COUNT控制library cache latches数量

The hidden parameter _KGL_LATCH_COUNT controls the number of library cache latches.

The default value should be adequate, but if contention for the library cache latch cannot be resolved,

it one may consider increasing this value. The default value for _KGL_LATCH_COUNT is the next prime number

after CPU_COUNT. This value cannot exceed 67.

3.Library cache: mutex X

在10g及其以后版本中,很多latch使用mutex代替,我们常见的Library cache: mutex X is similar to library cache wait in earlier version.(_kks_use_mutex_pin=false可以禁止mutex)

4.library cache latch案例处理过程

Sun 5.1 的系统，DB 11.2.0.2.  登陆的过程是个苦逼的过程，登陆30多秒才登陆成功，不用查看就知道CPU 肯定100%了。

Oracle@h25k06dc$vmstat 5 5

kthr      memory            page            disk          faults      cpu

r b w  swap free  re  mf pi pofr de sr m5 m6 m7 m1  in  sycs us sy id

0 0 0120080864 63113000 122 721 266 175 174 0 0 5 24 0 5 1590 7847 3308 9 1 90

308 0 0117751600 66781304 194 616 0 9 9 0 0 3 0 1 3 2444 81080 46681 97 3 0

305 0 0117752440 66782280 160 556 0 6 6 0 0 5 0 0 4 2430 84445 40509 97 3 0

310 0 0117751872 66780480 165 718 0 2 2 0 0 3 0 0 3 2399 74438 42603 97 3 0

307 0 0117752296 66782264 77 344 0 3 2 0 0 3 0 0  3 2319 82768 42063 97 3 0

第一列300+的数字很显眼，一般几十就很紧张了。不过还见过600多的，也就没什么大惊小怪，按步骤来，看等待事件：

select event,count(*) fromv$session group by event;

命令敲下去，几分钟都没反应，不过不能继续等下去，新开了一个窗口，准备做个hanganalyze，杯具的同样没反应。

等了一会，还是没反应，这种事情遇到多了，也不那么慌了，期间还接了局方的几个电话，挂了电话，继续奋斗，开来只能用最后一招了，kill 进程。

本打算用一条命令搞定的：

ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9

保险期间，先ps了一下：

ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'

返回几百个，有点多，一般来说，如果数据能正常连接和操作，最好先定位出具体的session，在把这个session对应的进程kill 掉就ok了，明显今天早上人品欠佳，定位不出来。

这里LOCAL=NO 的进程太多，不能全部kill 掉，也是没办法，一次kill 部分，看可能缓解一下。

每次随机的kill 一批，kill 到第三批的时候，总算有反应了。

oracle@h25k06dc$vmstat 5 5

kthr      memory            page            disk          faults      cpu

r b w  swap free  re  mf pi pofr de sr m5 m6 m7 m1  in  sycs us sy id

0 0 0 120078656 63119016 122 722 266 176 176 00 5 24 0 5 1597 7899 3333 9 1 90

0 0 0 118483144 67508104 61 1159 0 0 0 0 0 220  0 22 5349 28461 13297 55 4 42

0 0 0 118487648 67513760 38 726 0 0 0 0 0  0 0  0  0 4435 24430 10103 52 4 44

0 0 0 118488136 67514264 36 482 0 0 0 0 0  7 0  0  7 3451 22461 10015 51 3 47

0 0 0 118489392 67515480 58 630 0 0 0 0 0  1  0  0  14087 29228 12237 49 4 47

看了一下时间，处理过程大约花了20分钟，有点长，反应速度还需要提高。迅速创建了一个快照，用来分析故障原因：

这里event 很明显，latch:library cache。

当我们对包，存储过程，函数，视图进行编译的时候，Oracle就会在这些对象的handle上面首先获得一个library cache lock，然后再在这些对象的heap上获得pin，这样就能保证在编译的时候其它进程不会来更改这些对象的定义，或者将对象删除。

当一个session对SQL语句进行硬解析的时候，这个session就必须获得librarycache lock。 这里AWR也比较明显，硬解析过高。

从v$active_session_history视图里抓了latch: library cache 的session 及SQL，有3个SQL 没有使用绑定变量，导致硬解析过高。

SQL提交给运维，继续关注数据库

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之案例:Oracle等待事件library cache latch故障优化处理总结 CPU占用100%