私は、「バッチ処理にバインド変数はもうやめません？ ~バッチ処理の突発遅延を題材にして考えてみる~」と題して、バッチ処理における突発的な処理遅延についてお話させていただきました。

少しセッション時間が短かったこともあり、駆け足での一方的な説明になってしまい、Unconferenceというよりは通常のセミナーになってしまったな・・・ と思っていたところ、セッションの最後の質問タイムで、聴講いただいた方と意見の交換をすることができ、Unconference的なエッセンスを入れ込むことができたように思っています（結果オーライw）。 Nさん、ご質問いただきありがとうございました！（感謝感激）

また、幸運なことに、本セッションの前に、SQLのバインド変数化という題材をOLTPの観点で、sh2さんにご説明いただいていました。本セッションではOLTPではなくバッチの観点で説明しましたので、同じ題材をそれぞれのセッションで異なる観点で説明で来た形になり、聞いていただいた方がより理解を深めることができたのではと考えています。sh2さん、ありがとうございました！

• Oracle Database経験者がMySQLの設計思想を知っていろいろ考える会

当日発表に使用した資料を以下においておきます。

さて、ご参加いただいた方は実感されたとは思いますが、日本オラクルさま主催のセッションとはかなり色合いの異なる内容になっています。(マニュアル活用方法を題材にしたエンジニアのスキル向上に関するアドバイスしかり、MySQLとOracle Databaseの比較しかり・・・） 私個人の意見ですが、この点が 日本オラクルさまでなく、JPOUG がイベントを企画する大きな意味であると思っています。 今回のイベントの雰囲気を伝えるtweetは、Oracle OpenWorld Unconference presented by JPOUG - Togetter にまとまっています。（楽しそうでしょ？） 6月を目標に次回イベントを企画中です。企画が進行しだいイベント情報を発信させていただきますので、 ぜひFacebookページに「いいね！」してみてください！

• Facebook - JPOUG fanpage

ご支援いただいた皆様に感謝したいと思います。

Oracle OpenWorld Tokyo 2012事務局のみなさま、OTN事務局のみなさま、Unconferenceをご支援いただきありがとうございました。まだ立ち上がったばかりの団体に対して、貴重な場を提供いただき、まことにありがとうございました。

セッションをご担当いただいたスピーカのみなさま、ありがとうございました。業務などで多忙な状況で、準備や調整を実施いただいたかと思います。みなさまのおかげで、イベント全体のセッション内容を、バリエーションに富んだ、より価値あるものにできました。まことにありがとうございます。

最後に、私のこのような活動に理解を示してくれている、職場のみなさん、ありがとうございます！ 私が心置きなくセッションを担当できたのも、みなさんのおかげです！ 感謝してもしきれません、ありがとう！！！

Unconference とは、少なめの人数でスピーカーとリスナーがいろいろやり合いながらすすめる ユニークな形式のセミナー(?)です。 oracletech.jpにも紹介記事があります。こちらを見ていただくと、よりイメージをつかめるかも・・・

Oracle OpenWorld の特別セッション「Oracle OpenWorld Unconference presented by JPOUG」

場所は 六本木アカデミーヒルズ49 です。以下のURLの地図も合わせてご覧ください！

http://www.oracle.com/openworld/jp-ja/access/index.html

http://www.academyhills.com/forum/room/49/index.html

開催時間帯は、JPUOGメンバーが 誰かしら会場にいるはずです。Oracle製品に携わるエンジニアのお祭りです。楽しみましょう！

なにかご要望やご意見がある方は、Facebookページにコメントを。

Facebook - JPOUG fanpage

ついでに「いいね！」してもらえるとうれしいです。

去年から運営メンバーの一員として打ち合わせなどに参加してきましたが、 JPOUG (Japan Oracle User Group)のWebサイトを立ち上げることができました。

JPOUG (Japan Oracle User Group) - http://www.jpoug.org

あわせて、各種の交流やイベント告知などの情報発信のため、Facebookページも作成しています。 もしよろしければ、アクセスいただき、「いいね！」をお願いいたします。

Facebook - JPOUG fanpage

また、JPOUGがIOUC(International Oracle Users Group Community)へ参加することに決まりました。

http://www.iouc.org/p/cm/ld/fid=45&region=14&gid=590

Oracle製品ユーザーの交流を深めましょう！！

50名強(もしかするとそれ以上)という多くの方にご出席いただいただけでなく、 著名なOracleエンジニア方々の前で話すということで、非常に緊張いたしましたが 主催者の吉田さんのご配慮もあり、楽しい時間をすごすことができました。

• Oracle LOVERS シーズン2 第2回 - oracletech.jp
• Oracle LOVERS シーズン2 第2回 - Zussar

わざわざ貴重なお時間を割いて、ご参加いただいた皆様、ありがとうございました。 実際の業務に有用な情報を1つでもご提供できたらうれしく思います。

また、主催者の吉田さん、いつもありがとうございます。 吉田さんの人柄がなせるものと思いますが、Oracle LOVERSはいつもリラックスした楽しい雰囲気で、 とてもすばらしいですね。 お忙しいとは思いますが、今後もぜひOracle LOVERSを継続していただけたらと思います。

今回の発表資料を公開する予定はありませんが、前半部分のデモで多用した DBMS_XPLAN.DISPLAY_CURSORの使い方については過去のBlogエントリの内容が参考になると 思いますので、以下にリンクを張っておきます。参考にしていただければ幸いです。

• SQLパフォーマンス問題調査でEXPLAIN PLAN、SQLトレースは（ほとんど）使わない
• DBMS_XPLAN.DISPLAY_CURSORの使い方とちょっとした落とし穴
• DISPLAY_CURSORでCBOの見積りミスを簡単に確認する

それでは・・・

しかし、これだけの情報では、実行計画と実行されたSQLのWHERE条件を対応づけて理解することは 難しいです。（できなくはありませんが、かなり推測に頼る形になります。）

SQLのWHERE条件と対応付けるためには、フィルタ述語とアクセス述語に着目する必要があります。

Predicate Informationセクション

実行計画をDBMS_XPLAN.DISPLAY_CURSORで取得した場合、フィルタ述語とアクセス述語に関する情報は Predicate Informationセクションに表示されます。

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |       |       |    20 (100)|          |
|   1 |  NESTED LOOPS                |          |    10 | 40120 |    20   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL          | PA       |     1 |  2004 |     9   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| CH       |    10 | 20080 |    11   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IDX_CHPA |    10 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id): ←★
---------------------------------------------------

   2 - filter("PA"."PID"=1)
   4 - access("CH"."PID"=1)

