Oracle 19c（19.12+）及21c支持密码滚动切换，核心是创建含PASSWORD_ROLLOVER_TIME限制的profile并绑定用户，最小值1/24天（1小时），最大60天；启用后用户处于INROLLOVER状态，新旧密码均可认证，连接池存量会话不受影响。
能，但必须依赖 Oracle 19c（19.12+）或 21c 及以上版本的 PASSWORD_ROLLOVER_TIME 特性；旧版本无原生支持，硬切必然中断。
Oracle 19c/21c 密码滚动切换怎么配
核心是创建带 PASSWORD_ROLLOVER_TIME 限制的 profile，并绑定到目标用户。不是改完密码就完事，得提前配置过渡窗口。
- 用
SYS或具有ALTER PROFILE权限的用户执行：CREATE PROFILE pw_rollover_prof LIMIT PASSWORD_ROLLOVER_TIME 1.5;
- 把 profile 绑给用户：
ALTER USER app_user PROFILE pw_rollover_prof;
-
PASSWORD_ROLLOVER_TIME单位是“天”，最小支持1/24（即 1 小时），最大60；设为0或未启用该 profile 时，该特性不生效 - 确认生效：
SELECT username, profile, account_status FROM dba_users WHERE username = 'APP_USER';
正常应看到OPEN&INROLLOVER状态
改密码后连接池为什么还能连上
不是连接池“自动刷新”了密码，而是 Oracle 在服务端做了兼容：只要用户处于 INROLLOVER 状态，LOGON 阶段会同时校验旧密码和新密码（仅限一次密码变更，不支持多轮滚动）。
- 连接池里的存量连接不受影响——它们用的是已建立的会话，不涉及重新认证
- 新连接请求（比如连接池扩容、连接失效重连）可使用任一密码完成认证
- 注意：该机制只作用于密码验证环节，不改变
DBA_USERS.PASSWORD_CHANGE_DATE，也不影响密码复杂度策略或锁定规则 - 如果应用层配置了连接测试 SQL（如
SELECT 1 FROM DUAL），它仍会走原有连接，完全感知不到密码已变
WebLogic 连接池没热更新能力，怎么办
WebLogic 的 JDBC 数据源默认在启动时读取密码并缓存，运行中无法 reload。但你根本不需要它 reload —— PASSWORD_ROLLOVER_TIME 让它“不用 reload 也能活下来”。
- 不要尝试用 JMX 或控制台动态修改数据源密码字段，这只会让新连接失败（因为数据库还没切）或触发锁库（因为数据库先切了）
- 不要写脚本去 kill 连接池再重建，这等于主动制造连接中断
- 真正要做的只有两步：① 提前配好 rollover profile；② 在窗口期内执行
ALTER USER ... IDENTIFIED BY - 如果 WebLogic 启用了连接泄漏检测或测试查询失败重试，确保失败容忍次数 ≤ 2，避免因短暂认证抖动触发误判
旧版本 Oracle（如 12c、18c）真没招？
没有服务端滚动机制，只能靠架构层兜底，但所有方案都带妥协点：
- 影子账户方案：建一个权限等价、密码长期固定的备用账号（如
APP_USER_SHADOW），应用代码里加 try-catch，主账号连不上就切 shadow；缺点是需改代码、多维护一套凭证、DBA 必须同步解锁 shadow 账户 - 双账号轮转：提前建好
APP_USER_V2，应用配置支持双数据源 fallback，密码切换期同时维护两套账号；缺点是配置复杂、权限同步易漏、连接池资源翻倍 - 临时放宽锁定策略：在改密码窗口期，用
ALTER PROFILE ... LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED临时禁用爆破锁，操作完立刻恢复；风险是削弱安全水位，需严格审批与审计
最常被忽略的一点：无论用哪种方案，DBA_USERS.ACCOUNT_STATUS 字段必须被监控——它比任何应用日志更早暴露锁库风险，建议在密码变更前后 5 分钟内轮询该视图。
