密码问题导致 Library Cache Lock

       中午收到邮件，附件是awr，ash和其他的日志文件，客户反映昨天下午服务器CPU使用率增高，最终导致节点二重启，现在要分析日志得出结论。

通过awr报告可以看到DB Time超高

逻辑读较高

等待事件最多的是Library Cache Lock

时间模型发现异常，connection management call elapsed time代表建立会话的时间。

再往下看，发现有部分SQL语句执行时间较长

下边再结合ASH报告继续分析

排名第一的依然是Library Cache Lock和Connection Management

主要分析Library Cache Lock中P3的值，这里给出的是十进制‘5177346’，转成十六进制‘004f0002’

注释：前四位代表namespace，后四位代表mode

004f转成十进制是79,2代表share

查询视图x$kglob发现79代表accout_status

select distinct KGLHDNSP,KGLHDNSD from x$kglob order by 1;

查询mos发现一篇文章，地址是https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=450389854561179&id=1309738.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=13v67k16je_37

对比当前ash报告完全吻合，OAUTH是用户登录验证的服务

至此，整个过程基本清晰。

是因为ORACLE BUG导致，密码被修改，应用尝试多次失败登录，导致产生大量的Library Cache Lock。

附：如果启用审计，可通过以下语句统计登录失败次数

select username, os_username, userhost, client_id, trunc(timestamp), count(*) failed_logins from dba_audit_trail where returncode = 1017 and timestamp > sysdate - 7 group by username, os_username, userhost, client_id, trunc(timestamp);

以下是Oracle提供的解决方法

以下是Oracle提供的多个关于密码问题导致的bug