关于oracle：ORA-03113：ASP.Net应用中长时间不活动后通信通道上的文件结束

我已经使用ODAC / ODP.Net驱动程序的10.1.0.301版在IIS5上实现了负载平衡(不使用会话状态)ASP.Net 2.0应用程序，该应用程序运行回单个Oracle 10g服务器。 长时间不活动(几个小时)后，看似随机的应用程序将抛出Oracle异常：

Exception: ORA-03113: end-of-file on communication channel at
Oracle.DataAccess.Client.OracleException.HandleErrorHelper(Int32
errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx*
pOpoSqlValCtx, Object src, String procedure) at
Oracle.DataAccess.Client.OracleCommand.ExecuteReader(Boolean requery,
Boolean fillRequest, CommandBehavior behavior) at
Oracle.DataAccess.Client.OracleCommand.System.Data.IDbCommand.ExecuteReader()

...Oracle portion of the stack ends here...

我们将在每个请求上创建新的连接，将打开和关闭包装在try / catch / finally中，以确保正确关闭连接，并将整个内容包装在using(OracleConnection yadayada){...}块中。 由于不活动而被分解后，此问题似乎没有链接到ASP.Net应用程序的重新启动。

我们还没有自己重现问题。 思想，祈祷，帮助？

更多：经过IT检验，防火墙未设置为杀死这些服务器之间的连接。

ORA-03113: end-of-file on communication channel

数据库是否在通知您不再存在网络连接。这可能是因为：

对于1)(防火墙)在tahiti.oracle.com中搜索SQLNET.EXPIRE_TIME。这是一个sqlnet.ora参数，它将以可配置的时间间隔定期发送网络数据包，即：设置此项将使防火墙认为该连接处于活动状态。

对于1)(网络)与您的网络管理员交谈(连接可能不可靠)

对于2)检查alert.log是否有错误。如果服务器进程失败，将出现错误消息。此外，还将编写跟踪文件以使支持人员能够识别问题。该错误信息将引用跟踪文件。

可以在metalink.oracle.com上使用适当的客户服务标识符(CSI)提出支持问题。

将Validate Connection = true添加到您的连接字符串。

查看此博客以了解更多信息。

细节：
在OracleConnection.Close()之后，实际的数据库连接不会终止。连接对象放回连接池中。 ODP.NET隐式使用了连接池。如果创建新的连接，则将获得其中一个池。如果此连接"尚未打开"，则OracleConnection.Open()方法实际上不会创建新的连接。如果实际连接断开(出于任何原因)，则在第一次选择，更新，插入或删除时会失败。

使用Validate Connection，可以在Open()方法中验证真实的连接。

检查一段时间后，是否没有防火墙终止连接(这是我们遇到的类似问题的原因)

end-of-file on communication channel:

此错误的过程之一是由于数据库处于打开状态而无法写入日志；

解决方案检查数据库是否在ARCHIVELOG或NOARCHIVELOG中运行

检查使用

如果它在ARCHIVELOG上尝试更改为NOARCHIVELOG

通过使用sqlplus

• 启动挂载
• 更改数据库noarchivelog；
• 更改数据库打开；

如果它适用于此

然后，您可以调整闪回恢复区域，使其可能是闪回恢复区域已满
->然后在确认您的闪存恢复区域具有空间之后，可以将数据库更改为ARCHIVELOG

当实际问题是oracle数据库服务器空间不足时，可以在应用程序日志中引发此错误消息。

更正空间问题后，此特定错误消息消失了。

您可以尝试以下注册表黑客：

如果可行，只需增加KeepAliveTime。当前设置为2分钟。

前面提到的文章很好。 http://forums.oracle.com/forums/thread.jspa?threadID=191750(目前为止)

如果这不是经常运行的内容(请不要在主页上执行此操作)，则可以关闭连接池。

本文中没有提到其他"陷阱"。如果您尝试使用连接进行的第一件事是调用存储过程，则ODP将挂起！！！您将不会回去管理一个错误情况，只需全力以赴！解决此问题的唯一方法是关闭连接池。一旦我们做到了，所有的问题就消失了。

池化在某些情况下是好的，但代价是每个连接的第一个语句周围的复杂性增加。

如果错误处理方法如此好，为什么他们不将其作为ODP的选项来为我们处理？