不能靠“查密码”来轮换，必须用 ALTER USER 执行显式重置；Oracle 19c 及以后版本中 dba_users.password 字段已无实际密码语义，返回 null 或占位符，安全轮换唯一合法路径是高权限账号执行 ALTER USER ... IDENTIFIED BY。
直接结论：不能靠“查密码”来轮换，必须用 ALTER USER 执行显式重置
Oracle 19c 及以后版本中，dba_users.password 字段已无实际密码语义，返回 null 或占位符（如 's:...'），任何试图从数据库表里“读出旧密码再设新密码”的做法都不可行，也不合规。安全轮换的唯一合法路径是：用已有高权限账号（如 SYS 或具备 ALTER ANY USER 权限的账号）执行 ALTER USER ... IDENTIFIED BY。
ALTER USER 语法与关键参数控制
轮换本质是原子性替换，但细节决定是否引入风险：
-
ALTER USER app_user IDENTIFIED BY 'NewPass@2026' REPLACE 'OldPass@2025';—— 仅当用户启用了密码复杂度校验（password_verify_function）且设置了SEC_CASE_SENSITIVE_LOGON=TRUE时，REPLACE子句才被接受；否则报错ORA-01031: insufficient privileges - 若目标用户属于
COMMON USER（CDB 环境），需在CDB$ROOT容器中执行该语句，否则修改仅作用于当前 PDB - 避免使用
IDENTIFIED EXTERNALLY或IDENTIFIED GLOBALLY方式切换——这会绕过口令策略，且无法与应用连接池的密码缓存同步 - 若应用使用 Oracle Wallet，轮换数据库密码后，必须同步更新 wallet 中凭证：
mkstore -wrl /path/to/wallet -createCredential db_alias new_user new_password
轮换过程中的连接中断与应用适配要点
密码变更瞬间，所有持旧密码的活跃连接不受影响，但新连接将立即拒绝认证。常见踩坑点：
- 连接池未配置自动重连或密码刷新机制（如 HikariCP 的
connection-test-query不足以触发重认证）→ 应用启动后首次查询失败 - 中间件（如 WebLogic、Tomcat）JDBC URL 含明文密码 → 必须同步更新
password参数，并重启数据源，否则持续报ORA-01017: invalid username/password - 批处理脚本或运维工具硬编码密码 → 建议改用 Oracle Wallet 或外部密钥管理服务（如 HashiCorp Vault），避免代码/配置中暴露凭证
- 未验证密码策略兼容性：新密码若违反
FAILED_LOGIN_ATTEMPTS或PASSWORD_LOCK_TIME设置，可能导致账户被锁 —— 可先用SELECT * FROM dba_profiles WHERE profile = 'DEFAULT';查看当前限制
自动化轮换的边界与风险提示
虽可用 PL/SQL 脚本批量执行 ALTER USER，但以下情形必须人工介入：
- 涉及
SYS、SYSTEM或 DBA 角色持有者：禁止脚本化轮换，必须走变更流程并双人复核 - 密码文件（
orapw$ORACLE_SID）中存储的SYS密码 ≠ 数据库内SYS用户密码，二者独立维护；轮换数据库用户密码不影响 OS 认证登录能力 - GoldenGate、OGG 或 Data Guard 备库的监控账号密码必须与主库严格一致，否则复制进程报
ORA-12170: TNS:Connect timeout类错误，而非明确的认证失败 - 审计要求留存操作痕迹：确保
UNIFIED AUDITING已启用，并检查AUDIT POLICY ORA_DATABASE_PARAMETER是否覆盖了ALTER USER操作
真正难的不是执行命令，而是确认所有依赖路径——从连接池、中间件、脚本到灾备链路——是否同步完成更新。漏掉任意一环，都会让“安全轮换”变成生产事故的导火索。
