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 间隔 ≥ 应用最大空闲窗口”，三者缺一不可。单靠数据库侧配置，治标不治本。
