9

30秒以内に例外をスローする400行のSQLクエリがあります

ORA-03113: 通信チャネルでファイルの終わりです

以下に注意事項を示します。

  1. タイムアウトを10分に設定しました
  2. 削除すると、このエラーが解決する最後の条件が 1 つあります。
  3. このエラーは、インデックスを分析したときに最近発生しました。

厄介な条件は次のとおりです。

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

したがって、私の仮定は、クエリがリソースの浪費として識別されたため、明らかにサーバー側から終了されているということです。

私の仮定は適切ですか？この問題を解決するにはどうすればよいですか?

編集:障害のあるクエリの説明プランを取得しようとしましたが、説明プランのクエリでも ORA-03113 エラーが発生します。私のクエリはあまりパフォーマンスが高くないことは理解していますが、なぜそれが ORA-03113 エラーの理由になるのでしょうか。ヒキガエルからクエリを実行しようとしていますが、アラート ログもトレースも生成されません。データベースのバージョンは Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production です。

4

7 に答える 7

5

このエラーの考えられる原因の 1 つは、サーバー側でのスレッドのクラッシュです。Oracle サーバーがトレース ファイルを生成したかどうか、またはアラート ログにエラーを記録したかどうかを確認します。

クエリから 1 つの条件を削除すると、問題が解決すると言われています。その条件なしでクエリを実行するにはどのくらいの時間がかかりますか? クエリの両方のバージョンの実行プランをチェックして、その条件を追加することで非効率的なプランが選択されていないか確認しましたか?

于 2010-07-28T12:32:41.520 に答える
3

クエリの特定のバリエーションで、同様の接続切断の問題が発生しました。私の場合、特定の状況でrownumを使用すると、接続が切断されました。これは、特定のOracleデータベース構成設定を調整することで回避策があったバグであることが判明しました。パッチをインストールできるようになるまで、回避策を実行しました。もっと詳細を覚えたり、これに関する古いメールを見つけたりできればいいのですが、詳細があなたの問題に対処するのに役立つかどうかはわかりません。おそらくバグに遭遇したことを伝えるためにこれを投稿します。Oracleのサポートサイト（support.oracle.com）にアクセスできる場合は、他の人から報告されている可能性があります。

編集：Oracleのサポートについて簡単に説明しました。ORA-03113に関連するバグは1000以上ありますが、該当する可能性のあるバグが見つかりました。

バグ5015257：QUERY_REWRITE_ENABLED ='TRUE'の場合、ORA-3113とコアダンプでクエリが失敗する

要約する：

  • 9.2.0.6.0で識別され、10.2.0.1で修正されました
  • 特定のクエリ（識別されていない）を実行すると、ORA-03113が発生します
  • クエリでexplainを実行しても同じです
  • $ ORACLE_HOME/dbsにコアファイルがあります
  • 回避策は、QUERY_REWRITE_ENABLEDをfalseに設定することです。altersystem 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

likeを数字 (大文字と小文字を区別しない) で使用している場合は、両方の部分の "UPPER" を安全に削除できます。これにより、like 文をチェックするクエリ時間を短縮できます。

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 に関連する修正を見つけることができれば)、DB をアップグレードするオプションが残されます。またはそれを回避するためにクエリを書き直します。既知のバグである場合は、Metalink からその方法についていくつかのアイデアを得ることができます。運が良ければ、余分な条件が計画に予期しない影響を与えているかどうかは、ヒントと同じくらい簡単かもしれません. someMultiJoin.someColumn成功したバージョンで使用されているインデックスの一部ですか? 混乱している可能性がUPPERあり、とにかくインデックスを使用するようにほのめかすことで、成功した計画に戻すことができますが、それは明らかにかなり投機的です.

于 2010-08-10T11:21:43.257 に答える
0

これは、多くの場合、複雑なクエリを使用するコスト ベース オプティマイザーのバグです。

できることは、実行計画を変更することです。たとえば、WITHを使用していくつかのサブクエリを引き出します。または、SELECT /*+ RULE */ ヒントを使用して、Oracle が CBO を使用しないようにします。Oracle は別の実行計画を使用するため、統計を削除することも役立ちます。

データベースを更新できる場合は、9.2.0.8 のテスト インストールを行い、エラーが解消されるかどうかを確認します。

スキーマのダンプを作成し、その中のすべてを削除して、ダンプを再度インポートすると役立つ場合があります。

于 2010-08-06T06:45:14.573 に答える
0

切断されたことを意味します。これは、リソースを大量に消費していることが原因であるとは考えられません。

DB への接続が NAT 経由で実行されている場所を見てきました。トラフィックがないため、トンネルが閉じられ、接続がドロップされます。通常、接続プーリングを使用する場合、これは得られません。

于 2010-07-28T07:31:55.013 に答える
0

@ダニエルが言ったように、サーバーへのネットワーク接続が切断されています。通信チャネルの End-of-file を調べて、有用な提案があるかどうかを確認してください。

共有してお楽しみください。

于 2010-07-28T11:27:56.367 に答える