Bind Peek をもっと使おうぜ！ 柴田 歩

2

免責事項／注意事項

本資料において示されている見解は、私自身(柴田 歩)の 見解であり、Oracle Corporation 及び 日本オラクル社 の見解を必ずしも反映したものではありません。 予めご了承ください。

3

自己紹介

日本オラクル株式会社 テクノロジーコンサルティング統括本部 DBアーキテクト部 プリンシパルコンサルタント 柴田 歩(しばた あゆむ)

シバタツさん、しばちょうさん に 続く 3人目 の 柴田 !

2007年4月に中途で入社

DBの製品コンサルとして、DB関連のプロジェクトを歴任

4

DDD 2013 で↓のセミナーもやりました

コレ

http://www.oracle.com/technetwork/jp/ondemand/ddd-2013-2051348-ja.html

5

こうならんように、頑張ります。

:::::::: ┌─────────────── ┐ :::::::: ｜ 歩 がやられたようだな | ::::: ┌───└───────────ｖ───┬┘ ::::: ｜ ククク…奴はOracle三柴田の中で最弱 | ┌──└────────ｖ──┬───────┘ ｜ 我ら柴田の面汚しよ │ └────ｖ─────────┘ |ﾐ, ／ ｀ヽ /! ,.──､ |彡/二Oニニ|ノ /三三三!, |! `,' ＼､､＿,|/-ｬ ト `=j r=ﾚ /ミ !彡 ● T 爪| / /￣|/´＿_,ｬ |`三三‐/ |`=､|,='| ＿(＿ /人 ヽ ミ='／|`:::::::/ｲ＿_ ト｀ー く＿＿,-, ､ _!_ / ( ﾟω ﾟ ) / `ー─'" |_,.イ､ | |/､ Y /| | | j / ﾐ`┴'彡＼ ' ` シバタツ しばちょう 恭平 勝家

6

目次

１章. イントロダクション

２章. 前提知識

３章. 統計運用と「Bind Peek(他)」の組み合わせで考える。

４章. まとめ

7

1章. イントロダクション

8

こんなガイド、してませんか？

「ミッションクリティカルなシステムでは Bind Peek は false にして、SQL性能を 安定させることが推奨です。 」

9

烈○王先生 から 一言

10

Bind Peek無効化が安全神話と化してないか？

Bind Peek無効化は昔から言われ続けた結果、

「安全神話」と化しているのではないか？

「安全神話」の意味

– 絶対安全だという信頼感。言外に根拠のない 思い込み、錯覚にすぎないという含みがある。 安全性が保たれている時はこの言葉は使用されず、 崩れた時に使用される。

– hatena keywordより

11

「2000年前～」は言い過ぎだけど、、、

まあ「2000年前～」は言い過ぎなんですけど、Bind Peek無効化 を昔の知識だけで、呪文の ように唱え続るのは良くないすよ(ﾟεﾟ )

– そう云う人は割と多いんじゃないか？？？

Bind Peekの動作や、関連する機能も 振りかえりつつ、もう一度考えてみる。

12

2章. 前提知識

13

Bind Peek の概要

SQLが同じ場合でも、与えられたバインド変数値によって実行計画を使い分ける(最適化する)機能

SELECT * FROM TBL_A WHERE COL1 >= :B1

------------------------------------ | Id | Operation | Name | ------------------------------------ | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL | TBL_A | ------------------------------------

------------------------------------------------- | Id | Operation | Name | ------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS BY INDEX ROWID | TBL_A | | 2 | INDEX RANGE SCAN | TBL_A_I1 | -------------------------------------------------

10000の場合 1の場合

14

10gR2までの動作は...

10gR2までは、初回ハード・パース時のバインド変数値によって作成された実行計画で固定されてしまう。

SELECT * FROM TBL_A WHERE COL1 >= :B1

------------------------------------ | Id | Operation | Name | ------------------------------------ | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL | TBL_A | ------------------------------------

------------------------------------------------- | Id | Operation | Name | ------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS BY INDEX ROWID | TBL_A | | 2 | INDEX RANGE SCAN | TBL_A_I1 | -------------------------------------------------

1の場合 初回のPLAN で固定

・10gR2 までは Bind Peek=false が推奨 ・この推奨が、今日まで続く「安全神話」の始まり

10000の場合

15

