APEX实战第8篇：ORDS连库报错574？一招根治用户过期问题

作为 APEX 应用开发工程师，笔者发现很多同行在使用 APEX + ORDS 架构时，都会遇到数据库凭证错误相关的问题。之前大家普遍知道 APEX_PUBLIC_USER 需要设置密码永不过期，但往往会忽略另一个关键用户——ORDS_PUBLIC_USER，这也是导致 Database Credential Error 和 HTTP Status Code: 574 问题反复出现的核心原因。

今天笔者就结合自己的踩坑经历，把 ORDS_PUBLIC_USER 相关的问题解决流程完整分享出来，帮大家快速解决问题，避免重复踩坑。

01 | 先明确问题：ORDS 连不上数据库，报错到底啥意思？

当你启动 ORDS 后，访问 APEX 应用或 ORDS 接口时，可能会遇到这样的错误提示：

ORDS was unable to make a connection to the database. The database user specified by db.username configuration setting is expired. The connection pool named: |default|lo| had the following error(s): UCP-29: Failed to get a connection

简单说，就是 ORDS 配置的数据库用户过期了，导致连接池拿不到连接。这里的关键用户，就是我们今天的主角——ORDS_PUBLIC_USER。

很多同学之前只关注了 APEX_PUBLIC_USER，却不知道 ORDS 正常运行也依赖专属的 ORDS_PUBLIC_USER，这个用户默认使用数据库的 DEFAULT 密码策略，一旦密码过期，就会触发上述错误。

02 | 解决步骤：从定位问题到彻底解决，一步都不能少

下面笔者就把完整的解决流程拆解开，每个步骤都讲清楚操作方法和注意事项，小白也能跟着做。

① 第一步：定位问题用户，确认是 ORDS_PUBLIC_USER 过期

首先我们需要通过 ORDS 命令，确认配置的数据库用户到底是谁，避免操作错用户。

在命令行执行以下命令：

ords config list

这个命令会列出 ORDS 的所有配置信息，找到db.username 对应的 value 值，不出意外的话，会显示ORDS_PUBLIC_USER，这就确认了是这个用户过期导致的问题。

② 第二步：给 ORDS_PUBLIC_USER 配置永不过期策略

既然是密码过期问题，核心就是给 ORDS_PUBLIC_USER 设置密码永不过期的策略。这里笔者假设你已经创建好了名为 PASSWORD_UNLIMITED 的永不过期配置文件（如果没有，可先执行 CREATE PROFILE PASSWORD_UNLIMITED LIMIT PASSWORD_LIFE_TIME UNLIMITED PASSWORD_GRACE_TIME UNLIMITED; 创建）。

以 SYSDBA 身份登录数据库，执行以下 SQL 命令：

alter user ORDS_PUBLIC_USER profile PASSWORD_UNLIMITED;

这一步的作用是把 ORDS_PUBLIC_USER 关联到永不过期的配置文件，从根源上避免后续再次过期。

③ 第三步：重启 ORDS 测试，发现新问题

配置完永不过期策略后，我们重启 ORDS 看看效果，执行命令：

# 1. 查找 ORDS 进程并终止
ps -ef | grep ords
# 找到进程号（第二列数字），执行 kill 命令终止进程
kill -9 进程号

# 2. 后台启动 ORDS 并将日志输出到 ords.log 文件
nohup ords serve > ords.log &

此时大概率会发现，错误变了！新错误提示为：

ORA-28001: The account has expired.

这是因为我们虽然修改了密码策略，但已经过期的账号状态不会自动恢复。这时候有同学会尝试用 ALTER USER ORDS_PUBLIC_USER ACCOUNT UNLOCK;命令解锁，但笔者亲测，这个命令对已经过期的账号状态无效，无法将其从 expired 改为 open。

④ 第四步：重置 ORDS_PUBLIC_USER 密码，恢复账号状态

要彻底解除 expired 状态，必须重置 ORDS_PUBLIC_USER 的密码。以 SYSDBA 身份登录数据库，执行以下 SQL 命令：

ALTER USER ORDS_PUBLIC_USER identified by "newpassword";

注意：这里的 newpassword 替换成你自己的密码，建议设置一个复杂度高、不容易忘记的密码，比如 Ords_2025@Pub（包含大小写、数字和特殊字符）。

