一次oracle 中用户被锁的排查过程

早上过来，一客户工作人员反映有个库中的用户被锁掉，让我排查下原因。

当时直接反应就是用户密码错误，尝试次数过多导致用户被锁。

客户给我生成了listener.log，

我在库上查看用户被锁时间：

select username,lock_date from dba_users where username='xxx'; 

发现被锁用户的时间信息已经不存在，原因是用户已经被客户解锁，所以视图dba_users中已经看不到用户被锁时间的信息。

这个时候通过查看表user$来解决这个问题：

select name,ltime from user$ where name ='XXXX';

查看ltime的具体时间点后，在listener.log这个监听日志中定位当时是哪个程序连接，和业务人员确认是一个晚上跑批的定时任务。。。

本以为一切顺利，结果客户一再肯定说密码没有设置错误，也打开了一些配置文件，确认了密码没有错误的问题。

我就惆怅了，难道被SQL注入攻击了，又让安全组那边查了下审计信息，也没有发现异常。

我就一个人一点点的看listener.log，发现每天时间点都有那个跑批程序出现，user$中显示4月3号2点10分01秒锁的账户，但昨天才解锁，那么这未解锁的几天，按道理讲跑批程序都是应该没有成功的。客户又找来了相关开发人员，一个个排查，原来存在多个跑批程序，上次程序发布的过程中，有个跑批程序密码没有更改。。。。。。

我也是醉了。由于客户一开始很是肯定，认为密码配置没有问题，我也就信了，都要开始考虑是不是踩了某个log方面的bug，比如当时中间件连接oracle存在异常，或者密码延迟之类的，导致账户被锁了。。。。。。。

给自己提了个醒，很多时候我们所肯定的只是我们确实知道的东西，万一有某一方面我们没有涉及到，那么就可能问题出现在该方面。排查问题的过程要全面，从点到面，毫无死角。