这个一个普通的周四，和往日一样，到公司，开电脑，收邮件。 还没几分钟，收到一条手机告警短信，看了一下，放那没管了，一天能收到上百条的告警信息，麻木掉了，过了几分钟，又收到一条相同库的报警，还是看了一眼，不过此时心里已经提高警惕了，第三次收到报警，知道这个库肯定出问题了，迅速连内网。

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

第一列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 到第三批的时候，总算有反应了。

看了一下时间，处理过程大约花了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 没有使用绑定变量，导致硬解析过高。

&nbs