Predicate Informationセクション内のフィルタ述語、アクセス述語の先頭には オペレーション（ステップ）に対応するIdが記載されています。

フィルタ述語の働き

フィルタ述語は、Predicate Informationではfilter(…)と記載され、 行頭の番号に対応するオペレーションの実行時に、取得したデータから 対象データを抜粋（フィルタ）する処理が実行されたことを示します。

上記の実行計画では、Id=2 TABLE ACCESS FULL において フィルタ述語 filter(”PA”.”PID”=1) が適用されていることがわかります。 これは、表PAを全表スキャンした後に、PA表のデータのうち、pa.pid = 1という 述語（条件）にマッチする行を抜粋したことになります。

SELECT cid, cname, pa.pid, pname FROM ch, pa 
  WHERE ch.pid = pa.pid and pa.pid = 1
                            ^^^^^^^^^^

今回実行したSQL(から不要なヒントを除いて整形したもの)は、上記のとおりですが、 フィルタ述語 filter(”PA”.”PID”=1) の条件は、SQLのWHERE条件に記載された pa.pid = 1 に対応していることがわかります。

アクセス述語の働き

アクセス述語は、Predicate Informationではaccess(…)と記載され、 行頭の番号に対応するオペレーションの実行時に、表示された述語を使用して データにアクセスしたことを示します。 一般に、オペレーションが索引スキャン系(INDEX UNIQUE SCAN, INDEX RANGE SCAN)の場合に指定され、 索引をTraverseする（索引のroot → branch → leafとたどる)ときの索引列の検索条件に対応します。

上記の実行計画では、Id=4 INDEX RANGE SCAN において アクセス述語 access(”CH”.”PID”=1) が適用されていることがわかります。 これは、索引IDX_CHPAの索引列CH.PIDに1という値を持つ索引エントリを探す ことに相当します。

SELECT cid, cname, pa.pid, pname FROM ch, pa 
  WHERE ch.pid = pa.pid and pa.pid = 1
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

