ORA-03135/ORA-02068错误根本原因是DB Link连接被中断，非存储过程本身问题；典型诱因包括防火墙空闲超时、远端账户密码失效、TNS解析失败或版本兼容性问题，需通过显式关闭连接、调整sqlnet.ora超时参数或改用物化视图等方案根治。
ORA-03135 / ORA-02068 这类错误不是存储过程的问题
根本原因不在存储过程本身，而是 db link 底层连接在执行过程中被中断或拒绝。oracle 存储过程调用远程对象（比如 select * from t@dblink 或 call proc@dblink）时，会复用当前会话已建立的 db link 连接；一旦该连接因网络、监听、超时或远端库异常而断开，后续操作就直接抛出 ora-03135: connection lost 或 ora-02068: following severe error from dblink_name。
DB Link 连接失效的典型触发点
这些场景下，即使存储过程逻辑完全正确，也会在运行中突然失败：
-
ORA-03135：最常见于防火墙或中间设备（如负载均衡器）设置了空闲超时（如 5 分钟），DB Link 会话挂起后被强制断开，但本地会话仍尝试复用该“僵尸连接” -
ORA-02068+ORA-01017：远端账户密码过期、被锁定，或 DB Link 定义里用的密码与当前实际不符（尤其在密码策略变更后未同步更新） -
ORA-12154：tnsnames.ora中对应的服务别名解析失败——注意：这个文件可能被多个 Oracle Home 共享，修改后未重启监听或未刷新客户端缓存 -
ORA-28040：11g 与 12c+ 混合环境里，远端库启用了更严格的认证协议（如 SQLNET.ALLOWED_LOGON_VERSION_SERVER=12），而 11g 客户端不支持
为什么重启服务能临时恢复？
这不是“修复”，只是清掉了坏连接状态：
- 重启数据库实例或监听器，会终止所有已建立但失效的 DB Link 会话，新连接从头协商
- 重启应用服务器，会重建整个 JDBC/OCI 连接池，丢弃所有残留的不可用 DB Link 句柄
- 但只要底层问题（如防火墙超时、密码过期、TNS 配置漂移）没解决，几小时后又会复现
存储过程里加异常捕获没用，真正要动的是连接管理
在存储过程中写 EXCEPTION WHEN OTHERS THEN ... 只能兜住错误，不能防止连接断开。真正有效的动作包括：
- 在调用 DB Link 前显式关闭旧连接：
ALTER SESSION CLOSE DATABASE LINK dblink_name;，避免复用悬挂会话 - 远端库启用
SQLNET.EXPIRE_TIME=5（单位分钟），让服务器主动探测并清理空闲连接 - 检查并统一两端的
sqlnet.ora：确保SQLNET.INBOUND_CONNECT_TIMEOUT和SQLNET.SEND_TIMEOUT不设得过小 - 对频繁调用 DB Link 的存储过程，考虑改用物化视图或定时同步表，避开实时跨库调用
DB Link 不是透明管道，它本质是一条有状态、有生命周期、受多层网络策略影响的连接通道。任何把它当“永久可用”的假设，都会在生产环境里准时爆雷。
