Bind Peek をもっと使おうぜ！(柴田歩) - JPOUG Advent Calendar 2014(Day 5) -

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の動作や、関連する機能も
振りかえりつつ、もう一度考えてみる。

14
10gR2までの動作は...
 10gR2までは、初回ハード・パース時のバインド変数値
によって作成された実行計画で固定されてしまう。
------------------------------------
------------------------------------
------------------------------------
-------------------------------------------------
-------------------------------------------------
-------------------------------------------------
1の場合初回のPLAN
で固定
・10gR2 までは Bind Peek=false が推奨
・この推奨が、今日まで続く「安全神話」の始まり
10000の場合

15
11gR1で「優れたカーソル共有」が導入
 11gR1からは「優れたカーソル共有(Adaptive Cursor
Sharing)」導入で、複数の実行計画を併用するようになった。
– Bind Peek を無効化した場合は、当機能も無効化されます。
------------------------------------
------------------------------------
------------------------------------
-------------------------------------------------
-------------------------------------------------
-------------------------------------------------
1の場合 10000の場合
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 が決定したアルゴリズム = 実行計画です。
プログラム
“条件”のみを記述
Optimizer
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無効化一択の時代じゃない。
– デフォルト設定なので、ナチュラルに使いこなしている
お客様／システムも大勢いらっしゃいます(｀･ω･)ゞ
 ではどのようなシステムや体制が、この資料で
出してきたモデルにマッチするかと云うと、、、

41
まとめ
SQLのアルゴリズム＝実行計画は予測で
組み立てられ、予測ゆえのハズレが不可避
– 全ての RDBMS に共通した、SQLが抱える本質的な困難
Bind Peek を初めとした実行計画の最適化機能
は、予測精度を向上／補正するための機能
– SQL の本質的な困難に、真正面から挑んでいる！
これらを *安易に* 無効化するのは、非推奨
– 思考停止してませんか？もう一度良く考え直してみましょう。

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

43
お詫び
 全体的に煽り気味なのは、その方が喰い付きが
良いだろうと云う目論見で、他意はありません。
 和むように、ようかんマンを置いてきますね。。。
殺伐としたスレに救世主が！
. ＿＿
ヽ|・∀・|ノようかんマン
|＿＿|
| |

44
おわり
ご清聴、ありがとうございました！

Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -

More Related Content

What's hot

Viewers also liked

Similar to Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -