【Oracle】数据库账号频繁被锁问题解决

文中使用的Oracle版本为11g。

今天在测试环境中遇到了一个问题，如下图：

所有的数据库客户端访问Oracle11g都出现了上面的提示“ORA-28000: the account is locked”，一开始其实并不知道是什么原因引起的问题，到后面才发现是登录错误过多导致的账号被锁定了，下面讲一下解决步骤。

由于测试环境的Oracle11g是docker镜像部署的，因此在客户端都无法登录的情况下（无论default，还是sysdba）只能到服务器的容器内部进行操作。

[root@node206 ~]# docker exec -it b71077dc86f1 bash
[oracle@b71077dc86f1 /]$ su -
Password: 
[root@b71077dc86f1 ~]# source /etc/profile 
[root@b71077dc86f1 ~]# su - oracle
[oracle@b71077dc86f1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mon Nov 21 13:54:36 2022

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> conn / as sysdba
Connected.

进入容器后先切换到root用户并通过source命令使环境变量生效，之后重新切换回oracle用户并通过sqlplus登录sysdba账号。登录之后通过“select username, profile from dba_users”语句获取到所有用户和对应的profile类型，如下所示：

select username, profile from dba_users;

USERNAME                       PROFILE
------------------------------ ------------------------------
MGMT_VIEW                      DEFAULT
SYS                            DEFAULT
SYSTEM                         DEFAULT
DBSNMP                         MONITORING_PROFILE
SYSMAN                         DEFAULT
PAOHE                          DEFAULT
OUTLN                          DEFAULT
FLOWS_FILES                    DEFAULT
MDSYS                          DEFAULT
ORDSYS                         DEFAULT
EXFSYS                         DEFAULT

USERNAME                       PROFILE
------------------------------ ------------------------------
WMSYS                          DEFAULT
APPQOSSYS                      DEFAULT
APEX_030200                    DEFAULT
OWBSYS_AUDIT                   DEFAULT
ORDDATA                        DEFAULT
CTXSYS                         DEFAULT
ANONYMOUS                      DEFAULT
XDB                            DEFAULT
ORDPLUGINS                     DEFAULT
OWBSYS                         DEFAULT
SI_INFORMTN_SCHEMA             DEFAULT

USERNAME                       PROFILE
------------------------------ ------------------------------
OLAPSYS                        DEFAULT
SCOTT                          DEFAULT
ORACLE_OCM                     DEFAULT
XS$NULL                        DEFAULT
BI                             DEFAULT
PM                             DEFAULT
MDDATA                         DEFAULT
IX                             DEFAULT
SH                             DEFAULT
DIP                            DEFAULT
OE                             DEFAULT

USERNAME                       PROFILE
------------------------------ ------------------------------
APEX_PUBLIC_USER               DEFAULT
HR                             DEFAULT
SPATIAL_CSW_ADMIN_USR          DEFAULT
SPATIAL_WFS_ADMIN_USR          DEFAULT

由于PAOHE（当前被锁定的账号）账号对应的profile类型为‘DEFAULT’，因此先查所有profile为‘DEFAULT’的密码生命周期是否收到限制，若密码生命周期是存在时间限制的，那么当前账号被锁定有可能就是因为超出了时间限制引起的。

SQL> select * from dba_profiles s where s.profile='DEFAULT' and resource_name='PASSWORD_LIFE_TIME';

PROFILE    RESOURCE_NAME       RESOURCE   LIMIT
---------- ------------------- --------   ----------
DEFAULT    PASSWORD_LIFE_TIME  PASSWORD   UNLIMITED

从上面的结果来看，账号对应的密码生命周期为无限制（unlimited）。虽然方向错了，但是还是先解锁给团队先用着，不能因为排查问题而耽误了开发进度（毕竟不是生产问题）。

SQL> ALTER USER PAOHE ACCOUNT UNLOCK;

User altered.

之后在网上又查阅了部分资料发现，使用同一账号登录多次失败也是导致账号频繁被锁定的常见原因，因此先以RESOURCE_NAME = 'FAILED_LOGIN_ATTEMPTS'为条件查询一下，看看profile为DEFAULT的登录失败锁定有没有限定次数，如下所示：

SQL> SELECT * FROM DBA_PROFILES WHERE RESOURCE_NAME = 'FAILED_LOGIN_ATTEMPTS';

PROFILE              RESOURCE_NAME          RESOURCE  LIMIT
-------------------- ---------------------- --------  ----------
DEFAULT              FAILED_LOGIN_ATTEMPTS  PASSWORD  10
MONITORING_PROFILE   FAILED_LOGIN_ATTEMPTS  PASSWORD  UNLIMITED

从上面输出可以看出，使用profile为DEFAULT的账号登录失败次数达到10次的情况下，账号将会被锁定。接下来要解决这个问题就好办了，首先先修改限制从限定10次改为无限次（unlimited），如下所示：

SQL> ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;

Profile altered.

之后在服务器层面对入站准则进行了限制并设立白名单。从数据库层面增加了对于访问登录的监听，所有的数据库访问都将记录到listener.log里面。