アクセス述語 access(”CH”.”PID”=1) は、上記SQLのWHERE条件 ch.pid = pa.pid and pa.pid = 1 を数学的/算術的に変換したものであることが わかります。（推移律 ： pa.pid=1であれば、ch.pid = pa.pidは ch.pid=1となる）

WHERE条件とフィルタ述語、アクセス述語の対応関係

このように、フィルタ条件、アクセス条件を確認すると、 それぞれのオペレーションにおいて、SQLのWHERE条件に対応したデータの絞込みが 行われているかをはっきりと理解することができます。

効率的なSQL実行の鉄則は、初期段階においてデータをできるだけ絞り込むことですので、 万が一、データが意図したように絞り込めていない場合は実行計画を再検討することに なります。その際に、現行の実行計画がどのオペレーションにおいて、どのWHERE条件に 対応したデータの絞込みがなされているかを理解することが重要になります。

フィルタ述語とアクセス述語の違い

フィルタ述語とアクセス述語は、ともに述語に合致したデータのみが得られるという 点で似ていますが、処理効率の観点からは全く異なることに注意してください。

アクセス述語は一般に索引スキャン実行時に指定されますが、 アクセス述語に合致したデータにのみ選択的にアクセスします。 このため、一般にアクセスするブロック数を小さく抑えることができます。

一方、フィルタ述語は、ブロックにアクセスした後のデータを除外する際に 適用されます。アクセスした後にデータを絞り込む形になるため、 一般にアクセスするブロック数は大きくなりがちです。

したがって、どうしてもケースバイケースの側面はありますが、データの絞込みは アクセス述語を使用する索引アクセスで行うことが一般に推奨されます。

SQLトレースの実行計画ではフィルタ述語とアクセス述語が表示されないことに注意

理由は不明ですが、SQLトレースの実行計画にはフィルタ述語とアクセス述語が表示されません。 上記のとおり、フィルタ述語とアクセス述語は実行計画内の各オペレーションの処理内容 を理解するために非常に有効な情報です。

このため、実行計画を確認する際は、フィルタ述語とアクセス述語が出力される DBMS_PLAN.DISPLAY_CURSOR(または類似のファンクション)を使用することを オススメします。

• (*1) 「たどれる」という表現のほうが近いかもしれませんが・・・

オペレーションの一覧

Oracle Databaseには非常に多くのオペレーションが存在し、 大部分のオペレーションについては、マニュアルの以下の箇所で説明されています。

• 10.2
• 11.1
• 11.2

最低限覚えておくべきオペレーション

全てのオペレーションに関して説明することは、現実的でないため、 先のエントリで説明した実行計画に含まれるオペレーションを説明します。 なお、このエントリに含まれるオペレーションは、非常に多くの実行計画で使用されうる、 非常に重要なものであり、最低限覚えておく必要があります。

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |       |       |    20 (100)|          |
|   1 |  NESTED LOOPS                |          |    10 | 40120 |    20   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL          | PA       |     1 |  2004 |     9   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| CH       |    10 | 20080 |    11   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IDX_CHPA |    10 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

なお、上記の実行計画は

SELECT /*+ FULL(PA) INDEX(CH idx_chpa) USE_NL(CH) LEADING(PA) */ 
       cid, cname, pa.pid, pname
   FROM ch, pa    WHERE ch.pid = pa.pid and pa.pid = 1

を実行したときのものです。(*2)

• (*2) 今回の説明の本筋ではないので気にしていただく必要はないのですが、説明に適した実行計画に誘導するために、Multi Join Key Pre-fetchingを無効化しています。

実行イメージ

以下の文章では逐次オペレーションについて説明しますが、この図を参考に読んでいただくと理解しやすいはずです。

TABLE ACCESS (FULL)

実際の実行計画の実行順序に即して説明してゆきます。

この実行計画では、最初にId=2 TABLE ACCESS FULLが実行されます。

|*  2 |   TABLE ACCESS FULL          | PA       |     1 |  2004 |     9   (0)| 00:00:01 |

TABLE ACCESS FULLは指定された表の全体をスキャン（フルスキャン）して、 表に格納された行データを取得するオペレーションです。 仕組みからわかるとおり、取得したい行の数が、表全体の行数に比べて多い場合には 効率的なデータアクセス方法ですが、少ない場合は非効率的です。

