web-dev-qa-db-ja.com

Oracle SQL Developerの実行計画の実行結果の理解

クエリを最適化しようとしていますが、説明計画から返される情報の一部を理解できません。 OPTIONS列とCOST列の重要性を教えていただけますか？ OPTIONS列には、Word FULLのみが表示されます。 COST列では、コストが低いほどクエリが高速になると推測できます。しかし、コスト値は正確に何を表し、許容可能なしきい値は何ですか？

oracleoracle-sqldevelopersql-execution-plan
61
Kevin Babcock

EXPLAIN PLANの出力は、Oracleのクエリオプティマイザーからのデバッグ出力です。 COSTは、コストベースのオプティマイザー（CBO）の最終出力であり、その目的は、クエリを実行するために使用可能な多くの異なるプランのいずれかを選択することです。 CBOは各プランの相対コストを計算し、最もコストの低いプランを選択します。

（注：CBOには、考えられるすべての計画を評価するのに十分な時間がない場合があります。これらの場合、これまでに見つかった最低コストの計画を選択するだけです）

一般に、スロークエリの最大の要因の1つは、クエリを処理するために読み取られる行数（より正確にはブロック）であるため、コストは部分的にに基づきますオプティマイザーの推定値を読み取る必要がある行の数。

たとえば、次のクエリがあるとします。

SELECT emp_id FROM employees WHERE months_of_service = 6;

（months_of_service列にはNOT NULL制約があり、通常のインデックスがあります。

オプティマイザーがここで選択できる2つの基本的な計画があります。

  • プラン1：「employees」テーブルからすべての行を読み取り、それぞれについて、述語がtrue（months_of_service=6）。
  • 計画2：インデックスを読み取ります。months_of_service=6（これにより一連のROWIDが生成されます）、返されたROWIDに基づいてテーブルにアクセスします。

「従業員」テーブルに1,000,000（100万）行があると想像してください。さらに、months_of_serviceの値の範囲が1から12であり、何らかの理由でかなり均等に分布していることを想像してみましょう。

プラン1のコストはFULL SCANを含み、employeesテーブルのすべての行を読み取るコストになります。これは約1,000,000です。しかし、Oracleは多くの場合マルチブロック読み取りを使用してブロックを読み取ることができるため、実際のコストは低くなります（データベースの設定方法によって異なります）。マルチブロック読み取りカウントが10であると想像しましょう-フルスキャンの計算コストは​​1,000,000/10です。総費用= 100,000。

プラン2のコストは、INDEX RANGE SCANとROWIDによるテーブルルックアップを伴い、インデックスのスキャンコストに加えて、ROWIDによるテーブルへのアクセスコストになります。インデックスレンジスキャンのコストについては説明しませんが、インデックスレンジスキャンのコストは行ごとに1であると想像してください。 12ケース中1ケースで一致が見つかると予想されるため、インデックススキャンのコストは1,000,000/12 = 83,333です。さらに、テーブルにアクセスするコスト（アクセスごとに1ブロックの読み取りを想定し、ここではマルチブロック読み取りを使用できない）= 83,333;総コスト= 166,666。

ご覧のとおり、プラン1（フルスキャン）のコストは、プラン2（インデックススキャン+ ROWIDによるアクセス）のコストよりも低くなっています。つまり、CBOはフルスキャンを選択します。

ここでオプティマイザーによって行われた仮定が真である場合、実際にはプラン2がプラン2の方が好ましく、効率的です。これは、フルスキャンが「常に悪い」という神話を否定します。

オプティマイザーの目標がALL_ROWSではなくFIRST_ROWS（n）の場合、結果はまったく異なります。この場合、オプティマイザーは最初の数行をより速く返すことが多いため、クエリ全体の効率が低下するため、プラン2を優先します。 。

103
Jeffrey Kemp

CBOは決定ツリーを構築し、クエリごとに使用可能な各実行パスのコストを推定します。コストは、インスタンスに設定されたCPU_costまたはI/O_costパラメーターによって設定されます。また、CBOは、クエリが使用するテーブルとインデックスの既存の統計を使用してできる限りコストを見積もります。コストだけに基づいてクエリを調整しないでください。コストにより、オプティマイザーが何をするのかを理解できます。コストがなければ、オプティマイザーが実行したプランを選択した理由を把握できます。コストが低くても、クエリが高速になるわけではありません。これが当てはまる場合と、これが間違っている場合があります。コストはテーブルの統計に基づいており、それらが間違っている場合、コストは間違っています。