11gR1で「優れたカーソル共有」が導入 11gR1からは「優れたカーソル共有(Adaptive Cursor Sharing)」導入で、複数の実行計画を併用するようになった。 – Bind Peek を無効化した場合は、当機能も無効化されます。

SELECT * FROM TBL_A WHERE COL1 >= :B1

------------------------------------ | Id | Operation | Name | ------------------------------------ | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL | TBL_A | ------------------------------------

------------------------------------------------- | Id | Operation | Name | ------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS BY INDEX ROWID | TBL_A | | 2 | INDEX RANGE SCAN | TBL_A_I1 | -------------------------------------------------

10000の場合 1の場合

10gR2までの欠点は、11gR1以降は概ね解消されている。

バインド変数に応じてPLANを使い分け

16

関連機能： Cardinality Feedback の概要

11gR2からの新機能

初回SQL実行時の情報を Feedback して、 ２回目以降の実行計画を最適化する機能

– 実行統計としてのカーディナリティを Feedback

– オプティマイザ統計から算出したカーディナリティと、 実行時のカーディナリティが乖離していた場合に、 ハード・パースを再度実施して実行計画を再作成する。

– KROWN# 147614

17

関連機能：Dynamic Sampling の概要

9iR2からの機能

ハード・パース時にオプティマイザ統計が NULL のテーブル／索引が存在した場合、それらの統計を動的にサンプリングして、実行計画を最適化する機能

– ヒント等で明示的に動作させることも可能

– KROWN#55982

11.2.0.4以降は”動的統計”と云う名称に

12c からは永続情報として、他クエリからも参照可能

18

関連機能：12c の実行計画関連・新機能

適応計画(Adaptive Plan)

– SQLの実行時に予測(実行計画)と実行統計が乖離している場合に、実行計画を予め用意されていたサブプランへ "動的"に切り替えて最適化する機能

SQL計画ディレクティブ

– SQLの予測(実行計画)と実行時でカーディナリティが乖離している場合に、ヒストグラムや拡張統計を採取するためのエントリを保持しておく機能

19

SQLと云う言語の特徴

SQLと云う言語は、データ抽出時に「何を（What）抽出するか」の“条件”のみを記述し、「どうやって(How)抽出するか」を記述しない、他言語には無い特徴を有します。

– 多くの言語では、繰り返し（for～, while～）や 条件分岐（if～, case～）などのアルゴリズムを記述する必要があります。

どうやって（How）データを抽出するか、即ちアルゴリズムの 決定・制御は、RDBMS の Optimizer で行われます。

– Optimizer が決定したアルゴリズム = 実行計画です。

プログラム

“条件”のみを記述

Op

timiz

er

SQL データ

アルゴリズムを決定／制御

※Oracle DBA & Developer Day 2013 資料より

20

SQLのアルゴリズムは「予測」で組み立てられる。

SQL の アルゴリズム≒実行計画 は、オプティマイザが 最適と考えられるものを「予測」して組み立てます。

そして「予測」である以上、必ずハズレのケースが出てきます。

– ハズレの実行計画を引くと、性能問題として顕在化！

– SQLの特徴に由来する、全てのRDBMSに共通した本質的な困難

– 各ベンダやオープンソースのRDBMSは、このSQLの本質的な困難に 立ち向かうべく、日々凌ぎを削っています。(もちろんOracleも！)

まずこのハズレの実行計画の存在を意識／認識しておくのが、 本セミナーの出発点となります。

※Oracle DBA & Developer Day 2013 資料より

21