この実行計画では、PA表から1行のデータを得たとします。

INDEX RANGE SCAN

この実行計画では、次にId=4 INDEX RANGE SCAN が実行されます。

|*  4 |    INDEX RANGE SCAN          | IDX_CHPA |    10 |       |     1   (0)| 00:00:01 |

Id=2 TABLE ACCESS FULL で得た pa.pid=1にマッチしたPA表の行に該当するデータを CH表から取得するために実行しています。 索引をスキャンし、検索条件にマッチする索引列を含む行の識別子(ROWID)を得ます。

今回の実行計画では、索引列は一意ではないとしています。 この場合は、索引をスキャンするオペレーションの名称はINDEX RANGE SCAN であり、 複数行の識別子(複数のROWID)が返される場合があります。

なお、索引列が一意である場合、すなわち、索引が一意索引であり、検索条件が一意制約が 設定された索引列に対する等価条件である場合、 索引をスキャンするオペレーションの名称はINDEX UNIQUE SCANとなります。 このオペレーションでは、複数行の識別子(複数のROWID)が返されることはありません。 1つ(または0)のROWIDが返されます。

TABLE ACCESS (BY INDEX ROWID)

次に TABLE ACCESS (BY INDEX ROWID)が実行されます。

|   3 |   TABLE ACCESS BY INDEX ROWID| CH       |    10 | 20080 |    11   (0)| 00:00:01 |

Id=4 INDEX RANGE SCAN で得たROWID(のリスト)が示す行データを、CH表から取得します。 ROWIDは行のアドレスに相当する位置情報であるため、ROWIDがわかれば、行データが どのブロックに格納しているかがわかります。

NESTED LOOP

Id=1 NESTED LOOPS の子オペレーションの実行がすべて終了したため、 次は、Id=1 0 NESTED LOOPSが実行されます。

|   1 |  NESTED LOOPS                |          |    10 | 40120 |    20   (0)| 00:00:01 |

NESTED LOOPSオペレーションは、複数の表の行データを結合する結合オペレーションの 1つで、文字通り入れ子ループのような処理モデルに従い、結合処理を実行します。

具体的には、上側の子オペレーションで得たデータに対して、対応するデータを 下側の子オペレーションを介して取得して結合する処理となります。 上側の子オペレーションで得たデータが複数行である場合、1つの行ごとに下側の子オペレーション の処理が実行されるため、下側の子オペレーションは複数回実行される場合があります。

このような動作は、プログラミング言語における入れ子の制御ループに似ていることから、 NESTED LOOPによばれているようです。

for (int i; i < 10; i++){   → Id=2 TABLE ACCESS FULL に対応
  for (int j; j < 10; j++{  → Id=3 TABLE ACCESS BY INDEX ROWIDに対応

  }
}

先の例では、上側の子オペレーションであるId=2 TABLE ACCESS FULLで 得られた行数が1でしたが、仮に2だった場合は、 Id=3 TABLE ACCESS BY INDEX ROWIDは2回実行されます。

そのほかの結合オペレーション

NESTED LOOP(ネステッドループ結合)以外の結合オペレーションとして、HASH JOIN (ハッシュ結合)、 MERGE JOIN(ソートマージ結合)の2つがありますが、これらについては追って説明します。

Oracle Database Userのみなさんに役立つ活動を行っていきたいと思います！ 何かご意見がありましたら、twitterやblogのコメント欄で頂戴できればうれしいです！

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'LAST'));

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID  dvv5bah5b4k51, child number 1
-------------------------------------
SELECT /*+ FULL(PA) INDEX(CH idx_chpa) USE_NL(CH) LEADING(PA) */ cid,
cname, pa.pid, pname    FROM ch, pa    WHERE ch.pid = pa.pid and pa.pid
= 1

Plan hash value: 3514264536

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |       |       |    20 (100)|          |
|   1 |  NESTED LOOPS                |          |    10 | 40120 |    20   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL          | PA       |     1 |  2004 |     9   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| CH       |    10 | 20080 |    11   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IDX_CHPA |    10 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("PA"."PID"=1)
   4 - access("CH"."PID"=1)


24 rows selected.

実行計画のツリー構造とオペレーションの親子関係

実行計画は、一般に複数のオペレーションから構成されます。オペレーションは、親子関係に したがってインデントして整形されたツリー構造となります。

