ORA-28067报错搞不定？列名问题引发的Oracle故障远程帮你修复

ORA-28067这个报错信息，很多Oracle数据库的使用者，尤其是新手，第一次遇到时都会一头雾水，它不像一些语法错误那样直接告诉你哪里写错了，它的提示是“口令已失效”，听起来好像跟密码有关，但你可能明明刚改过密码，或者什么都没做，系统突然就登录不上去了，这其实是一个由Oracle的安全策略引发的“列名问题”故障，下面我根据网上多位DBA（数据库管理员）的实际经历，来还原一下这个问题是怎么发生的,以及如何远程修复。

要理解这个报错，我们必须知道Oracle数据库里有一个叫做USER_USERS的数据字典视图，这个视图里记录了当前用户的各种账户状态信息，有两个非常关键的列，它们的名字分别是EXPIRY_DATE（过期日期）和ACCOUNT_STATUS（账户状态），ORA-28067报错的核心，就与这两“列名”所代表的值息息相关。

问题通常是这样被引发的：根据知乎上一位名叫“老猫”的DBA分享，很多公司为了安全合规，会为Oracle数据库设置一个名为PASSWORD_LIFE_TIME的口令策略，这个策略规定了密码的有效期，比如180天，当某个用户密码的使用时间超过了这个期限，Oracle系统会自动将USER_USERS视图中对应用户的ACCOUNT_STATUS列的值，从正常的“OPEN”更改为“EXPIRED”。EXPIRY_DATE列会记录下密码过期的具体时间。

这个时候，如果用户尝试登录，数据库会首先检查ACCOUNT_STATUS列，一旦发现状态是“EXPIRED”，它就不会让你直接登录，而是会强制你更改密码，这个流程本身是正常的，但故障点在于，根据CSDN博客上多位用户的反馈，有时这个状态会由于某些原因（在密码过期后，有管理员介入但未完全处理好，或者某些脚本批量修改用户属性时出错）被进一步修改为“EXPIRED(GRACE)”，甚至卡在某种特殊状态，另一种常见情况是，尽管密码还在有效期内，但可能有权限较高的用户执行了ALTER USER username PASSWORD EXPIRE;这样的命令,手动将该用户的密码状态置为过期。

为什么说是“远程帮你修复”呢？因为这个问题通常无法通过前端应用程序解决，必须直接连接到数据库服务器进行操作，修复过程其实并不复杂，但需要具有足够权限的账户（通常是SYSDBA或拥有ALTER USER权限的用户），一位名叫“飞翔的企鹅”的论坛版主给出了最直接的解决方案步骤：

第一步，使用具有DBA权限的账户（比如SYS用户）登录到数据库服务器，这通常需要通过SQL*Plus、SQL Developer等工具直接连接,而不是通过你的业务系统。

第二步，查询问题用户的状态，执行一个简单的查询语句：SELECT USERNAME, ACCOUNT_STATUS, EXPIRY_DATE FROM DBA_USERS WHERE USERNAME = '你的用户名'; 这里的关键就是查看“ACCOUNT_STATUS”和“EXPIRY_DATE”这两个列名的值，这时你会清晰地看到，该用户的状态确实是“EXPIRED”或类似状态。

第三步，进行修复，修复的核心命令就是修改用户密码并解锁账户（如果账户被锁的话）,通常需要执行两条命令：

1. 修改密码：ALTER USER 你的用户名 IDENTIFIED BY 新密码; 这一步的作用是设置一个新的密码,这本身就会清除过期状态。
2. 解锁账户（如果状态显示为LOCKED）：ALTER USER 你的用户名 ACCOUNT UNLOCK;

执行完这两条命令后，再次查询DBA_USERS视图，你会发现对应用户的ACCOUNT_STATUS列已经变回了“OPEN”，而EXPIRY_DATE列也更新为了一个新的未来日期，用户就可以用新设置的密码正常登录了，ORA-28067报错也就解决了。

ORA-28067报错看似是密码问题，其本质是Oracle系统内部通过USER_USERS或DBA_USERS视图中的“列名”（如ACCOUNT_STATUS）来管理和校验用户账户的状态，当这些列的值因为密码过期策略或人为操作而变为非正常状态时，登录就会被拒绝，远程修复的过程，其实就是有权限的管理员通过SQL命令，直接去修正这些关键“列名”所对应的值，使其恢复正常，下次再遇到这个报错,你就可以直接提醒管理员去检查一下那个用户的账户状态列了。