ORA-03113执行sql查询时

Question

我有一个400行的SQL查询，它在30秒内抛出异常

  

ORA-03113：通信频道上的文件结尾

以下是需要注意的事项：

1. 我已将超时设置为10分钟
2. 删除时有最后一个条件可以解决此错误。
3. 仅在我分析索引时才出现此错误。

令人不安的情况是这样的：

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

所以我的假设是，查询从服务器端被终止，显然是因为它被识别为资源占用。

我的假设是否合适？我该如何解决这个问题？

编辑：我试图获得错误查询的解释计划，但解释计划查询也给我一个ORA-03113错误。我知道我的查询不是很高效，但为什么这是ORA-03113错误的原因。我正在尝试从toad运行查询，并且没有生成警报日志或跟踪，我的db版本是 Oracle9i企业版9.2.0.7.0版 - 生产

Answer 1

此错误的一个可能原因是服务器端的线程崩溃。检查Oracle服务器是否已生成任何跟踪文件，或在其警报日志中记录任何错误。

您说从查询中删除一个条件会导致问题消失。没有这个条件，查询需要多长时间才能运行？您是否检查了两个版本的查询的执行计划，以查看添加该条件是否导致选择了一些效率低下的计划？

Answer 2

我对查询的某些变体有类似的连接丢弃问题。在我的情况下，在某些情况下使用rownum时连接丢失了。事实证明，这是一个通过调整某个Oracle数据库配置设置来解决问题的错误。我们采用了一种解决方法，直到可以安装补丁。我希望我能记住更多细节或找到一封旧电子邮件，但我不知道具体细节会有助于解决您的问题。我发布此信息只是为了说您可能遇到了一个错误，如果您可以访问Oracle的支持站点（support.oracle.com），您可能会发现其他人已经报告过它。

编辑： 我快速浏览了Oracle支持。有超过1000个与ORA-03113相关的错误，但我找到了一个可能适用的错误：

错误5015257：QUERY_REWRITE_ENABLED ='TRUE'时，ORAD-3113和COREDUMP失败！

总结：

• 在9.2.0.6.0中确定并在10.2.0.1中修复
• 运行特定查询 （未识别）导致ORA-03113
• 运行解释查询做了 相同
• 有一个核心文件 $ ORACLE_HOME / dbs
• 解决方法是设置 QUERY_REWRITE_ENABLED为false：alter system set query_rewrite_enabled = FALSE;

另一种可能性：

错误3659827：ORA-3113来自长跑查询

• 9.2.0.5.0至10.2.0.0
• 问题：客户长时间运行查询，始终生成ORA-3113错误 在客户系统上，他们会收到core.log文件，但不会收到任何错误 在alert.log中。在测试系统上我使用了我收到的ORA-7445错误。
• 解决方法：在会话级别或实例级别设置“_complex_view_merging”= false。

Answer 3

如果你使用喜欢和数字（不区分大小写），你可以安全地删除这两个部分的“UPPER”，这可以减少检查相似句子的查询时间

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

等于：

AND someMultiJoin.someColumn LIKE '%90936%'

数字不受UPPER影响（％与字符大小写无关）。

Answer 4

从目前为止的信息看起来像是Dave Costa前段时间建议的后端崩溃。你能查看服务器日志吗？

你能用set autotrace traceonly explain获得计划吗？它是从本地SQL * Plus发生的，还是仅通过远程连接发生？当然听起来像后端的ORA-600可能是罪魁祸首，特别是如果它在解析时。成功运行比失败的运行时间更长似乎排除了网络问题。我怀疑它的失败很快但是客户端花了30秒才放弃死连接，或者服务器花了这么长时间来编写跟踪和核心文件。

这可能会让您选择修补（如果您可以在Metalink上找到特定ORA-600的相关修补程序）或升级数据库;或重写查询以避免它。如果这是一个已知的bug，你可能会从Metalink那里得到一些关于如何做到这一点的想法。如果您很幸运，它可能就像提示一样简单，如果额外条件对计划产生意外影响。 someMultiJoin.someColumn是成功版本中使用的索引的一部分吗？ UPPER可能会让它感到困惑，你可以通过暗示它使用索引来说服它回到成功的计划上，但这显然是相当推测的。

Answer 5

这意味着您已断开连接。这可能不是因为资源匮乏。

我已经看到了与数据库的连接在NAT上运行的位置，并且由于没有流量，它会关闭隧道并因此断开连接。通常，如果您使用连接池，则无法获得此信息。

Answer 6

正如@Daniel所说，与服务器的网络连接正在破裂。您可以查看End-of-file on communication channel，看看它是否提供了有用的建议。

分享并享受。

Answer 7

这通常是具有复杂查询的基于成本的优化工具中的错误。

您可以尝试做的是更改执行计划。例如。使用WITH拉出一些subquerys。或者使用SELECT / * + RULE * /提示来阻止Oracle使用CBO。同时删除统计信息会有所帮助，因为Oracle会使用另一个执行计划。

如果您可以更新数据库，请进行9.2.0.8的测试安装并查看错误是否已消失。

有时，有必要转储模式，删除模式中的所有内容并再次导入转储。