たとえば、上記の実行計画は、NESTED LOOPS, TABLE ACCESS FULL などのオペレーション から構成されます。(オペレーションの種類と処理内容については次のエントリで説明します。）

オペレーションの親子関係についてですが、 Id=1 NESTED LOOPSは Id=2 TABLE ACCESS FULLと、Id=3 TABLE ACCESS BY INDEX ROWID の親となります。同様に Id=3 TABLE ACCESS BY INDEX ROWID Id= 4 INDEX RANGE SCAN の親となります。

                Id=0 SELECT STATEMENT
                       ↑
                       │行ソース
                       │
                Id=1 NESTED LOOPS 
                     ↑  ↑
 行ソース┌─────┘  └─────┐行ソース
         │                          │
Id=2 TABLE ACCESS FULL      Id=3 TABLE ACCESS BY INDEX ROWID
                                     ↑
                                     │行ソース
                                     │
                            Id=4 INDEX RANGE SCAN

それぞれのオペレーションは、行ソースとよばれる表から取得した行データ（のサブセット）を出力します。 親オペレーションは子オペレーションの行ソースを入力として処理を行います。

概念的な説明だけではわかりにくいので、先の実行計画がどのように処理されるかを イメージしながら、読み方を説明してみましょう。

実行計画で一番最初に実行されるオペレーションを探す

まず、この実行計画で一番最初に実行される(*1) オペレーションを探します。 最も最上位のオペレーション(Id=0 SELECT STATEMENT)にポイントしてから、そのオペレーションの 子オペレーションをたどります。 子オペレーションが2つ以上ある場合は、上側に表記されたオペレーションをたどります。 子の子、子の子の子、とインデントされたオペレーションを順にたどってゆき、 子がなくなった時点でポイントしていたオペレーションが、 実行計画で一番最初に実行されるオペレーションです。

先の実行計画の例において、一番最初にオペレーションを特定するまでの手順は以下の とおりです。

• 1. 最も最上位のオペレーション(Id=0 SELECT)をポイント
• 2. Id=0 SELECTの子オペレーションはId=1 NESTED LOOPSだけなので、NESTED LOOPSをポイント
• 3. Id=1 NESTED LOOPSの子オペレーションとして、2つのオペレーション Id=2 TABLE ACCESS FULL と Id=3 TABLE ACCESS BY INDEX ROWID があるが、上側に表示されている Id=2 TABLE ACCESS FULLをたどる。
• 4. Id=2 TABLE ACCESS FULL には、子オペレーションがないため、 このオペレーションがこの実行計画で最初に実行されるオペレーションとなる

一番深くインデントされたオペレーションが必ずしも一番最初に実行される わけではないことに注意が必要です。 上記の例でも、一番深くインデントされたオペレーションである Id=4 INDEX RANGE SCAN は一番最初に実行されるオペレーションではありません。

• (*1)「実質的な意味で」一番最初に実行されるオペレーションという意味です。 形式的には、Id=0のSELECT STATEMENTが一番最初に実行されるオペレーションですが、この観点は理解するうえであまり意味がないからです。

以後のオペレーション実行順序

さて、最初に実行されるオペレーションが Id=2 TABLE ACCESS FULL であることはわかりました、以降、どのような順序でオペレーションが実行される のでしょうか。順に追っていきましょう。

• 5. Id=2 TABLE ACCESS FULL は、PA表をテーブルスキャン（全行取得）する オペレーションであり、取得した結果を親オペレーションId=1 NESTED LOOPに 渡す。
• 6. Id= 1 NESTED LOOP は、自分の子オペレーションのうち、次に実行すべき オペレーションを探す。ここでは、Id= 3 TABLE ACCESS BY INDEX ROWIDが 未実行であるため、Id= 3 TABLE ACCESS BY INDEX ROWID をポイントする。
• 7. Id= 3 TABLE ACCESS BY INDEX ROWID は自分の子オペレーションである、 Id= 4 INDEX RANGE SCAN をポイントする。
• 8. Id= 4 INDEX RANGE SCAN には子オペレーションがないため、 Id= 4 INDEX RANGE SCAN の処理を実行する。 索引IDX_CHPAをレンジスキャン（範囲検索）し、表に格納された行の識別子 である、ROWIDのリストを得て、取得した結果を親オペレーション Id= 3 TABLE ACCESS BY INDEX ROWID に渡す。
• 9. Id= 3 TABLE ACCESS BY INDEX ROWI Dは Id= 4 INDEX RANGE SCAN より得たROWIDの リストに従い、表から行データを取得し、取得した結果を親オペレーション Id= 1 NESTED LOOPに渡す。
• 10. Id= 1 NESTED LOOP のすべての子オペレーションの実行が完了したため、 自オペレーションの処理である Nested Loop 結合処理を実行して、結果を 親オペレーションId=0 SELECTに渡す。
• 11. Id=0 SELECTは擬似的なオペレーションであり、実際の処理は行わないため、ここで終了

このような順序となります。

ルール化するならば

先に説明した手順をルール化するならば、以下のようにまとめられます。 （わかりやすくするため厳密性を犠牲にしています。）

• 1. 自オペレーションの処理は、すべての子オペレーションの処理が完了してから実行される。
• 2. 子オペレーションがない場合、自オペレーションを実行できる。
• 3. あるオペレーションに子オペレーションが複数ある場合、上側に記載された子 オペレーションが先に実行される。

しかし、当たり前の話ですが、実行計画を取得できたとしても、読めなければ意味がありません。 このため、取得した実行計画の読み方をこれからいくつかのエントリで説明したいと思います。

以下の構成で進める予定です。（エントリ記載次第、リンクを張る予定）

• 実行計画のツリーのたどり方
• オペレーションの一覧と最低限覚えておくべきオペレーション
• フィルタ述語とアクセス述語
• 結合の動作イメージとオペレーション

自身の経験上、実行計画の読み方は一度の説明で理解しにくいようです。 このため、一連のエントリでは、わざと同じようなことを何度も繰り返し説明するような 形にしています。

しかし、この作業は簡単なものではありません。 先のエントリ の例は、1つのテーブルにのみアクセスするきわめてシンプルなものであり、 テーブルスキャン(TABLE ACCESS FULL) よりもインデックススキャン (INDEX RANGE SCAN) が効率的であるとすぐにわかりました。 しかし、通常のアプリケーションではSQLはもっと複雑であり、 最適な実行計画の検討は、Oracle Databaseに関するSQLチューニングスキルが必要であり、時間もかかる作業です。

Oracle Database 9.2 以前など、アドバイザ機能が充実していなかったバージョンを 使用していたときは、スキルを持ったデータベースエンジニアが、さまざまな角度から 検討し、最適と思われる実行計画を検討していたと思います。 この作業は、実際に効果が得られるかどうか不透明なわりに、時間と労力を要する非効率的なものでした。 チューニング作業は、時間をかければかけただけ、必ず改善されるという保障があるわけではないという 側面があるからです。

Oracle Database 10g以後では、アドバイザ機能が充実し、SQLチューニングアドバイザ を活用して、Oracle Database が自動的に最適な実行計画を作成してくれるように なっており、作業コストを大幅に削減できます。 しかし、SQLチューニングアドバイザを使用するためには Enterprise Edition の利用に くわえて、別売のオプション機能 Diagnostic Pack と Tuning Packが必要であるため、 使用できる人が限られるのが現実ではないでしょうか。

動的サンプリングによる最適な実行計画検討の自動化

実は、動的サンプリングという機能を使うことで、SQLチューニングアドバイザが使用で きない場合でも、最適と思われる実行計画の検討をOracle Database任せにすることが できます。

動的サンプリングは、SQLの実行前に、SQLがアクセスするテーブルのデータをサンプリングし、 サンプリングした結果を元にCBOがSQLの実行計画を作成する機能です。 通常の場合、すなわち動的サンプリングが実行されない場合、 CBOはオプティマイザ統計を元に実行計画を作成します。オプティマイザ統計は データの特性を集約したサマリ情報 （具体的には行の平均長や列値の最小値・最大値、ヒストグラムなど）に過ぎないため、 仮にオプティマイザ統計が最新の状態であっても、CBOのコスト予測が外れて最適な 実行計画が作成されない場合がないのは、先のエントリで示したとおりですが、 実際のデータをサンプリングすれば、予測が外れる可能性を大幅に減らすことが できます（実際にデータを先読みしているので、予測が当たるのは当たり前といえば当たり前ですが・・・）。

では、初期化パラメータOPTIMIZER_DYNAMIC_SAMPLING を指定して、動的サンプリングを 有効にしてから、先のエントリのSQLを実行し、Oracle Database が最適と判断した実行計画を 見てみましょう。

なんと！（わざとらしいですね）想定どおりのインデックススキャン(INDEX RANGE SCANオペレーション) を用いた実行計画が選択されました！

SQL> alter session set statistics_level=ALL;
セッションが変更されました。

SQL> alter session set OPTIMIZER_DYNAMIC_SAMPLING=10;
セッションが変更されました。

SQL> SELECT sum(val1) FROM tbl0 WHERE flg1 = 'X' AND flg2 = 'X';
 SUM(VAL1)
----------
         1

SQL> select * from table(DBMS_XPLAN.display_cursor('42fxsw7fcxuht',0, 'ALL ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  42fxsw7fcxuht, child number 0
-------------------------------------
SELECT sum(val1) FROM tbl0 WHERE flg1 = 'X' AND flg2 = 'X'

Plan hash value: 1204532613

------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |      1 |        |       |     2 (100)|          |      1 |00:00:00.01 |       3 |
|   1 |  SORT AGGREGATE              |           |      1 |      1 |     7 |            |          |      1 |00:00:00.01 |       3 |
|   2 |   TABLE ACCESS BY INDEX ROWID| TBL0      |      1 |      1 |     7 |     2   (0)| 00:00:01 |      1 |00:00:00.01 |       3 |
|*  3 |    INDEX RANGE SCAN          | IDX0_TBL0 |      1 |      1 |       |     1   (0)| 00:00:01 |      1 |00:00:00.01 |       2 |
------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1
   2 - SEL$1 / TBL0@SEL$1
   3 - SEL$1 / TBL0@SEL$1

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("FLG1"='X' AND "FLG2"='X')

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - (#keys=0) SUM("VAL1")[22]
   2 - "VAL1"[NUMBER,22]
   3 - "TBL0".ROWID[ROWID,10]

Note
-----
   - dynamic sampling used for this statement (level=10) ←★


38行が選択されました。

動的サンプリングが実行された場合は、Noteセクションにその旨の表示がされることに 注意してください。ここで動的サンプリングの実行有無をチェックできます。

動的サンプリングレベルには0から10を指定でき、マニュアルでは基本的にサンプリング 対象のブロック数に影響するような表記があります。 しかし、ブロック数だけではなく、動的サンプリングの実行有無の 判断にも使用されるようです（小さいレベルを指定すると動的サンプリングが実行されないような動作が見られる場合もある模様・・・詳細不明）。

動的サンプリングを用いて作成された実効計画が適切であると判断できる場合は、 この実行計画に近づくように、元のSQLにヒントを追加したりするなどして、 元のSQLがこの実行計画で実行されるようにするよう誘導することもできます。

なお、動的サンプリングの結果は共有プールに保管され、再利用されるようです。 毎回動的サンプリングを実行するのはナンセンスですので、妥当な動作であると思われますが、 再利用のロジックが明確でないため、いわゆるアプリケーションからのSQL実行時において 動的サンプリングを使用することには十分な検討が必要です。（特にサンプリングレベルの設定）

ではSQLチューニングアドバイザは不要か？

動的サンプリングは非常に便利な機能です。 しかし、動的サンプリングがあれば、SQLチューニングアドバイザが不要かというと そんなことはありません。 SQLチューニングアドバイザでは、アドバイザ結果をSQLプロファイルして提供すること があります。SQLプロファイルは最適な実行計画を選ぶことを可能にする補足的な統計であり、 ヒントと異なり、実行計画を完全に固定する情報ではありません。 したがって、データ量が増減して最適な実行計画が変化した場合でも、それに追従することができます。 ヒントではこのような柔軟な処理は実現できません（ターゲットとする実行計画が変化するたびに、 それに応じてヒントを書き換える必要があります）。

また、動的サンプリングを用いる方法では、実行計画の誘導作業を自動化することが できません。SQLにヒントを埋め込む作業は、SQLをコーディングするエンジニアが行う必要があります。

したがって、あくまでも動的サンプリングを用いる方法は、「SQLチューニングアドバイザ が利用できない環境で、やむを得ず使用する方法」と位置づけることが妥当でしょう。