为什么Oracle 11g RAC会报ORA-3113通信超时_排查防火墙对VIP长连接的影响

ORA-3113在RAC中90%是防火墙静默回收VIP空闲连接所致，因VIP不发心跳，超时（默认1800秒）后防火墙删除会话表项，客户端再发包即被丢弃，触发“end-of-file”错误。

ora-3113 出现时，90% 不是数据库挂了，而是防火墙把 vip 连接静默回收了——尤其在 rac 环境下，vip 本身不发心跳包，空闲超时后被防火墙切断，客户端再发请求就直接报 “end-of-file on communication channel”。

为什么 RAC 的 VIP 特别容易被防火墙断连

RAC 中客户端通常连的是 VIP（虚拟 IP），而非物理 IP。但 VIP 本身不主动发送任何网络数据包，只要应用端没有持续 SQL 请求，整个 TCP 连接就处于纯空闲状态。防火墙（尤其是企业级设备如 StoneOS、FortiGate）默认对 TCP 会话设 1800 秒（30 分钟）空闲超时，到期即删会话表项。下次应用发包时，防火墙已无对应会话，直接丢弃，客户端收不到 ACK，最终触发 ORA-3113。

常见错误现象：

• 应用凌晨跑批，第 31 分钟突然失败，日志里只有 ORA-3113，无其他 Oracle 错误
• crs_stat -t 显示所有实例 ONLINE，lsnrctl status 正常，但客户端连 VIP 就断
• 换连物理 IP（非 VIP）后问题消失——这基本坐实是 VIP + 防火墙组合问题

怎么确认是防火墙干的，而不是数据库崩溃

别急着查 alert.log——先做三件事快速定位是否为网络层中断：

• 在数据库服务器上执行：netstat -tn | grep :1521 | grep ESTABLISHED，看连接是否存在；若存在但客户端已收不到响应，大概率是中间设备拦截
• 用 show session detail | include 1521（StoneOS）或 fw ctl conntab -s | grep 1521（Check Point）查防火墙当前会话，观察该连接是否在超时后消失
• 抓包验证：在客户端或 DB 侧用 tcpdump -i any port 1521 -w ora3113.pcap，复现问题后打开看最后是否有 RST 或无响应的 SYN/ACK 交互

如果 alert.log 里紧挨着 ORA-3113 的是 PID xxx died 或 Instance terminated by PMON，那才是真崩溃；否则全是干净的“连接断开”，就是网络链路问题。

sqlnet.expire_time=10 对 RAC VIP 有效吗

有效，但有前提条件：

• 必须配置在**每个节点的 $ORACLE_HOME/network/admin/sqlnet.ora** 中，不是只配一个节点
• 值单位是分钟，建议设为 10（不能为 0，0 表示禁用 DCD）
• 配置后需执行 lsnrctl reload，且仅对**新建立的连接生效**；已有连接仍会按原超时被断
• DCD 探针由 Oracle 监听进程（tnslsnr）发出，目标是客户端 IP+端口，对 VIP 场景完全适用

注意：DCD 不解决防火墙对“建连后零流量”的初始超时判定，它只是让连接在超时前“动起来”。所以即使设了 sqlnet.expire_time=10，若防火墙超时设成 5 分钟，照样断。建议将防火墙 TCP 空闲超时调至 ≥ 15 分钟，再配 DCD 作为兜底。

RAC 下最容易被忽略的 DCD 生效盲区

很多人配完 sqlnet.expire_time 就以为万事大吉，结果测试还是断——问题往往出在这几个地方：

• sqlnet.ora 文件路径错：RAC 中监听可能使用 GRID_HOME 下的 sqlnet.ora，而非 DATABASE_HOME；确认监听实际加载的是哪个：lsnrctl show trc_directory 后查 trace 日志路径反推
• 客户端用了连接池（如 UCP、HikariCP），池内连接长期复用但未启用 validationQuery，导致旧连接一直挂着，DCD 不触发——必须配置连接池的 test-on-borrow 或 validation-interval
• Oracle 客户端版本太老（如 10g client），不支持 DCD 探针解析，sqlnet.expire_time 被忽略；最低要求 Oracle 11g client 及以上

真正稳定的方案，永远是“防火墙超时 ≥ DCD 间隔 ≥ 应用最大空闲窗口”，三者缺一不可。单靠数据库侧配置，治标不治本。