遇到这个错误，一般我们想到的是数据库用户被锁，只需要执行用户解锁即可恢复，但这里之所以写出来是因为比较奇葩的一个问题。
昨天下午接同事信息，说一个用户连接报被锁，经过沟通发现其实连接一个ADG的备库作为只读用户查询数据使用，于是按照他提供的相关数据库服务器信息登录检查，发现账号居然没有被锁定，但通过其账号密码登录尝试确实报ORA-28000: the account is locked，这就比较奇葩了，下面将处理过程做个记录，希望对其他同仁有所借鉴。
一、错误现象
SQL> conn dbuser/dbuser; ERROR: ORA-28000: the account is locked
二、错误原因
用户通过错误密码登录，超出失败登录限制，导致用户被锁。
三、处理过程
1.登录备库，查看数据库用户字典
账号处于open状态，为何用户会被锁呢？登录主库查看发现账户依旧正常，但通过用户名密码登录没有被锁的信息
这就奇怪了，用户没有被锁，主库可以登录，为何备库就显示被锁呢？难道是备库的多次登录失败导致用户被锁，因为备库只读导致数据字典记录不到锁定信息？
经过测试发现确实是在备库通过错误的用户密码登录，会导致备库的账号被锁定，但在字典不会记录账户被锁信息，同时主库可以正常登录。
登录统计
select name,LCOUNT from user$ where name='DBUSER';
2.备库用户解锁
alter user dbuser account unlock;
再次登录，可以登录。但稍等几分钟后重试，依旧提示被锁。
3.尝试重启数据库恢复
重启后用户恢复正常，但等一会后又提示用户被锁定。
4.放大招，更改用户profile，使登录失败无限制
查看用户对应的profile做的密码、登录限制
set line 200;
set pagesize 2000;
col resource_name for a30;
col profile for a18;
col limit for a15;
select a.username,a.profile,b.resource_name,b.limit from dba_users a,dba_profiles b where a.profile=b.profile and b.resource_name='FAILED_LOGIN_ATTEMPTS' and a.username='APP_BG';
更改用户登录限制
SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS UNLIMITED; Profile altered.
5.问题追踪
究竟是哪个IP一直尝试使用不正确的密码登录数据库呢？我们可以通过几种方法去traceroute，可以通过登录审计的方式（由于是备库，所以需要开启系统级别的审计），可以通过tcpdump抓包的形式分析连接数据库的信息。这里做的是数据库审计的方式完成问题追踪，具体方法如下：
1)确定用户状态
select username, ACCOUNT_STATUS ,LOCK_DATE ,expiry_date from dba_users order by lock_date desc ;
2)查看审计信息
show parameter audit;
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string NONE
发现审计未开启
开启数据库审计
alter system set audit_sys_operations=TRUE scope=spfile; --审计管理账户，一般设置false alter system set audit_trail=os,extended scope=spfile; 重启数据库
3)跟踪审计日志
show parameter audit_file_dest
4)分析审计日志连接的用户、IP地址等
若使用的是DB级别的审计，可通过下面的语句查看登录审计信息
SELECT username,TIMESTAMP,os_username,userhost, OS_PROCESS,RETURNCODE FROM sys.dba_audit_session WHERE returncode != 0 AND TIMESTAMP>='2015-12-09 13:25:00' ;
四、附录
1.参考文档
有篇文章说是mos上的一篇说了这个问题是由于主库（经过测试，发现此描述有问题，请忽略）
ORA-28000 On Active Data Guard (文档 ID 1922621.1) In this Document Symptoms Cause Solution References APPLIES TO: Oracle Database - Enterprise Edition - Version 11.2.0.1 and later Information in this document applies to any platform. SYMPTOMS Noticed one user account was locked in primary and its Active Data Guard instances. It was fine Primary Database after unlocking the User, but at the Active Data Guard Standby Database, it was showing ORA-28000 that the account is still locked. Followed Note 1600401.1: ORA-28000 "the account is locked" in the standby database, even after the account was unlocked in the primary but it is still unlocked and user can not connect to standby database. Here is log:
2.数据库审计
Audit_trail：
None：是默认值，不做审计；
DB：将audit trail 记录在数据库的审计相关表中，如aud$，审计的结果只有连接信息；
DB,Extended：这样审计结果里面除了连接信息还包含了当时执行的具体语句；
OS：将audit trail 记录在操作系统文件中，文件名由audit_file_dest参数指定；
xml：10g里新增的。
注：这两个参数是static参数，需要重新启动数据库才能生效。
当开启审计功能后，可在三个级别对数据库进行审计：Statement(语句)、PRivilege（权限）、object（对象）。
（1） 语句审计 AUDIT SELECT TABLE BY username ; AUDIT SESSION BY jeff, lori; （2） 权限审计 AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL; AUDIT DELETE ANY TABLE; AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL; （3） 对象审计 AUDIT DELETE ON jeff.emp; AUDIT SELECT, INSERT, DELETE ON jward.dept BY ACCESS WHENEVER SUCCESSFUL; （4） 取消审计 NOAUDIT session; NOAUDIT session BY jeff, lori; NOAUDIT DELETE ANY TABLE; NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE,EXECUTE PROCEDURE; NOAUDIT ALL; -- 取消所有statement审计 NOAUDIT ALL PRIVILEGES; -- 取消所有权限审计 NOAUDIT ALL ON DEFAULT; -- 取消所有对象审计 （5） 清除审计 DELETE FROM SYS.AUD$; DELETE FROM SYS.AUD$ WHERE obj$name='EMP'; （6） 审计视图 USER_AUDIT_STATEMENT -- 语句审计 USER_AUDIT_SESSION -- session审计 USER_AUDIT_OBJECT -- 审计对象列表 USER_AUDIT_TRAIL -- 审计记录 （7） 将审计结果表从system表空间里移动到别的表空间上 实际上sys.aud$表上包含了两个lob字段，并不是简单的move table就可以。 下面是具体的过程: alter table sys.aud$ move tablespace users; alter table sys.aud$ move lob(sqlbind) store as( tablespace USERS); alter table sys.aud$ move lob(SQLTEXT) store as( tablespace USERS); alter index sys.I_AUD1 rebuild tablespace u ;