ジャスパー レポート [PDF 形式] の生成中にブラウザがハングします。このレポートは、以下に示す説明プランのクエリを実行します。
クエリの分析を手伝ってください。このクエリに時間がかかりすぎていませんか? また、このレポートの生成中にスタック スレッドに気付きました。
ジャスパー レポート [PDF 形式] の生成中にブラウザがハングします。このレポートは、以下に示す説明プランのクエリを実行します。
クエリの分析を手伝ってください。このクエリに時間がかかりすぎていませんか? また、このレポートの生成中にスタック スレッドに気付きました。
EXPLAIN PLAN は、オプティマイザーが情報に基づいてクエリをどのように実行するか (所要時間を含む) を推測したものです。オプティマイザーは、データ ボリュームやシステム特性に関する統計情報など、多くの事柄に基づいてこの推測を行います。
これらの推測は、通常、特に Oracle の新しいバージョンではかなり適切です。ただし、特に統計が古い場合、データ分布が歪んでいる場合、または周囲のシステム条件が原因である場合は、それらがまだ出力されている可能性があります。
特定のケースでは、オプティマイザーは、クエリが 1 つの行を返すと推測しています。それは正しいですか? そうでない場合は、統計が不正確であり、更新する必要があります。
時間に関しては、オプティマイザーはクエリの実行に 45 秒かかると推測しています。それは長すぎますか?あなただけが言うことができますか?
データベースのチューニングは複雑な科学であることに注意してください。多くの詳細な情報が必要です。実行速度の遅いクエリを調整することで、人々はキャリア全体を築きます。Web アプリケーションのチューニングは、アーキテクチャや不適切なコーディングがボトルネックになる可能性があるポイントが非常に多いため、さらに複雑になります。システム全体のパフォーマンスのプロファイルを取得することは非常に困難です。
APCに同意します。私も予想時間(45秒)を見てビックリしました。付け加えると、Explain plan は CBO による「予想される計画」です。実際の実行後、'Actual' と 'Expected' が異なる場合があります。
したがって、実際の計画も確認することをお勧めします。以下を使用して、実際の計画を取得できます。
1) dbms_xplan の使用
explain plan for <SELECT ...>
select * from table(dbms_xplan.display); --estimated plan
select * from table(dbms_xplan.display_cursor); --actual plan
2) '10046 トレース' と TKPROF をトリガーします。
alter session set tracefile_identifier = 'something-unique'
alter session set sql_trace = true;
alter session set events '10046 trace name context forever, level 8';