ORA-03113: 大约 2 小时 10 分钟后，通信通道上的文件结束答案

【问题标题】：ORA-03113: end-of-file on communication channel after ~ 2 hours and 10 minsORA-03113: 大约 2 小时 10 分钟后，通信通道上的文件结束
【发布时间】：2017-07-14 00:49:37
【问题描述】：

我有一个带有过程的 sql 脚本。我使用它运行它 sqlplus -s @script.sql logfile.log myparam1 myparam2 但大约 2 小时 10 分钟后，我的脚本以

结尾

ERROR:
ORA-03114: not connected to ORACLE 


DECLARE
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel 
Process ID: 12345 
Session ID: 33 Serial number: 54321

我有以下 tcp 设置

-bash-4.1$ cat /proc/sys/net/ipv4/tcp_keepalive_time (which is two hours)
7200
-bash-4.1$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
-bash-4.1$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

当脚本运行时，我检查了 TCP 连接在我的端建立，但在数据库端（数据库服务器机器）没有这样的连接。

我的理论是数据库服务器以某种方式断开了连接。当我的系统在 2 小时（7200 秒）后发送第一个 keepalive 探测时，它发现连接不再处于活动状态并关闭连接并返回脚本。

我无法理解为什么数据库系统会断开连接？数据库端是否有任何设置来增加详细程度？或者这可能与某些防火墙设置有关？此外，在 2 小时 10 分钟内，我们可以猜测 2 小时的部分来自 tcp_keepalive_time，即 10 分钟的部分。任何数据库端重试？

编辑：DBA 和我查看了这个问题，我看到 TCP 连接在我的末端已建立，他没有看到任何来自我这边的连接。

【问题讨论】：

这可能是因为数据库进程崩溃，甚至无法报告错误消息。要求您的 DBA 检查警报日志，以了解警报日志中同时发生的任何错误。
在您的脚本中，您是在两个多小时内多次运行 sqlplus，还是您的脚本需要两个多小时才能运行，而 sqlplus 只启动了一次？
Sqlplus 只启动了一次。该脚本只是删除行。

标签： oracle tcp ora-03114

【解决方案1】：

如果我们在那段时间没有任何活动，我们的防火墙会在大约两个小时后断开我们的 Pro*C 连接。我们的解决方案是：

select 1 from dual;

每个数据库连接每 15 分钟一次，以保持活动状态。

如果我没记错的话，您上面提到的 tcp 保持活动时间仅在连接具有 SO_KEEPALIVE 的 setsockopt 调用时使用。由于与 Oracle 的实际连接是由 Oracle 管理的，因此我们无法知道它是否已设置。

在查看此内容时，我在网络上的一些地方（this 和 this）看到了 $ORACLE_HOME/network/admin/sqlnet.ora 文件中对 sqlnet.expire_time=minutes_to_check 的引用。他们说：

设置此参数后，在不活动 10 分钟后，服务器向客户端发送一个 10 字节的小探测包。如果这数据包未确认，连接将被关闭...

下次我得到 DBA 的注意时，我必须让他们更改这个值，看看它对事情的影响。在第二个链接的后面，他们说：

如果 SQLNET.EXPIRE_TIME 小于 FW 连接空闲超时，则防火墙会将此数据包视为活动，并且空闲超时（防火墙中断）永远不会发生，直到两个客户端和服务器进程都处于活动状态。

我希望这正是我们所需要的。

【讨论】：

DBA 在 Oracle 端添加了 SQLNET.EXPIRE_TIME 参数，但我仍然看到问题。也许一些最新的防火墙可能不会将 DCD 数据包视为您指出的文章中提到的有效流量。这里 - zhefeng.wordpress.com/2009/06/15/…

【解决方案2】：

首先，您应该检查您的alert.log，以发现在此期间的任何错误这次。
那么，有两种方法可以使您的活动会话断开连接。
(1)SQLNET.EXPIRE_TIME (2)初始化参数resource_limit为真，你的profile的(dba_users + dba_profiles) idle_time

【讨论】：

【解决方案3】：

通信通道上的文件结尾很少是数据库方面的问题。如果您怀疑 DB 端问题，则通过 gv$session 监控会话活动。您将能够立即找出会话是否“挂起”或长时间运行在特定语句上。断开与数据库的连接并不少见，尤其是在网络不稳定的情况下。

【讨论】：

【解决方案4】：

我们尝试将 SQLNET.EXPIRE_TIME 设置为 10 分钟。但它没有用。我们反弹了数据库服务器机器，但它仍然无法正常工作。也许一些最新的防火墙可能不会将 DCD 数据包视为文章 mentioned in the article 中提到的有效流量（也由上面的@user1683793 给出）。最后，我们将 keepalive 时间更改为 25 分钟（在客户端计算机上），以便 tcp 连接上会有一些流量。幸运的是，防火墙似乎将保持活动数据包视为流量。

-bash-4.1$ cat /proc/sys/net/ipv4/tcp_keepalive_time
1500

【讨论】：