执行完这个命令后，ORDS_PUBLIC_USER 的账号状态就会恢复为 open，过期问题就解决了。

⑤ 第五步：关键坑点！用正确命令同步 ORDS 密码配置

重置完数据库用户密码后，很多同学会直接重启 ORDS，但此时会遇到新的错误：

The connection pool named: |default|lo| had the following error(s): ORA-01017: invalid credential or not authorized; logon denied

这是因为 ORDS 配置里的密码还是旧的，没有同步我们刚重置的新密码。这里要重点提醒大家，不同 ORDS 版本设置密码的命令不一样！

笔者使用的是 ORDS 25.1 版本，这个版本及以后的新版本，敏感配置（比如密码）必须用 secret 子命令设置，普通的 ords config set db.password 命令会失效。

正确的操作是在命令行执行：

ords config secret db.password

执行后会提示你输入密码，直接输入我们刚才重置的 newpassword 即可（交互式输入更安全，避免密码暴露在命令行历史记录中）。

如果你的 ORDS 版本较低（比如 21 之前），可能需要用 ords config set db.password "newpassword"，但建议优先用 secret 命令，更符合安全规范。

⑥ 第六步：最终测试，确认问题解决

完成密码同步后，我们再次重启 ORDS：

# 1. 查找 ORDS 进程并终止
ps -ef | grep ords
kill -9 进程号

# 2. 后台启动 ORDS
nohup ords serve > ords.log &

此时访问 APEX 应用或 ORDS 接口，就不会再出现之前的数据库连接错误了。为了确保万无一失，也可以通过以下方式验证 ORDS 状态：

# 方式1：查看 ORDS 进程是否存在（确认启动成功）
ps -ef | grep ords

# 方式2：查看 ORDS 日志，确认无报错
tail -f ords.log

# 方式3：查看 ORDS 配置信息，确认核心配置正确
ords config list

如果通过 ps 命令能看到 ORDS 进程，且日志中无数据库连接相关报错，就说明 ORDS 正常运行，问题彻底解决。

03 | 避坑指南：这些关键要点，帮你避免重复踩坑

在解决问题的过程中，笔者踩了几个坑，这里总结出来，帮大家少走弯路：

① 不要只关注 APEX_PUBLIC_USER，忽略 ORDS_PUBLIC_USER

APEX_PUBLIC_USER 是 APEX 应用的核心用户，ORDS_PUBLIC_USER 是 ORDS 服务的核心用户，两者缺一不可。建议在安装配置初期，就同时给这两个用户设置永不过期策略，一劳永逸。

② 账号过期后，仅解锁无效，必须重置密码

很多同学误以为 ALTER USER ... ACCOUNT UNLOCK 能解决过期问题，但实际上这个命令只能解决账号锁定问题，无法解除过期状态。过期状态必须通过重置密码才能恢复，这一步不能省。

③ 注意 ORDS 版本差异，密码配置命令要选对

ORDS 21 版本及以后，敏感配置必须用ords config secret 命令设置，普通的 set 命令无效；另外要注意，ORDS 没有 status 命令，无法直接查看运行状态，需通过查看进程、日志或配置信息验证。如果设置密码后仍报错，先检查自己的 ORDS 版本和配置是否正确。

④ 密码要保持一致：数据库用户密码 ≡ ORDS 配置密码

重置 ORDS_PUBLIC_USER 的数据库密码后，一定要同步更新 ORDS 配置里的密码，两者必须完全一致（包括大小写、特殊字符），否则会报 ORA-01017 认证失败错误。

04 | 总结：一劳永逸的核心方案

其实解决这个问题的核心很简单：给 ORDS_PUBLIC_USER 配置永不过期的密码策略，同时确保 ORDS 配置里的密码与数据库用户密码一致。

完整流程可以简化为：定位用户 → 配置永不过期策略 → 重置密码 → 同步 ORDS 密码配置 → 重启 ORDS。

建议大家在搭建 APEX + ORDS 环境时，就提前完成这两个用户（APEX_PUBLIC_USER、ORDS_PUBLIC_USER）的永不过期配置，避免后续运行中突然出现问题，影响业务使用。

如果大家在操作过程中遇到其他问题，欢迎在评论区留言交流，笔者会尽力为大家解答～