DBMS_XPLAN.DISPLAY_CURSOR対gather_plan_statisticsを使用していないことDBMS_XPLAN.DISPLAY_CURSORはあなたに<em>実際</em>を与えながらPLANはあなたに<em>理論</em>実行計画を与えるEXPLAIN、ちょうど私が理解から、2の間の差にいくつかの明確化を要求

Question

をヒント場合の計画を説明ステートメントの実行統計を含む実行計画。

EXPLAIN PLANはこのデータをPLAN_TABLEに格納しますが、DBMS_XPLANはその情報としてV $ SQL_PLAN、V $ SQL_PLAN_STATISTICSおよびV $ SQL_PLAN_STATISTICS_ALLビューを使用します。

しかし、DISPLAY_CURSORがそのステートメントの実際のランタイム統計情報を収集するには、/*+ gather_plan_statistics */ヒントを設定する必要があります。それ以外の場合は、V $ SQL_PLANのみが格納されます。これは実行プランのみを提供し、実際の実行統計は提供しません。 /*+ gather_plan_statistics */で、V $ SQL_PLAN_STATISTICSが満たされている場合のみです。

私はgather_plan_statisticsヒントを使用しないと、EXPLAIN PLANとDISPLAY_CURSORは常に同じ実行計画を同じステートメントに与えますか？

Answer 1

違いはあまり微妙ではなく、巨大です。

あなたが正しく言及したように、planはplan_tableにデータを格納し、プランはそのテーブルからクエリされます。これは、sqlが実行されないことを意味し、オプティマイザのみがプランを提供するように求められます。その設定では、プランは、Explainプランを実行するセッションのオプティマイザ環境に大きく依存します。

DBMS_XPLAN.DISPLAY_CURSORを使用すると、以前に実行された計画を取得できます。プランは、DBMS_XPLAN.DISPLAY_CURSORを発行して格納されません。実行されたためv $構造体に格納されます。あなたは

select * from dual; 
select * from table(dbms_xplan.display_cursor); 

を実行することができますセッションで

クエリが「デュアルから選択」で実行され、これはまた、計画の作成で、私は五$構造に保存されていることの結果。 display_cursorは直前に実行されたカーソルを見つけ、それに続くプランを表示します。プランとその統計情報が既にshared_poolに存在するため、このセットアップで/ * + gather_plan_statistics * /は追加値を持ちません。

あなたの他の質問は、計画が常に同じかどうかは、多くの要因によって異なります。変数は同じですか？Adaptive Cursor Sharingを使用していますか？SQL Plan Stabilityを使用していますか？

あなたの質問：計画を説明してdisplay_cursorと同じ計画をしていますか？私はそれを頼りにしません。なぜなら、説明計画では、プランはセッションオプティマイザ環境に依存するからです。 display_cursorはより良い方法であり、好ましくはアプリケーションによって作成された名前付きカーソルを使用します。 SQL Plan Stabilityを使用しない場合は、オプティマイザ統計が変更されたときにプランが変更される可能性があります。 Adaptive Cursor Sharingを使用すると、変数が変更されたときにプランが変更される可能性があります。

サンプリングのオーバーヘッドについての素晴らしい読みは、Jonathan Lewisブログで見つけることができます。また、Jonathan：gather_plan_statisticsから、/ * + gather_plan_statistics * /ヒントを使用するのではなく、statistics_levelを 'all'に設定してデバッグするのが賢明です。ヒントはコードを変更し、新しいsql_idを生成します。

こちらがお役に立てば幸いです。