ORA-28001报错需先诊断再处置：普通用户须用DBA权限执行ALTER USER重置密码并调整PROFILE中PASSWORD_LIFE_TIME；Grid用户不可用ALTER USER，须在各RAC节点停ASM、用orapwd重建含sysasm=y的密码文件后重启ASM。
ORA-28001报错时，先别急着改密码
ORA-28001不是连接失败的通用错误，而是明确告诉你“密码已过期”，但直接执行 ALTER USER username IDENTIFIED BY newpass 往往无效——尤其当用户被锁定（ACCOUNT_STATUS = 'LOCKED'）或使用了非默认 profile 时。更关键的是：有些用户（比如 grid）根本不能走这条路径，会报 ORA-01918: user 'grid' does not exist。
真正该做的，是先确认两点：
- 当前用户是否在
dba_users中存在且状态为EXPIRED或EXPIRED(GRACE) - 该用户的
profile是什么？是否继承了PASSWORD_LIFE_TIME限制？
用这条语句一次性查清：
SELECT username, account_status, expiry_date, profile FROM dba_users WHERE account_status LIKE '%EXPIRED%';
普通数据库用户：改密码 + 调策略两步必须都做
只改密码，下次还会过期；只调策略，当前连接仍失败。两者缺一不可。
改密码（需 SYSDBA 权限）：ALTER USER app_user IDENTIFIED BY new_secure_pass;
调策略（影响后续所有新密码）：
如果想永久生效（仅限测试/内部系统）：ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;
如果要保留安全策略（推荐生产环境）：ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90;
注意：PASSWORD_LIFE_TIME 修改后立即生效，无需重启实例；但旧密码不会自动续期，必须显式重置。
Grid用户报ORA-28001？别碰ALTER USER
Oracle 19c RAC 中的 grid 用户不是普通数据库用户，它不存于 dba_users，其 sysasm 权限由 ASM 密码文件控制。在任意节点执行 ALTER USER grid ... 都会失败。
正确做法是逐节点操作：
- 停本节点 ASM：
srvctl stop asm -n $(hostname) - 备份原密码文件：
cp $GRID_HOME/dbs/orapw+ASM $GRID_HOME/dbs/orapw+ASM.bak - 重建密码文件（必须含
sysasm=y）：orapwd file=$GRID_HOME/dbs/orapw+ASM password=new_grid_pass entries=10 force=y format=12.2 sysasm=y - 重启 ASM：
srvctl start asm -n $(hostname)
验证：asmcmd -p 能进，再执行 lsdg 不报 ORA-28001 即成功。
JDBC/应用连不上？检查连接字符串和驱动行为
JDBC 报 java.sql.SQLException: ORA-28001 表面是密码问题，但背后可能有陷阱：
- 某些老版本 Oracle JDBC driver（如 ojdbc6）在密码过期时不会抛出明确异常，而是静默失败或卡住
- 连接串里用了
oracle.jdbc.driver.OracleDriver（已废弃），建议换成oracle.jdbc.OracleDriver - 应用配置了连接池（如 HikariCP），需确认是否启用了
connection-test-query或validation-timeout，否则坏连接可能滞留数小时
最简验证法：用相同 URL 和凭据，拿 sqlplus 手动连一次。连得通，说明是应用层缓存或驱动问题；连不通，才是真过期。
真正麻烦的从来不是“怎么改密码”，而是不知道哪个账户、在哪台实例、用哪种认证机制（OS auth / password file / unified directory）在控制权限。尤其是 RAC 环境下，grid 和 oracle 用户的密码文件是各节点独立的，漏掉一个节点，集群就半瘫痪。