クエリを調整するときは、各ステップのカーディナリティと行数を確認する必要があります。彼らは理にかなっていますか？オプティマイザーが想定しているカーディナリティは正しいですか？行が適切に返されているかどうか。存在する情報が間違っている場合、オプティマイザーが正しい決定を下すために必要な適切な情報を持っていない可能性が非常に高くなります。これは、cpu-statsと同様に、テーブルとインデックスの統計が古いか、欠落していることが原因である可能性があります。オプティマイザーを最大限に活用するためにクエリを調整するときに統計を更新するのが最善です。スキーマを知ることは、チューニングの際にも非常に役立ちます。オプティマイザーが非常に悪い決定を選択した時期を把握し、小さなヒントを使用して正しいパスを指定することで時間を節約できます。

7
MichaelN

OracleでEXPLAIN PLANを使用するためのリファレンスは次のとおりです。 http://download.Oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm ）ここにある列： http://download.Oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i183

「FULL」という言葉は、クエリがデータを見つけるために全表スキャンを実行していることを示しています。これは、特定の状況では問題ありませんが、そうでない場合は、インデックス作成/クエリの書き込みが不十分であることを示しています。

通常、EXPLAIN PLANでは、問合せでキーを使用していることを確認する必要があります。したがって、Oracleは、必要最小限の行にアクセスして目的のデータを見つけることができます。最終的には、テーブルのアーキテクチャを使用してこれまでのところしか取得できません。コストが高すぎる場合は、スキーマのレイアウトを調整してパフォーマンスベースを高めることを検討する必要があります。

6
drowe

最近のOracleバージョンでは、COSTはオプティマイザーがクエリに要する時間を表し、単一ブロックの読み取りに必要な時間の単位で表されます。

したがって、単一ブロックの読み取りに2ミリ秒かかり、コストが「250」と表される場合、クエリの完了には500ミリ秒かかると予想されます。

オプティマイザーは、単一ブロックおよびマルチブロックの読み取りの推定数、およびプランのCPU消費に基づいてコストを計算します。後者は、特定の操作を他の操作の前に実行して、CPUコストの高い操作を回避することにより、コストを最小限に抑えるのに非常に役立ちます。

これにより、オプティマイザーが操作にかかる時間をどのように知るのかという疑問が生じます。 Oracleの最近のバージョンでは、「システム統計」のコレクションが許可されています。これは、テーブルまたはインデックスの統計と混同しないようにしてください。システム統計は、ハードウェアのパフォーマンスの測定値であり、最も重要なことは次のとおりです。

  1. 単一ブロックの読み取りにかかる時間
  2. マルチブロック読み取りにかかる時間
  3. マルチブロック読み取りの大きさ（テーブルのエクステントが最大値よりも小さいために可能な最大値と異なることがよくあります）.
  4. CPUパフォーマンス

これらの数値は、システムの動作環境によって大きく異なる可能性があり、「昼間OLTP」操作と「夜間バッチレポート」操作、および必要に応じて「月末レポート」に対して異なる統計セットを保存できます。

これらの統計情報のセットを使用すると、特定のクエリ実行プランをさまざまな動作環境でコストを評価できます。これにより、全テーブルスキャンまたは他のインデックススキャンの使用が促進される場合があります。

コストは完全ではありませんが、オプティマイザーはリリースごとに自己監視を改善し、将来のより良い判断を下すために、推定コストと比較して実際のコストをフィードバックできます。これにより、予測がかなり難しくなります。

並列クエリ操作は複数のスレッドで合計時間を消費するため、コストは必ずしも実時間ではありません。

Oracleの古いバージョンでは、CPU操作のコストは無視され、シングルおよびマルチブロック読み取りの相対コストは、initパラメーターに従って効果的に修正されました。

3
David Aldridge

FULLはおそらくフルテーブルスキャンを指しているので、使用中のインデックスはありません。これは通常、クエリがテーブル内のすべての行を使用することになっていない限り、何かが間違っていることを示しています。

コストは、さまざまな負荷、プロセッサ、メモリ、ディスク、IOの合計を示す数値であり、高い数値は通常不良です。計画のルートに移動すると数値が加算されるため、各ブランチを調べてボトルネックを特定する必要があります。

また、v $ sqlおよびv $ sessionを照会してSQLステートメントに関する統計を取得することもできます。これには、あらゆる種類のリソース、タイミング、および実行に関する詳細なメトリックが含まれます。

1
stili