9

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

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

以下是需要注意的事项：

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

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

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

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

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

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

4

7 回答 7

5

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

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

于 2010-07-28T12:32:41.520 回答
3

对于查询的某些变体，我遇到了类似的连接丢弃问题。在我的情况下，在某些情况下使用 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：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。
于 2010-08-13T01:10:06.773 回答
2

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

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

等于：

AND someMultiJoin.someColumn LIKE '%90936%'

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

于 2010-08-11T15:50:44.523 回答
1

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

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

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

于 2010-08-10T11:21:43.257 回答
0

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

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

于 2010-07-28T07:31:55.013 回答
0

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

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

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

有时它有助于转储模式，删除其中的所有内容并再次导入转储。

于 2010-08-06T06:45:14.573 回答
0

正如@Daniel 所说，与服务器的网络连接正在中断。您可以查看通信频道上的文件结尾，看看它是否提供了任何有用的建议。

分享和享受。

于 2010-07-28T11:27:56.367 回答