ORDS 在 WebLogic 环境中执行 INSERT/UPDATE 时抛出 MissingDependencyException，提示无法提供 @Named("ords") java.sql.Connection，但 SELECT 正常——根本原因常非权限配置，而是数据库端触发器编译异常导致 ORDS 连接上下文初始化中断。
ords 在 weblogic 环境中执行 insert/update 时抛出 `missingdependencyexception`，提示无法提供 `@named("ords") java.sql.connection`，但 select 正常——根本原因常非权限配置，而是数据库端触发器编译异常导致 ords 连接上下文初始化中断。
该错误表面看似 ORDS 缺失写权限或连接池配置异常，实则是一个典型的“故障现象与根因错位”案例。从堆栈关键线索入手：
No provider found for: requires java.sql.Connection with constraint: (provides @Named(ords) java.sql.Connection) ... Caused by: TypeDependencyNotAvailableException: The type: class oracle.dbtools.oauth.OAuthProviderImpl could not be instantiated due to missing dependency: (provides @Named(ords) java.sql.Connection) java.sql.Connection
这并非表示数据库用户无 INSERT 权限，而是 ORDS 在构建 OAuth 认证服务（OAuthProviderImpl）时，依赖注入容器尝试获取一个已命名的 java.sql.Connection 实例（@Named("ords")），但该连接实例未能成功创建。而连接创建失败的深层原因，往往藏在数据库端——特别是当 ORDS 执行 DML 时隐式触发了数据库对象（如 BEFORE INSERT 触发器）。
✅ 根本原因定位：
应用层发起写操作 → ORDS 获取连接并开启事务 → 执行 SQL → 数据库触发器被激活 → 若触发器存在编译错误（INVALID 状态）、依赖对象失效（如被删的函数/视图）、或含未处理异常（如 RAISE_APPLICATION_ERROR 未被捕获），Oracle 可能中断当前会话的连接上下文初始化流程，导致 ORDS 后续无法复用或重建符合 @Named("ords") 约束的连接实例。此时读操作（SELECT）仍可工作，因其不触发相关触发器，连接初始化路径不同。
? 排查与修复步骤：
-
检查数据库触发器状态
登录目标 Schema，查询所有触发器编译状态：SELECT owner, trigger_name, status, last_ddl_time FROM dba_triggers WHERE table_owner = 'YOUR_SCHEMA' AND status = 'INVALID' AND triggering_event LIKE '%INSERT%' OR triggering_event LIKE '%UPDATE%';
-
重新编译失效触发器
对查出的INVALID触发器逐一编译：ALTER TRIGGER your_schema.your_trigger_name COMPILE; -- 或批量编译（需谨慎） BEGIN FOR t IN (SELECT trigger_name FROM user_triggers WHERE status = 'INVALID') LOOP EXECUTE IMMEDIATE 'ALTER TRIGGER ' || t.trigger_name || ' COMPILE'; END LOOP; END; / -
验证触发器逻辑健壮性
检查触发器代码中是否存在以下高危模式：- 未捕获的
EXCEPTION块（尤其WHEN OTHERS THEN NULL隐藏错误）； - 引用了已删除或权限不足的 PL/SQL 包、函数或表；
- 使用了
DBMS_OUTPUT.PUT_LINE（虽不报错，但可能干扰某些 JDBC 驱动行为）； - 在
FOR EACH ROW触发器中执行耗时 DML 或远程调用。
- 未捕获的
-
验证 ORDS 连接池健康度（辅助确认）
确保defaults.xml中连接池配置合理（非主因，但需排除）：<entry key="jdbc.InitialLimit">5</entry> <entry key="jdbc.MinLimit">5</entry> <entry key="jdbc.MaxLimit">20</entry> <entry key="jdbc.InactivityTimeoutInSec">1800</entry>
⚠️ 重要注意事项：
- 不要盲目授予
DBA权限给 ORDS 用户——本问题与权限无关，过度授权反而增加安全风险； - WebLogic 中重启 ORDS 应用不能解决此问题，因为触发器状态驻留在数据库字典中；
- 若触发器涉及跨 Schema 访问，请确保
GRANT EXECUTE ON schema.pkg TO ords_user显式授权，而非仅依赖PUBLIC； - 启用 ORDS 的
debug日志级别（logging.level.oracle.dbtools=DEBUG）可捕获更早的连接获取失败点，但核心线索仍在数据库端。
✅ 总结：
当 ORDS 出现“读正常、写失败”且伴随 @Named("ords") java.sql.Connection 依赖缺失异常时，应优先将排查焦点转向数据库端 DML 相关对象的完整性与有效性，尤其是触发器、存储过程及关联依赖。一次 ALTER TRIGGER ... COMPILE 往往就能恢复整个 REST 写入链路——这提醒我们：现代 REST 框架的稳定性，深度耦合于底层数据库对象的“静默健康”。
