一、故障描述

某次，用户电话紧急反馈，数据库出现连接不上现象，业务已经不可用。在信息同步之后，故障表象是数据库账户被锁（ LOCKED ），导致业务无法登录。因此，处理该问题的手段也是比较简单，第一时间将账户解锁，业务恢复。但是，这里会有一个疑问，业务账户为何突然被锁？需要进一步定位 root   cause 。

二、 根因分析

有经验的同学，应该都清楚，在数据库默认的 Default  P ro file 中，会有一个资源选项 FAILED_LOGIN_ATTEMPTS ，默认值为 1 0 ，表示当数据库账户登录报错命中 1 0 次之后，系统会自动将对应的账户锁住（ L OCKED ）。

带着这个怀疑，我们同时检查数据库故障时间段 A LERT 日志，但是，仅发现大量连接超时的记录，未曾发现 ORA- 01017 报错。通常，业务发起 T CP/IP 连接时，如果是账户名或者密码错误，会命中 O RA-01017 。

显然，在数据库 ALERT 日志中并未发现我们预期的记录，好在用户并没有关闭数据库默认自带的 A UDIT 审计功能，会记录用户登录时的 ret urncode ，如果在 aud $ 基表中故障时间段出现 1 017 错误代码，也能证实是失败登录次数过多导致账户被锁。

但是，通过查询 AUD$ 表中记录，未发现有 1017 错误代码， 3 136 等倒是可以和 A LERT 中的记录对上。

此时，排查一度陷入僵局，既然不是这个原因引起，那是否有可能是被人为锁住（ L OCKED ）呢！因此，我们很快对当前联机 R EDO 日志和归档日志进行挖掘分析，在故障时间段内，发现了大量修改 user$ 表基表的操作，其中 9 6 和 9 7 就是代表被锁的用户 I D 。

确认 96 、 97 用户在 20 点 37 分时被锁定，并且有业务机器修改 sys.user$ 表记录，继续检查发现是业务机器登录 sys 用户修改此表。

同时，通过检查历史会话信息，发现 20 点到 -21 点期间，有许多业务机器使用 sys 用户的登录记录。如下：

三、解决 方案

  整篇分析下来，数据库业务账户被锁（ L OCKED ）的原因大概梳理了 3 种，第一种是失败登录次数过多导致系统自动上锁，这种场景出现的概率较大；第二种，业务出于某种需要、误操作或者主观恶意的人为上锁；第三种，比较少见，直接修改数据库系统基表 sys .user$ ，这种操作是极其不推荐的。本次分享的案例，我们发现业务机器大量使用登录 sys 账户登录数据库，这种操作是极其不安全的，也可能是导致出现这次事故的主要原因。