SQL実行計画を作成する際、統計情報が古いまたはそもそもない場合にサンプリングして取得。 これを実行するのに、USERIDとPASSWORDの値がヒットするまでUSERTABLEの全行を見る(フルスキャンする)のか、あるいはUSERTABLEのUSERIDに対応づけられたINDEXを参照するのか、具体的な方法を示したものが実行計画というわけです。, 上述のとおり、オプティマイザは実行計画の候補を幾つか作成し、どうしたら最短で実行できるか、これらの候補を比較した結果、より適切な実行計画が1つ選ばれ共有プールへ格納されるというわけです。その実行計画を作成するために基となる情報が「統計情報」になります。, 「統計情報」の定義については、以下に紹介した引用・参考資料に記載されているため多くは触れませんが、主に表統計、列統計、索引統計、システム統計から構成されています。これらの統計情報は、実際のデータベース上にある表や列、索引等の実態から得ているわけですが、どうやって、どのタイミングで反映しているのでしょうか?以下の3種類の方法があります。, ①自動的に取得 難しいです。(できなくはありませんが、かなり推測に頼る形になります。), SQLのWHERE条件と対応付けるためには、フィルタ述語とアクセス述語に着目する必要があります。, 実行計画をDBMS_XPLAN.DISPLAY_CURSORで取得した場合、フィルタ述語とアクセス述語に関する情報は 一般にアクセスするブロック数は大きくなりがちです。, したがって、どうしてもケースバイケースの側面はありますが、データの絞込みは 共有プールに残っていない場合は表示されないはずです。 フィルタ述語 filter(“PA”.”PID”=1) が適用されていることがわかります。 (※3)引用・参考資料の2.に説明のとおり、共有プール上にある実行計画をキャッシュアウトさせる前提で、統計情報の再収集後にOracle Databaseは新しい統計情報をもとに実行計画を作り直します。, 2.門外不出のOracle現場ワザ 第4章 Oracleデータベースの頭脳 「オプティマイザ」徹底研究. – 日本語訳, full table scan実行時にオプティマイザ統計駆動でdirect path read実行を決定する(_direct_read_decision_statistics_driven), SQL計画安定性のための CURSOR_SHARING = FORCEおよびFORCE_MATCHING_SIGNATUREの限界, lazyなOracleユーザーのためのヒント – タイプ数を削減するANSI DATEおよびTIMESTAMP SQL構文, poor-manスタック プロファイラでCPU使用率が高い事象をトラブルシューティング – ワンライナーで!, ALTER SESSION FORCE PARALLEL QUERYは、実際に何かを強制するものではありません, asqlmon.sql : SQL監視のような実行計画の行レベルのSQLレスポンス時間へのドリルダウン, quick'n'dirtyトラブルシューティングのために/procファイルシステムを使用してLinuxカーネルランドを覗く, Advanced Oracle Troubleshooting Guide [PART 1] :待機インタフェースが十分でない場合, Advanced Oracle Troubleshooting Guide, Part 2 : 魔法は必要ありません、体系的なアプローチで成しえるものです, Advanced Oracle Troubleshooting Guide, Part 3: プロセス?スタックをさらに冒険する, Advanced Oracle Troubleshooting Guide, Part 4 : 長時間パース問題の診断, Advanced Oracle Troubleshooting Guide, Part 5:WaitProfで本当に素早くV$ビューをサンプリング。SQLで!, Advanced Oracle Troubleshooting Guide, Part 6:os_explainを使用してOracleの実行計画を理解する, Advanced Oracle Troubleshooting Guide, Part 7:LatchProfを使用してラッチホルダの統計情報をサンプリング, Advanced Oracle Troubleshooting Guide, Part 8:LatchProfXを使用した、より詳細なラッチのトラブルシューティング, Advanced Oracle Troubleshooting Guide, Part 9 – OStackProfを使用してSQL*Plusからプロセススタックプロファイリング, Advanced Oracle Troubleshooting Guide – Part 10: インデックスユニークスキャンがマルチブロック読み込み?, Advanced Oracle Troubleshooting Guide – Part 11 :ash_wait_chains.sqlを用いた複雑な待機チェーンのシグネチャ分析, ash_wait_chains.sqlスクリプト(v0.2)でbuffer busy waitsを診断する, JPOUG Tech Talk Night #4 やりますよ! 今回は LTと12c座談会です, Oracle OpenWorld Unconference presented by JPOUG, オペレーションの一覧と最低限覚えておくべきオペレーション (実行計画の読み方#2). 指定しなくても、使用されないヒントがある場合は自動で表示されます。, SIer&バックエンドエンジニア&日曜プログラマー。 アクセス述語に合致したデータにのみ選択的にアクセスします。 DBMS_XPLAN.DISPLAY_CURSOR 2. 付与したヒント句が本当に反映されたかどうかを確認できます。, 開発環境(性能試験以外)なら、statistics_levelをALLにして、formatを"ALLSTATS LAST ADVANCED"しておけば良いかと思います。 By following users and tags, you can catch up information on technical fields that you are interested in as a whole, By "stocking" the articles you like, you can search right away. 適用されます。アクセスした後にデータを絞り込む形になるため、 DBMS_XPLAN.DISPLAY_CURSORは、v$sql_planから実行計画を取得することができるファンクションです。ただし、共有プールから実行計画が削除されている場合は取得することができません。, 以降、Oracle 12c R2にてDBMS_XPLAN.DISPLAY_CURSORを使用してみます。, SQL IDを指定して実行計画を取得します。通常はこちらのやり方を利用することが多いです。, 下のように表示されている行ですが、「child number 0」と表示されています。, 今回は同じSQL(SQL_ID)に対して作成された実行計画が一つだったため、「child number 0」になっています。