ORA-28007触发的直接原因是密码复用，优先受PASSWORD_REUSE_TIME控制；仅当其为UNLIMITED时，PASSWORD_REUSE_MAX才可能生效，但该参数在11gR2+版本中已被弃用（deprecated），实际无效。
ORA-28007 报错时，PASSWORD_REUSE_TIME 和 PASSWORD_REUSE_MAX 哪个起作用？
ORA-28007 触发的直接原因是 Oracle 检查到你试图设置的明文密码，在历史记录中已存在。它优先受 PASSWORD_REUSE_TIME 控制——即该密码在多少天内不允许复用。只有当 PASSWORD_REUSE_TIME 为 UNLIMITED 时，PASSWORD_REUSE_MAX（允许重复使用的最大次数）才可能生效。但注意：PASSWORD_REUSE_MAX 在绝大多数 Oracle 版本（11gR2+）中实际被忽略，官方文档也明确标注为“deprecated”。别白费力气去调这个参数。
修改 Profile 的正确顺序：先查再改，别跳步
直接执行 ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME 0 很容易失败，因为 Oracle 要求你必须同时显式指定 PASSWORD_REUSE_MAX（哪怕只是设为 UNLIMITED）。常见错误是只改一个参数，导致语法报错 ORA-02379: profile already has a limit for this resource。
- 先确认当前配置：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name IN ('PASSWORD_REUSE_TIME', 'PASSWORD_REUSE_MAX'); - 一次性同时修改两个参数：
ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED; - 注意：修改立即生效，无需重启数据库，但对已存在的密码历史记录不清理——旧密码仍被记着，只是不再触发时间限制检查
想彻底清空密码历史？USER$ 表操作风险极高
Oracle 把密码哈希和历史记录存在系统表 USER$ 的 SPARE4 和 ASTXT$ 列里。理论上清空这些字段能绕过所有复用检查，但这是严重越界操作：
-
UPDATE USER$ SET SPARE4 = NULL, ASTXT$ = NULL WHERE name = 'YOUR_USER';必须以SYS身份执行，且数据库需处于MOUNT状态（即停库） - Oracle 不支持、不保证该操作的兼容性；19c+ 版本中
ASTXT$已加密，直接置空会导致用户无法登录 - DBA 审计日志会完整记录该操作，生产环境基本等于自曝高危行为
真正安全又实用的替代方案：用哈希值重设密码
如果你必须复用旧密码（比如测试脚本写死），最稳妥的方式不是删历史，而是跳过明文校验——直接注入哈希值。前提是：你知道该用户当前有效的哈希值（通常从 DBA_USERS 或备份日志里获取）。
- 格式必须严格：
ALTER USER username IDENTIFIED BY VALUES 'S:xxx;T:yyy';，其中S:是旧版哈希，T:是 11g+ 的新哈希，两者缺一不可 - 哈希值不能手算，必须从合法渠道提取；伪造或拼接错误会导致用户永久锁死
- 该操作不触发任何密码策略检查，包括
PASSWORD_REUSE_TIME，也不写入新历史记录
真正麻烦的从来不是改参数，而是搞清哪条路径不会让下次改密码时突然连不上——尤其当多个应用共享同一个账号时，哈希复用看似取巧，实则是唯一不破坏现有连接链路的解法。
