ORA-03113 执行 sql 查询时答案

【问题标题】：ORA-03113 while executing a sql queryORA-03113 执行 sql 查询时
【发布时间】：2011-03-22 00:05:51
【问题描述】：

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

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

以下是注意事项：

我已将超时设置为 10 分钟
删除后的最后一个条件可解决此错误。
这个错误是最近我分析索引时才出现的。

麻烦的情况是这样的：

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

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

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

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

【问题讨论】：

阅读这篇文章——它以 ORA-03113 开头。 stackoverflow.com/questions/3347305/ora-07445-access-violation
请添加对问题文本造成麻烦的条件。
@VincentMalgrat - 我认为您不应该删除您的答案。它包含有用和中肯的建议。您只需要从 MOS 注释中删除那一大段引用即可。
@VincentMalgrat - 您能否请重新发布您的部分答案，这很有帮助。

标签： oracle query-optimization ora-03113

【解决方案1】：

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

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

【讨论】：

查询需要大约 40 秒才能消除该条件。当我尝试获得解释计划（有条件）时，我得到了同样的 ORA-03113 错误。
执行解释计划时遇到 ORA-03113 错误的事实进一步证明了 Oracle CBO 中的崩溃。您需要提高 Oracle 支持（如果您没有支持，请尝试升级到更高版本，因为您遇到的错误可能已修复）。也许 UPPER() 在常量上有一个错误的优化？

【解决方案2】：

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

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

错误 5015257：当 QUERY_REWRITE_ENABLED='TRUE' 时，使用 ORA-3113 和 COREDUMP 查询失败

总结一下：

在 9.2.0.6.0 中识别并在 10.2.0.1 中修复
运行特定查询（未确定）导致 ORA-03113
对查询运行解释一样的
中有一个核心文件 $ORACLE_HOME/dbs
解决方法是设置 QUERY_REWRITE_ENABLED 为 false：更改系统设置 query_rewrite_enabled = 错误；

另一种可能性：

错误 3659827：来自长时间运行的查询的 ORA-3113

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

【讨论】：

【解决方案3】：

如果您使用带有数字（不区分大小写）的like，您可以安全地删除两个部分的“UPPER”，这可以减少查询类似句子的时间 p>

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

等于：

AND someMultiJoin.someColumn LIKE '%90936%'

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

【讨论】：

【解决方案4】：

从目前的信息来看，这似乎是后端崩溃，正如 Dave Costa 前段时间所建议的那样。你能检查服务器日志吗？

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

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

【讨论】：

【解决方案5】：

这意味着您已断开连接。这不太可能是因为消耗资源。

我已经看到到数据库的连接在 NAT 上运行，因为没有流量，它关闭了隧道，从而断开了连接。一般来说，如果你使用连接池，你不会得到这个。

【讨论】：

不应该是这样，因为我已经尝试了一遍又一遍，仍然得到同样的错误。

【解决方案6】：

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

分享和享受。

【讨论】：

【解决方案7】：

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

您可以尝试更改执行计划。例如。使用WITH 拉出一些子查询。或者使用 SELECT /*+ RULE */ 提示来阻止 Oracle 使用 CBO。删除统计信息也有帮助，因为 Oracle 随后会使用另一个执行计划。

如果可以更新数据库，请测试安装 9.2.0.8，看看错误是否消失。

有时，将架构转储，删除其中的所有内容并再次导入转储会有所帮助。

【讨论】：