１枚前で書いた事、とても重要ですYO！

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ | ちょ、ちょーとまって!!!今>>1が何か言ったから静かにして！！ , ,-;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:,.ヽ─ｙ────────────── ,-v-、 /;:;:;:;:;:;:ミミ;:;:;:;:;:;:;:;:;:;`､ / _ﾉ_ﾉ:^) /;:;:;:;:彡―ー-､_;:;:;:;:;:;:;:;| / _ﾉ_ﾉ_ノ ／） |;:;:;:ノ、 `､;;:;:;:;:;:i / ﾉ ﾉノ／／ |;:/＿ヽ ,,,,,,,,,, |;:;:;:;:;:;! ____/ ______ ノ | ' ﾟ ''/ ┌｡-､ |;:;:;:;:/ _.. r（" `ｰ" 、 ﾉ |` ノ( ヽ ソ |ノ|/ _. -‐ '"´ l l-､ ﾞ ノ ＿,-ー| /＿` ”' ＼ ノ __ . -‐ ' "´ l ヽ`ー''"ｰ'" | : | ）ヾ三ﾆヽ /ヽ ' "´／｀ﾞ ｰｧ' "´ ‐'"´ ヽ､`ｰ ／ノ ヽ `､＿＿＿,.-ー' | / / __.. -'-'" | | ＼ / | l / . -‐ '"´ ＼ |＿__＞＜ / ヽ AAが古いのは、赦せ…

22

「予測」と「Bind Peek(他)」の関係

SQLの実行計画は「予測」で組み立てられ、 「予測」である以上、ハズレから逃れられません。

– OracleDB に限らない、全てのRDBMSに共通した困難

そして「Bind Peek」を初めとした実行計画最適化機能は、

全て実行計画の予測精度を上げる、

あるいは予測を補正するために存在します。

– ハズレの実行計画を引く確率を下げる。

– あるいはハズレた予測(実行計画)を補正する。

これらの前提を踏まえた上で、次逝ってみよう！(｀･ω･)Ъ

23

3章. 統計運用と「Bind Peek(他)」の組み合わせで考える。

24

２つのオプティマイザ統計運用

CBO のキモであるオプティマイザ統計は、 実行計画と切っても切れない関係

そしてオプティマイザ統計運用は、(色々な思想は 有るんでしょうが)以下の２つにおよそ大別されます。

– 統計をある断面で固定する「固定化運用」

– 統計を常に最新化する「最新化運用」

25

固定化/最新化 と Bind Peek等 の 組み合わせ

オプティマイザ統計の運用形態によって、 Bind Peek等の実行計画最適化機能を 使うか、使わないかは、変わってくる、、、

「固定化」「最新化」の２つの統計運用と、Bind Peek等の 最適化機能との組み合わせモデルで、考えてみます。

– ①固定化運用＋最適化無し のモデル

– ②最新化運用＋最適化有り のモデル

– ③最新化運用＋最適化無し のモデル

26

①固定化運用＋最適化無し の動作を考える。

①の組み合わせでは、ある断面で固定された、 あるいは 手作りのオプティマイザ統計を基にした、 単一PLANを使い続ける。

– 統計が変動しないので、実行計画は変動しにくい。

– 統計が実態と乖離し易く、最適化機能も無いので 全体的な SQL性能は悪い。

27

①固定化＋最適化無し モデルのSQL処理時間イメージ

時間経過(データ件数)

処理 時間 短

長

PLAN2

単一PLANを 使い続ける

動作するプラン

28

①固定化＋最適化無し モデルの評価

リスクヘッジと云う意味では良い。(そりゃそうだ。)

でも実態と乖離した統計と最適化無しで、SQL性能は悪い。

それと統計を手動でセットしながら固定するのは、 滅茶苦茶大変じゃないですかねぇ、、、(白目

– 行数(NUM_ROWS)／レコード長(AVG_ROW_LEN) ← わかる

– 個別値数(DISTINCT_KEYS)／索引の深さ(BLEVEL) ← まあわかる

– CLUSTERING_FACTOR／AVG_LEAF_BLOCKS_PER_KEY／AVG_DATA_BLOCKS_PER_KEY ↑ ｗｗｗｗｗｗ？？？？ｗｗｗｗｗｗｗｗｗｗｗｗｗ？？？ｗｗ

最後らへんのを出来る人は、良くも悪くも 神／仙人／職人

29

つぎは ②最新化運用＋最適化有り の動作

②の組み合わせでは、常時最新化されたオプティマイザ統計を基にして、複数PLANを使いながら実行計画は変動し続ける。

– フレッシュな統計 と 様々な最適化機能によって、 実行計画の予測精度は高く、全体的な SQL性能 は良い。

– 優れたカーソル共有機能により、複数PLANを併用可能

– 異なる実行計画(予測)の分岐点では、 それらのPLANを併用して少しずつ遷移するイメージ

30

時間経過(データ件数)

処理 時間 短

長

PLAN1 PLAN2 PLAN3

PLAN4

複数PLANのコスト(予測) 近接点で、各PLANを併用しなが ら少しづつ遷移していくイメージ

動作するプラン

②最新化＋最適化有り モデルのSQL処理時間イメージ

31

②最新化＋最適化有り モデルの評価

フレッシュな統計と最適化機能のお陰で、SQL性能は良い。

リスクヘッジと云う意味でも、別に悪くないよ？？？

– ハズレの実行計画を引く確率が低い。(リスクが低い。)

– 加えて各種補正機能で、ハズレを引いた時の 性能劣化も少ない。 (リスクが低い。)

– 更に複数PLAN併用の効果で、実行計画変化に伴う 性能変動が穏やかに出る。(リスクが低い。)

但し性能劣化のリスクを 0(ゼロ) にはできない。何故なら SQL だから。SQL のアルゴリズムは予測だから。

– Bind Peek のせいではない、、、と云うのがポイント

32

最後に ③最新化運用＋最適化無し の動作

③の組み合わせでは、常時最新化されたオプティマイザ統計を基にして、実行計画が変動し続ける。

– 実行計画の予測精度は ② よりも低く、SQL性能は悪い。

– 優れたカーソル共有が無効化されるため、 ある瞬間では単一PLANが使用される。

33

時間経過(データ件数)

処理 時間 短

長

PLAN2

PLAN4

ハズレのPLANを引いた 時の性能劣化が大きい 動作するプ

ラン

PLANのバリエーションも少ない。(列統計／ヒストグラム未使用)

ある瞬間では単一PLANしか選択されない(※複数PLAN併用不可)

③最新化＋最適化無し モデルのSQL処理時間イメージ

34

③最新化＋最適化無し モデルの評価

ハズレの実行計画を引き易いと云う意味で、リスクは高い。

– Bind Peekを無効化すると、列統計／ヒストグラム／拡張統計 を 見なくなる。予測精度を高める上では、相当不利ですよ。

– 複数PLAN併用不可 で 予測補正機能 も無く、 ハズレの実行計画を引いた時のダメージがデカい。

そして 最適化機能無効化(bind peekを無効化、等)は、 統計固定と組み合わせて、初めて意味が出てくる。

– 統計が変動する時点で、実行計画も変動するよ？？？

– それなのに、Bind Peek「だけ」無効化しても意味無くない？？？

35

② と ③ の性能変動モデルケース比較

「赤線」が直線に近いほど、リスクは低い。

どっちが直線に近いか？？？と云うこと

②最新化＋最適化有り ③最新化＋最適化無し

36

解る？前のスライドの意味解りますか？

37

Bind Peek(等)を有効化した方がリスクは低い！

モデルケースの比較にも表れているように、 最新化運用においては最適化機能を有効化した方が リスクは低い！(断言

– 実行計画の種類が少ない = SQL性能が安定、、、ではない。

– 最適化機能の無効化は固定化運用との組み合わせが前提

にも関わらず、どんなシステムでもお構いなく、 「取り敢えず」「無邪気に」「今までやってきたし」 「実績有るから、、、(震え声)」 てな感じに、 Bind Peek を無効化している人達はとても多いのでは？

38

もう一度、良く考え直してみよう。

システムの重要度や体制、アプリケーション特性や 開発／インフラのスキル、最適化機能を on/off する 事のメリデメ等によって、最適な構成や設定、 運用は変わってくるはず。

– 少なくとも、今は Bind Peek無効化一択 の時代じゃない。

– デフォルト設定なので、ナチュラルに使いこなしている お客様／システムも大勢いらっしゃいます(｀･ω･)ゞ

ではどのようなシステムや体制が、この資料で 出してきたモデルにマッチするかと云うと、、、

39

今回はここまで

40

4章. まとめ

41

まとめ

SQLのアルゴリズム＝実行計画は予測で 組み立てられ、予測ゆえのハズレが不可避 – 全ての RDBMS に共通した、SQLが抱える本質的な困難

Bind Peek を初めとした実行計画の最適化機能は、予測精度を向上／補正するための機能 – SQL の本質的な困難に、真正面から挑んでいる！

これらを *安易に* 無効化するのは、非推奨 – 思考停止してませんか？もう一度良く考え直してみましょう。

42

最後にもっかい煽っとく。 Bind Peek(等) を *安易に* 無効化する輩は… …

43

お詫び

全体的に煽り気味なのは、その方が喰い付きが 良いだろうと云う目論見で、他意はありません。

和むように、ようかんマン を置いてきますね。。。

殺伐としたスレに救世主が！

. ＿＿ ヽ|・∀・|ノ ようかんマン |＿＿| | |

44

おわり

ご清聴、ありがとうございました！