写这个系列之前几篇的时候总有读者私信问APEX环境半夜挂了ORDS日志里一堆看不懂的报错到底怎么快速定位这次就用第8篇聊聊一个我见过太多次的经典故障——ORDS连库报错574背后十有八九是数据库账号密码过期也就是ORA-28001/ORA-28002那一家子。今天不仅讲怎么救火还要把“根治”的思路完整交代清楚让你下次再遇到十分钟内解决而不是折腾到天亮。1. 574报错的真面目先别急着重启1.1 从一次深夜故障说起我先描述一个很典型的现场。某生产环境的APEX应用突然全部打不开浏览器端要么直接报错要么卡在登录页面转圈。运维第一时间重启了ORDS页面短暂恢复了几分钟然后又挂。再看日志里面反复出现类似这样的内容java.sql.SQLException: ORA-28001: the password has expired [ERROR] ... ORDS 574: Failed to establish connection ...说实话第一次见到574这个编号我也觉得是什么高深的中间件内部错误查了半天文档。后来发现问题根本不在ORDS而在它背后的数据库账号。一个APEX_PUBLIC_USER的密码过了有效期数据库不让它登录ORDS自然连不上库APEX应用全军覆没。1.2 574和ORA-28001/ORA-28002是什么关系574本身并不是Oracle数据库的标准错误码你可以把它理解为ORDS在建立或刷新数据库连接池时把底层认证异常重新包装后对外暴露的一个标识。真正致命的是和它一起出现的ORA-28001the password has expired翻译过来就是“密码已过期拒绝登录”。和它关系密切的还有ORA-28002the password will expire within N days意思是“密码将在N天后过期”。如果你在日志里看到28002说明账号还能登录但已经进入“风烛残年”状态离硬性拒绝只剩几天。为什么会出现这种情况根源在于Oracle从11g开始默认的DEFAULT Profile把口令有效期PASSWORD_LIFE_TIME设成了180天。APEX_PUBLIC_USER这类常年不换密码的内部服务账号只要没人定期处理到期必然出事。所以这类故障有个特别讽刺的规律几乎每半年准时来一次不少团队把它当成了“玄学”。1.3 为什么重启ORDS治不了本很多人第一反应是重启中间件我理解毕竟报错出现在ORDS日志里。但重启ORDS只是把连接池里的旧连接清掉下一次连接池重新填充时还是要用那个已经过期的账号去连数据库结果还是一样拒绝。更麻烦的是有些环境里ORDS连接池是懒加载的重启之后短时间内没人访问看起来“恢复”了等流量一上来报错立刻重现。所以你会看到“重启一下好了几分钟然后又挂了”的诡异现象。正确顺序永远是先查数据库账号状态确认是不是密码过期再决定要不要动中间件。方向错了折腾多久都是白费。2. 三步定位到底是谁的密码过期了2.1 第一步全库扫一遍过期账号不管日志里说什么先到数据库里把过期账号捞出来。用DBA权限执行这条SQL最直接SELECT username, account_status, TO_CHAR(expiry_date, YYYY-MM-DD HH24:MI:SS) AS expiry_time, profile FROM dba_users WHERE account_status LIKE EXPIRED% ORDER BY account_status;如果APEX是装在PDB里的19c以后常见记得先切到对应容器再查ALTER SESSION SET CONTAINER 你的PDB名; SELECT username, account_status, expiry_date, profile FROM dba_users WHERE account_status LIKE EXPIRED%;要是你不想一个个容器切也可以用cdb_users跨容器看SELECT con_id, username, account_status, expiry_date, profile FROM cdb_users WHERE account_status LIKE EXPIRED%;看到account_status为EXPIRED或EXPIRED(GRACE)的账号基本就是凶手了。EXPIRED(GRACE)说明账号已经过了180天硬期限但还在7天宽限期里能登录但每次连接都会报警告一旦宽限期结束就是彻底的EXPIRED连接直接被拒。2.2 第二步锁定APEX/ORDS相关的账号清单扫出来一堆过期账号时按优先级排查。下面这张表是我在实际环境里整理的重点对象数据库账号在APEX/ORDS架构里的作用过期后的典型症状APEX_PUBLIC_USERAPEX引擎的公共连接账号所有页面渲染都依赖它整个APEX实例瘫痪日志出现574/ORA-28001APEX_REST_PUBLIC_USERRESTful Services匿名调用账号REST接口报503或认证失败APEX_LISTENER部分版本和组件使用需一并排查相关组件功能异常ORDS元数据账号ORDS自身连接数据库的账号安装时自定义命名ORDS启动失败连库阶段直接报错APEX_INSTANCE_ADMIN_USERAPEX管理员内部账号管理页面登录异常工作区解析Schema应用中SQL语句的执行身份SQL Workshop、数据导出、部分REST模块踩雷这里要特别强调APEX_PUBLIC_USER它就是整个链路里的“命门”。我处理过的574故障里九成以上都是它过期。剩下的一成是ORDS元数据账号或REST账号过期。所以看到报错先查它别犹豫。2.3 第三步看清CDB/PDB边界如果你在CDB根容器里执行dba_users查询很可能什么都查不到因为APEX_PUBLIC_USER是装在某个PDB里的本地账号必须切到对应容器才能看到。反过来公共账号C##开头只能在根容器或全局视图里操作。很多排查卡在“明明账号存在怎么查不到”这种低级的边界问题上白白浪费时间。实操里我建议先确认APEX装在哪个容器再用一条SQL把那个容器的过期账号查清楚。别在根容器里瞎折腾。3. 一招根治同口令重置与防过期组合拳3.1 核心技巧用原密码重置刷新过期时钟找到过期的账号后最稳的一招不是设置新密码而是用同一个密码再重置一次。对你没看错就是原密码再IDENTIFIED BY一遍ALTER USER APEX_PUBLIC_USER IDENTIFIED BY 原来的密码原样抄回来 ACCOUNT UNLOCK;这招为什么能用因为Oracle在计算密码有效期时参考的是“密码最后被修改的时间”。你执行ALTER USER ... IDENTIFIED BY即使密码值和原来一模一样Oracle也会认为密码刚刚被修改过把expiry_date重新往后算同时账号状态恢复为OPEN。最关键的好处是密码实际没变ORDS连接池里保存的凭据完全不用动也就绕开了最危险的配置同步环节。这是我在生产环境最推荐的救急手段简单、快速、可控。3.2 验证是否真正生效重置完别急着走回到第一步的查询确认状态SELECT username, account_status, TO_CHAR(expiry_date, YYYY-MM-DD HH24:MI:SS) AS expiry_time, profile FROM dba_users WHERE username APEX_PUBLIC_USER;预期结果是account_status为OPENexpiry_date变成了未来某个日期。如果之前已经先改了Profile下一小节内容expiry_date可能直接变成NULL表示“永不过期”那就更彻底了。这里提醒一句密码如果包含小写字母或特殊字符ALTER USER里务必用双引号把密码包起来。不用双引号的话Oracle会把密码统一转成大写等于你真的换了密码这时候ORDS连接池里存的还是旧密码反而会引发二次故障。这个细节我后面还会专门讲。3.3 永久防复发给服务账号挂专属Profile救火只是第一步真正要“根治”得让这类账号不再受180天默认策略约束。我的做法是创建一个专门给服务账号用的Profile只放开密码时限保留其他安全限制CREATE PROFILE APEX_SERVICE_NOEXP LIMIT PASSWORD_LIFE_TIME UNLIMITED PASSWORD_GRACE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1;然后把APEX相关账号逐个挂上去ALTER USER APEX_PUBLIC_USER PROFILE APEX_SERVICE_NOEXP; ALTER USER APEX_REST_PUBLIC_USER PROFILE APEX_SERVICE_NOEXP; -- 其他服务账号按需添加这个Profile的设计是有讲究的PASSWORD_LIFE_TIME和PASSWORD_GRACE_TIME设成UNLIMITED解决过期问题但FAILED_LOGIN_ATTEMPTS和PASSWORD_LOCK_TIME保持默认的10次和1天防止暴力破解把账号锁死。安全性和可用性都要兼顾而不是一禁了之。3.4 只有真的改了新密码才需要动ORDS配置同口令重置能让你完全绕开ORDS配置同步但如果安全策略不允许“用同一个密码重置”非要改成新密码那就必须同步ORDS侧的凭据。ORDS连接池里保存着APEX_PUBLIC_USER等账号的密码数据库里改了中间件这边不跟上结果就是数据库账号明明OPENORDS还是连不上。同步的入口根据ORDS版本和部署方式有差异老版本通常维护在$ORDS_CONFIG目录的global/settings.xml里新版本可以用ords config命令更新对应配置项实在不行重新走一遍ORDS配置向导让它重新录入APEX_PUBLIC_USER密码然后重启ORDS。我的态度很明确能不动密码就不动密码。同口令重置能把风险降到最低这也是为什么我把这招放在“根治”组合拳的第一位。4. 防复发把密码过期变成看得见的告警4.1 一条SQL查未来30天过期账号等故障处理完最该做的是建一个简单的巡检脚本。我给团队用的就是下面这条SQL每周跑一次把未来30天内要过期的账号提前拉出来SELECT username, profile, ROUND(expiry_date - SYSDATE) AS days_left, account_status FROM dba_users WHERE (expiry_date BETWEEN SYSDATE AND SYSDATE 30 OR account_status LIKE EXPIRED%) AND username NOT IN (SYS,SYSTEM) ORDER BY days_left;这个查询的输出很简单但价值极高。看到days_left小于10的账号就有充足时间走变更流程去重置根本不用等到半夜被告警叫醒。4.2 把巡检挂进定时任务或监控平台光有SQL不够还得让它自动跑。最简单的办法是丢进数据库定时任务里或者接上企业的监控平台让脚本只输出“有问题”的行再配合邮件、企业微信之类的通知渠道。对于APEXORDS这种架构我建议把检查频率设成每天一次因为服务账号一旦过期影响是全站级的宁可多跑几次也不要漏。另外Oracle的告警日志里出现ORA-28002也是一个天然的预警信号。别只盯着ORDS日志定期捞一下数据库alert log把这类“即将过期”的提示抓出来比等到574炸了再排查强太多。4.3 运维台账里的两点经验处理完这类问题我建议在环境台账里补两句话一是服务账号必须使用专用Profile禁止落在DEFAULT策略下二是任何服务账号的密码变更都要在变更单里带上ORDS同步检查清单。这两条看着简单但能有效防止同一个坑在不同环境里反复踩——尤其是那种“环境很多、文档很少”的老项目台账就是救命稻草。5. 排坑实录我在现场踩过的几个坑5.1 只解锁不重置等于没修第一次处理这类问题时我犯过一个经典错误只执行了ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK;以为解锁了就完事。结果页面还是打不开。原因很简单ACCOUNT UNLOCK只负责清除LOCKED状态管不了EXPIRED状态——这是两套完全不同的“封禁”机制。密码过期必须通过IDENTIFIED BY重置来解除只解锁是无效操作。5.2 大小写没保留越修越乱还有一次同事执行重置时把密码写在单引号里没带双引号。Oracle按规则把所有字母转成了大写看起来“重置成功”但密码其实已经被改成大写的版本了。ORDS里存的还是大小写混合的原密码两边不一致结果故障范围从“密码过期”变成了“认证失败配置不同步”处理时间直接翻倍。现在我在团队里立了规矩任何含字母大小写或特殊字符的密码ALTER USER一律用双引号包裹。5.3 全局把DEFAULT改成UNLIMITED审计不答应有人图省事直接执行ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;把整个库的口令策略关了。我当时就劝过这么做虽然能一劳永逸解决过期问题但代价是业务账号也失去了强制改密机制审计来了根本交不了差安全评审也会亮红灯。正确做法是只给服务账号建专用Profile业务账号继续用默认策略各管各的。5.4 在CDB根容器里找不到APEX_PUBLIC_USER前面提过这是个特别容易卡住的边界问题。某个现场的DBA在根容器里查了半天说“APEX_PUBLIC_USER这个账号不存在”还怀疑是不是被删了。实际上账号就在APEX所在的PDB里切个容器再查立刻就看到了。所以遇到“查不到”的情况先想一下容器边界别急着下结论。5.5 密码历史策略导致同口令重置失败同口令重置也不是在所有环境里都能直接成功。如果某个账号的Profile设置了PASSWORD_REUSE_TIME或PASSWORD_REUSE_MAX数据库会拒绝重复使用旧密码。碰到这种情况先查一下SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN (PASSWORD_REUSE_TIME,PASSWORD_REUSE_MAX) AND profile APEX_SERVICE_NOEXP;如果确实限制了密码复用要么临时放宽这几个参数后重置要么用新密码并同步ORDS配置。好在我的生产环境里服务账号的专用Profile一般不设复用限制大部分情况下同口令重置都能一次性成功。5.6 常见问题速查表症状疑似原因处理方式全部APEX页面打不开日志有574ORA-28001APEX_PUBLIC_USER过期同口令重置挂专用ProfileORDS启动失败连接时报ORA-28001ORDS元数据账号过期同口令重置挂专用ProfileREST接口报503或认证失败APEX_REST_PUBLIC_USER过期同口令重置个别应用运行时报ORA-28001应用内连接账号过期重置对应数据库账号并同步应用侧凭据密码重置时提示违反复用规则PASSWORD_REUSE_TIME/MAX限制调整Profile参数后再重置页面间歇性恢复又失败连接池懒加载账号过期优先重置账号再重启ORDS处理完574这类故障我最大的感受是很多中间件报错看起来很吓人但根子其实在数据库侧的账号状态。现在我碰到任何ORDS连接异常第一件事永远是查一遍DBA_USERS确认有没有过期的服务账号而不是急着动配置文件。这个习惯帮我省了太多夜间值班时间。如果你也维护着APEXORDS环境建议把这套定位、救火、防复发的流程整理成自己的检查脚本下次哪怕不是你值班也能让接手的人少走弯路。
写这个系列之前几篇的时候总有读者私信问APEX环境半夜挂了ORDS日志里一堆看不懂的报错到底怎么快速定位这次就用第8篇聊聊一个我见过太多次的经典故障——ORDS连库报错574背后十有八九是数据库账号密码过期也就是ORA-28001/ORA-28002那一家子。今天不仅讲怎么救火还要把“根治”的思路完整交代清楚让你下次再遇到十分钟内解决而不是折腾到天亮。1. 574报错的真面目先别急着重启1.1 从一次深夜故障说起我先描述一个很典型的现场。某生产环境的APEX应用突然全部打不开浏览器端要么直接报错要么卡在登录页面转圈。运维第一时间重启了ORDS页面短暂恢复了几分钟然后又挂。再看日志里面反复出现类似这样的内容java.sql.SQLException: ORA-28001: the password has expired [ERROR] ... ORDS 574: Failed to establish connection ...说实话第一次见到574这个编号我也觉得是什么高深的中间件内部错误查了半天文档。后来发现问题根本不在ORDS而在它背后的数据库账号。一个APEX_PUBLIC_USER的密码过了有效期数据库不让它登录ORDS自然连不上库APEX应用全军覆没。1.2 574和ORA-28001/ORA-28002是什么关系574本身并不是Oracle数据库的标准错误码你可以把它理解为ORDS在建立或刷新数据库连接池时把底层认证异常重新包装后对外暴露的一个标识。真正致命的是和它一起出现的ORA-28001the password has expired翻译过来就是“密码已过期拒绝登录”。和它关系密切的还有ORA-28002the password will expire within N days意思是“密码将在N天后过期”。如果你在日志里看到28002说明账号还能登录但已经进入“风烛残年”状态离硬性拒绝只剩几天。为什么会出现这种情况根源在于Oracle从11g开始默认的DEFAULT Profile把口令有效期PASSWORD_LIFE_TIME设成了180天。APEX_PUBLIC_USER这类常年不换密码的内部服务账号只要没人定期处理到期必然出事。所以这类故障有个特别讽刺的规律几乎每半年准时来一次不少团队把它当成了“玄学”。1.3 为什么重启ORDS治不了本很多人第一反应是重启中间件我理解毕竟报错出现在ORDS日志里。但重启ORDS只是把连接池里的旧连接清掉下一次连接池重新填充时还是要用那个已经过期的账号去连数据库结果还是一样拒绝。更麻烦的是有些环境里ORDS连接池是懒加载的重启之后短时间内没人访问看起来“恢复”了等流量一上来报错立刻重现。所以你会看到“重启一下好了几分钟然后又挂了”的诡异现象。正确顺序永远是先查数据库账号状态确认是不是密码过期再决定要不要动中间件。方向错了折腾多久都是白费。2. 三步定位到底是谁的密码过期了2.1 第一步全库扫一遍过期账号不管日志里说什么先到数据库里把过期账号捞出来。用DBA权限执行这条SQL最直接SELECT username, account_status, TO_CHAR(expiry_date, YYYY-MM-DD HH24:MI:SS) AS expiry_time, profile FROM dba_users WHERE account_status LIKE EXPIRED% ORDER BY account_status;如果APEX是装在PDB里的19c以后常见记得先切到对应容器再查ALTER SESSION SET CONTAINER 你的PDB名; SELECT username, account_status, expiry_date, profile FROM dba_users WHERE account_status LIKE EXPIRED%;要是你不想一个个容器切也可以用cdb_users跨容器看SELECT con_id, username, account_status, expiry_date, profile FROM cdb_users WHERE account_status LIKE EXPIRED%;看到account_status为EXPIRED或EXPIRED(GRACE)的账号基本就是凶手了。EXPIRED(GRACE)说明账号已经过了180天硬期限但还在7天宽限期里能登录但每次连接都会报警告一旦宽限期结束就是彻底的EXPIRED连接直接被拒。2.2 第二步锁定APEX/ORDS相关的账号清单扫出来一堆过期账号时按优先级排查。下面这张表是我在实际环境里整理的重点对象数据库账号在APEX/ORDS架构里的作用过期后的典型症状APEX_PUBLIC_USERAPEX引擎的公共连接账号所有页面渲染都依赖它整个APEX实例瘫痪日志出现574/ORA-28001APEX_REST_PUBLIC_USERRESTful Services匿名调用账号REST接口报503或认证失败APEX_LISTENER部分版本和组件使用需一并排查相关组件功能异常ORDS元数据账号ORDS自身连接数据库的账号安装时自定义命名ORDS启动失败连库阶段直接报错APEX_INSTANCE_ADMIN_USERAPEX管理员内部账号管理页面登录异常工作区解析Schema应用中SQL语句的执行身份SQL Workshop、数据导出、部分REST模块踩雷这里要特别强调APEX_PUBLIC_USER它就是整个链路里的“命门”。我处理过的574故障里九成以上都是它过期。剩下的一成是ORDS元数据账号或REST账号过期。所以看到报错先查它别犹豫。2.3 第三步看清CDB/PDB边界如果你在CDB根容器里执行dba_users查询很可能什么都查不到因为APEX_PUBLIC_USER是装在某个PDB里的本地账号必须切到对应容器才能看到。反过来公共账号C##开头只能在根容器或全局视图里操作。很多排查卡在“明明账号存在怎么查不到”这种低级的边界问题上白白浪费时间。实操里我建议先确认APEX装在哪个容器再用一条SQL把那个容器的过期账号查清楚。别在根容器里瞎折腾。3. 一招根治同口令重置与防过期组合拳3.1 核心技巧用原密码重置刷新过期时钟找到过期的账号后最稳的一招不是设置新密码而是用同一个密码再重置一次。对你没看错就是原密码再IDENTIFIED BY一遍ALTER USER APEX_PUBLIC_USER IDENTIFIED BY 原来的密码原样抄回来 ACCOUNT UNLOCK;这招为什么能用因为Oracle在计算密码有效期时参考的是“密码最后被修改的时间”。你执行ALTER USER ... IDENTIFIED BY即使密码值和原来一模一样Oracle也会认为密码刚刚被修改过把expiry_date重新往后算同时账号状态恢复为OPEN。最关键的好处是密码实际没变ORDS连接池里保存的凭据完全不用动也就绕开了最危险的配置同步环节。这是我在生产环境最推荐的救急手段简单、快速、可控。3.2 验证是否真正生效重置完别急着走回到第一步的查询确认状态SELECT username, account_status, TO_CHAR(expiry_date, YYYY-MM-DD HH24:MI:SS) AS expiry_time, profile FROM dba_users WHERE username APEX_PUBLIC_USER;预期结果是account_status为OPENexpiry_date变成了未来某个日期。如果之前已经先改了Profile下一小节内容expiry_date可能直接变成NULL表示“永不过期”那就更彻底了。这里提醒一句密码如果包含小写字母或特殊字符ALTER USER里务必用双引号把密码包起来。不用双引号的话Oracle会把密码统一转成大写等于你真的换了密码这时候ORDS连接池里存的还是旧密码反而会引发二次故障。这个细节我后面还会专门讲。3.3 永久防复发给服务账号挂专属Profile救火只是第一步真正要“根治”得让这类账号不再受180天默认策略约束。我的做法是创建一个专门给服务账号用的Profile只放开密码时限保留其他安全限制CREATE PROFILE APEX_SERVICE_NOEXP LIMIT PASSWORD_LIFE_TIME UNLIMITED PASSWORD_GRACE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1;然后把APEX相关账号逐个挂上去ALTER USER APEX_PUBLIC_USER PROFILE APEX_SERVICE_NOEXP; ALTER USER APEX_REST_PUBLIC_USER PROFILE APEX_SERVICE_NOEXP; -- 其他服务账号按需添加这个Profile的设计是有讲究的PASSWORD_LIFE_TIME和PASSWORD_GRACE_TIME设成UNLIMITED解决过期问题但FAILED_LOGIN_ATTEMPTS和PASSWORD_LOCK_TIME保持默认的10次和1天防止暴力破解把账号锁死。安全性和可用性都要兼顾而不是一禁了之。3.4 只有真的改了新密码才需要动ORDS配置同口令重置能让你完全绕开ORDS配置同步但如果安全策略不允许“用同一个密码重置”非要改成新密码那就必须同步ORDS侧的凭据。ORDS连接池里保存着APEX_PUBLIC_USER等账号的密码数据库里改了中间件这边不跟上结果就是数据库账号明明OPENORDS还是连不上。同步的入口根据ORDS版本和部署方式有差异老版本通常维护在$ORDS_CONFIG目录的global/settings.xml里新版本可以用ords config命令更新对应配置项实在不行重新走一遍ORDS配置向导让它重新录入APEX_PUBLIC_USER密码然后重启ORDS。我的态度很明确能不动密码就不动密码。同口令重置能把风险降到最低这也是为什么我把这招放在“根治”组合拳的第一位。4. 防复发把密码过期变成看得见的告警4.1 一条SQL查未来30天过期账号等故障处理完最该做的是建一个简单的巡检脚本。我给团队用的就是下面这条SQL每周跑一次把未来30天内要过期的账号提前拉出来SELECT username, profile, ROUND(expiry_date - SYSDATE) AS days_left, account_status FROM dba_users WHERE (expiry_date BETWEEN SYSDATE AND SYSDATE 30 OR account_status LIKE EXPIRED%) AND username NOT IN (SYS,SYSTEM) ORDER BY days_left;这个查询的输出很简单但价值极高。看到days_left小于10的账号就有充足时间走变更流程去重置根本不用等到半夜被告警叫醒。4.2 把巡检挂进定时任务或监控平台光有SQL不够还得让它自动跑。最简单的办法是丢进数据库定时任务里或者接上企业的监控平台让脚本只输出“有问题”的行再配合邮件、企业微信之类的通知渠道。对于APEXORDS这种架构我建议把检查频率设成每天一次因为服务账号一旦过期影响是全站级的宁可多跑几次也不要漏。另外Oracle的告警日志里出现ORA-28002也是一个天然的预警信号。别只盯着ORDS日志定期捞一下数据库alert log把这类“即将过期”的提示抓出来比等到574炸了再排查强太多。4.3 运维台账里的两点经验处理完这类问题我建议在环境台账里补两句话一是服务账号必须使用专用Profile禁止落在DEFAULT策略下二是任何服务账号的密码变更都要在变更单里带上ORDS同步检查清单。这两条看着简单但能有效防止同一个坑在不同环境里反复踩——尤其是那种“环境很多、文档很少”的老项目台账就是救命稻草。5. 排坑实录我在现场踩过的几个坑5.1 只解锁不重置等于没修第一次处理这类问题时我犯过一个经典错误只执行了ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK;以为解锁了就完事。结果页面还是打不开。原因很简单ACCOUNT UNLOCK只负责清除LOCKED状态管不了EXPIRED状态——这是两套完全不同的“封禁”机制。密码过期必须通过IDENTIFIED BY重置来解除只解锁是无效操作。5.2 大小写没保留越修越乱还有一次同事执行重置时把密码写在单引号里没带双引号。Oracle按规则把所有字母转成了大写看起来“重置成功”但密码其实已经被改成大写的版本了。ORDS里存的还是大小写混合的原密码两边不一致结果故障范围从“密码过期”变成了“认证失败配置不同步”处理时间直接翻倍。现在我在团队里立了规矩任何含字母大小写或特殊字符的密码ALTER USER一律用双引号包裹。5.3 全局把DEFAULT改成UNLIMITED审计不答应有人图省事直接执行ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;把整个库的口令策略关了。我当时就劝过这么做虽然能一劳永逸解决过期问题但代价是业务账号也失去了强制改密机制审计来了根本交不了差安全评审也会亮红灯。正确做法是只给服务账号建专用Profile业务账号继续用默认策略各管各的。5.4 在CDB根容器里找不到APEX_PUBLIC_USER前面提过这是个特别容易卡住的边界问题。某个现场的DBA在根容器里查了半天说“APEX_PUBLIC_USER这个账号不存在”还怀疑是不是被删了。实际上账号就在APEX所在的PDB里切个容器再查立刻就看到了。所以遇到“查不到”的情况先想一下容器边界别急着下结论。5.5 密码历史策略导致同口令重置失败同口令重置也不是在所有环境里都能直接成功。如果某个账号的Profile设置了PASSWORD_REUSE_TIME或PASSWORD_REUSE_MAX数据库会拒绝重复使用旧密码。碰到这种情况先查一下SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN (PASSWORD_REUSE_TIME,PASSWORD_REUSE_MAX) AND profile APEX_SERVICE_NOEXP;如果确实限制了密码复用要么临时放宽这几个参数后重置要么用新密码并同步ORDS配置。好在我的生产环境里服务账号的专用Profile一般不设复用限制大部分情况下同口令重置都能一次性成功。5.6 常见问题速查表症状疑似原因处理方式全部APEX页面打不开日志有574ORA-28001APEX_PUBLIC_USER过期同口令重置挂专用ProfileORDS启动失败连接时报ORA-28001ORDS元数据账号过期同口令重置挂专用ProfileREST接口报503或认证失败APEX_REST_PUBLIC_USER过期同口令重置个别应用运行时报ORA-28001应用内连接账号过期重置对应数据库账号并同步应用侧凭据密码重置时提示违反复用规则PASSWORD_REUSE_TIME/MAX限制调整Profile参数后再重置页面间歇性恢复又失败连接池懒加载账号过期优先重置账号再重启ORDS处理完574这类故障我最大的感受是很多中间件报错看起来很吓人但根子其实在数据库侧的账号状态。现在我碰到任何ORDS连接异常第一件事永远是查一遍DBA_USERS确认有没有过期的服务账号而不是急着动配置文件。这个习惯帮我省了太多夜间值班时间。如果你也维护着APEXORDS环境建议把这套定位、救火、防复发的流程整理成自己的检查脚本下次哪怕不是你值班也能让接手的人少走弯路。
