【案例46】Oracle更换数据库密码后产生Library Cache Lock导致系统卡死

本文主要是介绍【案例46】Oracle更换数据库密码后产生Library Cache Lock导致系统卡死，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

问题现象

WAS环境，服务起不来，改成单机版后能登录，打不开节点。直接卡死。

问题分析

经过顾问反馈，在启动环境时，中间件卡住不动，怀疑数据源不通导致，于是使用checkDB脚本发现desgin数据源用户名密码不对。测试不通过。经过沟通，中午修改过数据库的密码。在sysconfig中修改了原数据源的相关密码未修改desgin数据源密码。经过沟通，顾问修改了oracle数据库的密码。

修改数据源的密码后再次测试数据源。发现测试通过，但是等待很久的时间才会返回结果。

再次启动，发现WAS已经正常启动。无报错。

但是登录系统测试后发现，过一段时间后，系统卡顿严重。再等待的一段时间后直接白屏卡死。

再次使用checkDB脚本排查发现报了一堆监听的错误。

检查was的systemout日志也发现了大量的报错。

经过反馈，之前修改完密码后，有人重新建立过数据库监听，怀疑tnsnames.ora配置错误导致。重新配置了相关文件。

重新启动了监听，发现过一段时间，又变的很卡。查看监听日志暂无异常。

于是生成了awr报告，发现有大量的Library Cache Lock的等待。

并且查看了alert日志发现有大量的TNS超时操作来源于某服务器（非NC应用服务器）

经过排查发现此IP为文件服务器，文件服务器是一个独立的ncchome，怀疑是文件服务器的数据源密码没有修改。一直在连数据库。但交互的密码是错误的。查询相关资料后，怀疑是Oracle的新特性导致的。

在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。

这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试攻击。

但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。

解决方案

--备份参数文件，防止数据库启动异常
--备份路径自己指定，下方Z盘为举例
create pfile='z:\app\orcl.ora' from spfile;--修改event
alter system set EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;--关闭数据库
shutdown immediate--启动数据库
startup