遇到ORA-28007报错时，许多用户的第一反应往往是直接改回原密码——毕竟密码没变，理论上应该能通过验证吧？但现实并非如此：ALTER USER user IDENTIFIED BY "old_password" 会触发密码重用校验，即使原封不动地输入原密码，依然会被拦截。Oracle并不会比对明文字符串是否一致，而是检查新密码的哈希值是否在历史记录中，并且是否处于 PASSWORD_REUSE_TIME 和 PASSWORD_REUSE_MAX 这两个参数的约束范围内。只要密码重用策略被启用，这条路就被彻底封死了。
ORA-28007报错时直接改回原密码行不行？
答案已经非常明确——不行。核心原因在于Oracle的密码重用校验机制：它不会比较明文是否相同，而是判断新密码的哈希值是否出现在历史记录中，并且是否在时间或次数限制范围内。只要profile配置了重用约束，直接改回原密码就必然会报错。
绕过重用限制的三种实操路径
既然直接改明文走不通，就得换个思路。核心原则是避开明文校验逻辑，根据具体场景选择对应方法：
- 知道原密码且只想“重置为相同值”：通过
IDENTIFIED BY VALUES子句直接写入哈希值。首先查询目标用户的哈希：SELECT spare4 FROM user$ WHERE name = 'USER_NAME'，获取类似S:ABC...或T:DEF...的字符串，然后执行ALTER USER user IDENTIFIED BY VALUES 'S:ABC...'。简单来说，就是告诉Oracle：“这个密码就是该哈希值对应的密码，无需检查它是否与历史记录重复。” - 想彻底禁用重用限制：修改profile，将
PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX都设置为UNLIMITED。但需要注意一个常见陷阱：这两个参数必须同时设置为UNLIMITED；如果只修改其中一个，反而会导致密码永远无法重置——Oracle会理解为“时间无限但次数有限”或“次数无限但时间有限”，最终无论如何都无法通过校验。 - 临时绕过（仅限DBA操作）：使用
CREATE USER temp_user IDENTIFIED BY "desired_password"创建一个临时用户，查询其spare4哈希值，然后用这个哈希值去更新目标用户。此方法不依赖profile修改，但需要具备SELECT ANY TABLE权限才能访问user$表。
profile修改后为什么还要执行一次ALTER USER？
很多人在修改完profile后认为问题已解决，但JDBC连接仍然报错。原因在于Oracle对密码有效期和重用策略的生效机制是“惰性”的——只有在实际执行 ALTER USER ... IDENTIFIED BY 时才会刷新内部状态。即使新旧密码完全相同，也必须触发一次显式修改，否则连接层仍会按照旧策略进行校验。因此，修改profile之后，务必手动执行一次密码修改，即使密码本身没有变化。
容易被忽略的兼容性坑
哈希值格式必须与客户端版本匹配。Oracle 12c及更高版本默认使用 T: 开头的新哈希格式，但旧版应用（如11g客户端）只识别 S: 开头的旧格式。如果从 spare4 查询到的是 T: 哈希，而客户端是11g，那么 IDENTIFIED BY VALUES 可能会静默失败，或者在登录时报 ORA-01017 错误。此时需要检查 SQLNET.ALLOWED_LOGON_VERSION_SERVER 参数设置，必要时考虑降级哈希生成方式——例如，通过11g实例导出用户再导入到12c中。
