典型案例：Bug 9776608-多个用户使用错误密码登录同一个用户而造成的用户无法登录异常

墨墨导读：在Oracle 11g中，大量的登录失败可能会导致library cache lock；或者大量的使用同一用户登录且登录失败，导致用户登录hang的问题，本文记录整个分析、处理过程。

一、前言

今天下午，某客户进行求助，说是数据库的一个用户(假设为wx)无法正常登录，但是奇怪的是其他用户登录正常。

二、问题处理过程及分析方法

通过远程，sqlplus / as sysdba对数据库进行登录，并进行检查，数据库运行正常，且数据库中没有异常的等待事件；
根据客户描述，通过wx用户和客户提供的密码进行登录，发现登录出现hang住的情况，重新打开另外一个数据库窗口，并对当前的阻塞进行排查：
select sid,seq#, BLOCKING_SESSIO,event,wait_class from v$session_wait;
并未发现阻塞。
于是对登录过程进行hanganalyze分析：
sqlplus / as sysdbaoradebug hanganalyze 3
connect wx/wx123
exit;
通过生成的hanganalyze文件，可以发现此时进行登录的进程，被其他用户登录的动作hang住，且此时等待均为library cache lock。

三、定位问题：

由于其他进程均为登录动作，且等待事件为library cache lock，于是对数据库版本进行查询，发现数据库版本为11.2.0.3。

此时，则想到了11g中的一个bug，即：大量的无效登录，可能会导致大量的library cache lock等待事件，造成数据库异常。于是通过mos进行搜索。最终发现，oracle11g中存在一个bug：9776608；该bug描述，多个用户使用错误密码同时登录一个用户的时候，会造成该用户登录异常。为了确认是否存在该异常，于是对登录失败的设备和次数进行统计：

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

可以发现从当天起，有大量的主机通过wx用户登录失败，于是询问客户，最近是否修改密码，根据客户的恢复，数据库在当天出现密码过期的情况，然后对数据库中该用户的密码进行修改，且修改的密码为新的密码，与之前不同。

因此，基本可以确认问题是由bug 9776608造成。

四、问题解决：

该问题解决有3个办法：
1. 安装补丁Patch:9776608
2. 要求所有使用该用户的应用、程序、客户端修改密码；
3. 关闭密码延迟功能。
这里打补丁浪费时间且不太现实，要求客户端修改密码，由于范围较大，所以也比较困难；而修改服务端的密码，则也会由于应用一直登录导致无法修改；
所以我们选择了关闭密码延迟功能，启用28401事件，具体方法如下：
alter system set event =“28401 TRACE NAME CONTEXT FOREVER, LEVEL 1” scope=spfile;
重启数据库：
shutdown immediate；startup
数据库启动成功后，问题解决。
作者

王鑫，近7年数据库服务经验，目前就职于云和恩墨西区交付团队，擅长Oracle、PostgreSQL数据库的迁移运维等工作，具有11g OCP、11g OCM、PGCA、PGCE等数据库认证。

先后为国家电网信息通信公司、成都人社局、四川电信进行Oracle、PostgreSQL、主机等驻场运维服务，参与成飞、甘肃电信、四川国土资源厅、成都房管局等大型oracle数据迁移项目。

墨天轮原文链接：https://www.modb.pro/db/45408（复制到浏览器中打开或者点击“阅读原文”立即查看）

赞 (0)

相关推荐