ALTER USER改密本身不中断现有连接，但新密码生效后旧凭据重连即失败；业务中断主因是应用未更新连接池配置或缓存旧凭据，且需同步处理用户状态（如UNLOCK）及PROFILE策略。
ALTER USER 命令改密码时，为什么用户会突然连不上？
直接执行 ALTER USER username IDENTIFIED BY new_password 本身不会中断已有连接，但新密码生效后，所有使用旧密码的客户端连接在下次重连时就会失败——这常被误认为“改完立刻断连”。真正导致业务中断的是应用未及时更新连接池配置或缓存了旧凭据。
- 普通用户只能改自己密码，需用当前密码登录后执行；管理员（如
SYS、SYSTEM）可直接改任意用户密码，无需原密码 - 若目标用户被分配了非默认
PROFILE（比如设置了PASSWORD_LIFE_TIME或FAILED_LOGIN_ATTEMPTS），改密后若未同步调整 profile，可能触发锁定或过期（如状态变为EXPIRED(GRACE)或LOCKED(TIMED)） - Oracle 12c 及以后版本，
dba_users.password字段已不可见，无法通过查哈希回滚；改密前如需留痕，应记录操作时间、用户、旧密码策略项（用SELECT profile FROM dba_users WHERE username = 'XXX'查）
忘记 SYS 密码时，OS 认证登录为什么有时会失败？
依赖 OS 认证（sqlplus / as sysdba）的前提是：数据库实例正在运行，且 Oracle 软件安装用户（如 oracle）属于 dba 操作系统组。一旦 REMOTE_LOGIN_PASSWORDFILE 参数设为 NONE 或 SHARED，远程 SYSDBA 登录会被拒绝，本地 OS 认证仍可用；但如果数据库已关闭，且未启用 ORAPWD 文件或该文件损坏，就只能靠启动到 MOUNT 状态再 open 来救急。
- 检查当前参数：
SHOW PARAMETER remote_login_passwordfile，必须为EXCLUSIVE才支持密码文件写入 - 确认 OS 用户组：
id命令输出中必须含dba组，否则/ as sysdba会报ORA-01031: insufficient privileges - 若数据库已 shutdown immediate，先用
startup mount启动，再alter database open，否则ALTER USER sys IDENTIFIED BY ...会报错
批量改密脚本里最容易忽略的三个细节
运维常用 SELECT 'ALTER USER ' || username || ' IDENTIFIED BY newpass123;' FROM dba_users WHERE ... 生成语句，但实际执行时容易漏掉权限、字符集和锁定状态校验。
- 脚本生成的语句不含分号结尾？SQL*Plus 默认不自动加分号，复制粘贴时若末尾没换行，最后一句可能被截断
- 密码含特殊字符（如
@、$、空格）必须用双引号包裹：ALTER USER scott IDENTIFIED BY "P@ssw0rd!";，否则解析失败 - 执行前务必检查用户状态：
SELECT username, account_status FROM dba_users WHERE username IN ('U1','U2');，状态为LOCKED或EXPIRED & LOCKED的用户，仅改密不够，还得配套ALTER USER xxx ACCOUNT UNLOCK
改完密码后，应用连不上怎么办？
不是密码错了，大概率是连接池没刷新。Oracle 数据库层无感知，问题全在中间件或客户端。
- Tomcat/JDBC 连接池（如 DBCP、HikariCP）需重启或手动触发连接重建；部分支持
testOnBorrow=true+validationQuery=SELECT 1 FROM DUAL自动踢掉失效连接 - PL/SQL Developer、SQL Developer 等工具会缓存登录信息，改密后需清除“保存的密码”或重新输入
- 若用 TNSNAMES.ORA 配置连接，确认其中
CONNECT_DATA下没硬编码密码（极不推荐），应改用外部密码文件或 wallet
真正麻烦的从来不是改密码这一步，而是改完之后谁在用这个账号、用在哪、怎么连、连多久——这些信息不在数据库里，得靠你提前理清楚。
