一次library cache lock 问题分析

一 说明

背景说明

台州工商行政管理局新上 RAC 数据库，在 2015 年开始，不定期出现应用程序连接不上数据库实例的故障，故障发生时间大多在下午 15:30-18:00 之间，数据库发生故障期的间业务具体现象为应用程序连接数据库出现长时间挂起现象，此时 RAC 数据库实例与监听均正常，只有重新启动数据库后应用程序方可连接数据库。  

故障初步分析

目前由于 WR 报告只能保留 7 天时间 , 最近的一次故障发生时间是 2015 年 5 月 12 日，已经超出了日志的最大保留时间， 同时我们检查数据库的告警日志，发现故障时间点的告警日志已经被人为的删除，从而使得故障的判断更加困难。不过所幸我们在 /tmp 目录下找到了故障发生时间点的 AWR 报告，应该是上蔟故障解决时遗留下来的报告。下面我们针对给出的故障时间点的 AWR 报告，进行分析并得出初步结论。 

故障详解

检查故障时间点的 CPU 繁忙程度，通过 DB Time 和 Elapsed Time 比对我们可以发现：

故障时间点：

可以看到，在60 分钟的物理时间中，DB 运行超过4000 分钟，CPU 已经被100% 消耗。

而在正常的时间节点中，同样的CPU 基本空闲在90% 以上。

正常业务中周期：

而在故障时间点的Top 10 等待事件中：

排第一位的即为 library cache lock ，一般来说，发生 library cache lock 一般是由于存储过程在运行中被编译，或者大量的 DDL 操作等等，不过我们检查了相关的 AWR 故障点的报告，没有发现可疑的 SQL 。不过在故障点的 Top 时间模型中，我们发现如下信息：

可以看到，故障时间99% 的CPU 都消耗在connection management call elapsed time 上面，也就是说，故障点的时候99% 的CPU 都消耗在连接上面，并且我们检查发现，在故障点发生的SQL ，和正常时间点发生的SQL ，存在很大的差别。

故障点的 SQL ：

正常时间节点的 SQL ：

由于资料有限，我们只能分析到这里，不过结合以上信息，我们也能够大致分析出导致 library cache lock 的原因。

根据 MOS 文档：

High "Library Cache Locks" Wait Time Due to Invalid Login Attempts ( 文档 ID 1309738.1) 由于台州工商局核心系统，原则上不应该有这么大的连接压力，我们根据 AWR 报告的信息分析，在故障发生的时候，应该是某些应用的连接出现密码错误问题，导致密码延迟登录特性被触发，从而命中 BUG ：

Bug 19867671 : LIBRARY CACHE LOCK CAUSED BY WRONG PASSWORD LOGIN 该 BUG 触发版本： 11.2.0.3 正好命中台州工商的数据库版本。并且由于客户的数据库错误密码登录失败次数从 10 次调整到 unlimited ： 使得问题不可能被重现。

总结

通过以上的分析对比，我们得出如下的结论：

1.        导致系统hang 住的原因是由于Library Cache Locks ，结合该时间段的AWR ，没有发现可疑的SQL ，而在故障时间段，基本的资源都消耗在会话连接上，所以我们还是判断数据库在会话连接层面出现问题，根据Bug 19867671 可知，在出现错误密码的时候，由于密码延迟登录的新特性，会导致大量的密码错误登录，并且，比对故障时间点的SQL 和正常时间点的SQL ，我们发现，两者的SQL 也不太一致，很有可能是不同的业务模块在weblogic 上由于密码的错误问题，导致该模块触发该BUG 。

建议：建议根据故障触发的时间段，结合故障时从2015 年开始触发的，确认该时间段调用的业务模块是什么，相应的中间件有哪些，通过对以上的中间件检查密码情况。 

2.        调整密码登录失败的参数，无论是从安全角度考虑还是从排查问题角度考虑，我们都建议客户将DEFAULT   FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED 重新设置为10 次。

3.        对应的系统日志及数据库日志不要随意的删除，方便后续的问题查看，本次在检查问题的时候发现，数据库的告警日志已经被清理，从问题的排查角度上看，对于故障时间节点的日志，我们建议客户保留，方便后续的问题排查。