JPOUG Advent Calendar 2015 の Day9 です。 Oracle Database の オプティマイザ統計運用 について語ってます。

1. まだ統計固定で消耗してるの？
- Bind Peek をもっと使おうぜ！ 2015 Edition -
柴田 歩

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

3. 3
自己紹介
 日本オラクル株式会社
クラウド・テクノロジーコンサルティング統括本部
DBアーキテクト部
プリンシパルコンサルタント
柴田 歩(しばた あゆむ)
 シバタツさん、しばちょうさん に 続く 3人目 の 柴田 !
 2007年4月に中途で入社
 DBの製品コンサルとして、DB関連のプロジェクトを歴任

4. 4
コンテンツ
コレ
 DDD 2013 SQLチューニングに必
要な考え方と最新テクニック
 http://www.oracle.com/technet
work/jp/ondemand/ddd-2013-
2051348-ja.html
 ブログ「ねら～ITエンジニア雑記」
 http://d.hatena.ne.jp/gonsuke77
7/
 Bind Peek を もっと使おうぜ！
-JPOUG Advent Calendar 2014-
 http://d.hatena.ne.jp/gonsuke77
7/20141205/1417710300

5. 5
こうならんように、今年も頑張ります。
:::::::: ┌─────────────── ┐
:::::::: ｜ Oracle の AYU がやられたようだな |
::::: ┌───└───────────ｖ───┬┘
::::: ｜ ククク…奴は我ら 四AYUの中で最弱 |
┌──└────────ｖ──┬───────┘
｜ 我々 AYU四天王 の面汚しよ │
└────ｖ─────────┘
|ﾐ, ／ ｀ヽ /! ,.──､
|彡/二Oニニ|ノ /三三三!, |!
`,' ＼､､＿,|/-ｬ ト `=j r=ﾚ /ミ !彡
T 爪| / /￣|/´＿_,ｬ |`三三‐/ |`=､|,='| ＿(＿
/人 ヽ ミ='／|`:::::::/ｲ＿_ ト｀ー く＿＿,-, ､ _!_ / ( ﾟω ﾟ )
/ `ー─'" |_,.イ､ | |/､ Y /| | | j / ﾐ`┴'彡＼ ' `
五郎丸 歩 浜崎あゆみ いしだあゆみ 吉田歩美

6. 6
目次
 １章. イントロダクション
 ２章. 前提知識
 ３章. 統計運用と「Bind Peek(他)」の組み合わせで考える。
 ４章. まとめ

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

8. 8
今年のお題
まだ統計固定で
消耗してるの？
– 某有名ブロガーのブログ名より拝借しますた。

9. 9
こんなガイド、してませんか？
「ミッションクリティカルなシステムでは
オプティマイザ統計を固定して
実行計画を安定させることが推奨です。 」

10. 10
範馬刃牙さん から 一言

11. 11
統計固定は果たして安全なんだろうか？
 最近対応したSQL性能トラブルのやり取り ※全て統計固定の環境
彡(ﾟ)(ﾟ) 「MView実体表の統計が0件やで。実行計画悪いやで。」
(´･ω･｀)「すみません。MViewって統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「索引の統計が0件で、実行計画悪いやで。」
( ^ω^) 「ごめんね。索引って統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「エンドユーザ様が使う研修環境の統計が0件/Null統計の嵐で、
まともなSQL性能が出てないンゴよ。お客さん激おこやで。」
(*^○^*)「研修環境なんて知らないんだ！本番しか管理しないんだ！研修環
境はデータ少ないのに、変な実行計画を選ぶOracleが悪いんだ！」
彡()()「」

12. 12
統計固定はデメリットも多いのだが、、、
 統計固定はデメリットも多いのだけど、
そのデメリットには余り目が向いてない気がする。
 にも関わらず、そのデメリットを考慮せずに
統計固定 を呪文のように唱え続るのは良くないすよ(ﾟεﾟ )
– そう云う人は割と多いんじゃないか？？？
 Bind Peek等、実行計画で関連する機能も
振りかえりつつ、もう一度考えてみる。

13. 13
2章. 前提知識

14. 14
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の場合
去年のBind Peek をもっと使おうぜ！より

15. 15
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の場合
去年のBind Peek をもっと使おうぜ！より

16. 16
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を使い分け
去年のBind Peek をもっと使おうぜ！より

17. 17
関連機能： Cardinality Feedback の概要
 11gR2からの新機能
 初回SQL実行時の情報を Feedback して、
２回目以降の実行計画を最適化する機能
– 実行統計としてのカーディナリティを Feedback
– オプティマイザ統計から算出したカーディナリティと、
実行時のカーディナリティが乖離していた場合に、
ハード・パースを再度実施して実行計画を再作成する。
– KROWN# 147614
去年のBind Peek をもっと使おうぜ！より

18. 18
関連機能：Dynamic Sampling の概要
 9iR2からの機能
 ハード・パース時にオプティマイザ統計が NULL の
テーブル／索引が存在した場合、それらの統計を動的
にサンプリングして、実行計画を最適化する機能
– ヒント等で明示的に動作させることも可能
– KROWN#55982
 11.2.0.4以降は”動的統計”と云う名称に
 12c からは永続情報として、他クエリからも参照可能
去年のBind Peek をもっと使おうぜ！より

19. 19
SQLと云う言語の特徴
 SQLと云う言語は、データ抽出時に「何を（What）抽出するか」
の“条件”のみを記述し、「どうやって(How)抽出するか」を記述
しない、他言語には無い特徴を有します。
– 多くの言語では、繰り返し（for～, while～）や
条件分岐（if～, case～）などのアルゴリズムを記述する必要があります。
 どうやって（How）データを抽出するか、即ちアルゴリズムの
決定・制御は、RDBMS の Optimizer で行われます。
– Optimizer が決定したアルゴリズム = 実行計画です。
プログラム
“条件”のみを記述
OptimizerSQL データ
アルゴリズムを決定／制御
※Oracle DBA & Developer Day 2013 資料より

20. 20
SQLのアルゴリズムは「予測」で組み立てられる。
 SQL の アルゴリズム≒実行計画 は、オプティマイザが
最適と考えられるものを「予測」して組み立てます。
 そして「予測」である以上、必ずハズレのケースが出てきます。
– ハズレの実行計画を引くと、性能問題として顕在化！
– SQLの特徴に由来する、全てのRDBMSに共通した本質的な困難
– 各ベンダやオープンソースのRDBMSは、このSQLの本質的な困難に
立ち向かうべく、日々凌ぎを削っています。(もちろんOracleも！)
 まずこのハズレの実行計画の存在を意識／認識しておくのが、
本セミナーの出発点となります。
※Oracle DBA & Developer Day 2013 資料より

21. 21
「予測」と「Bind Peek(他)」の関係
 SQLの実行計画は「予測」で組み立てられ、
「予測」である以上、ハズレから逃れられません。
– OracleDB に限らない、全てのRDBMSに共通した困難
 そして「Bind Peek」を初めとした実行計画最適化機能は、
全て実行計画の予測精度を上げる、
あるいは予測を補正するために存在します。
– ハズレの実行計画を引く確率を下げる。
– あるいはハズレた予測(実行計画)を補正する。
 これらの前提を踏まえた上で、次逝ってみよう！(｀･ω･)Ъ
去年のBind Peek をもっと使おうぜ！より

22. 22
12c新機能：SQL計画ディレクティブの概要
 SQL計画ディレクティブ
– SQLの予測(実行計画)と実行時でカーディナリティが乖
離している場合に、ヒストグラムや拡張統計を採取する
ためのエントリを保持しておく機能
– 統計最新化と併用することで、不足しているヒストグラ
ムや拡張統計が自動採取され、実行計画の予測精度が上
がってSQL性能向上が期待できる。
– 加えて、SQL計画ディレクティブが存在する状態でヒス
トグラムや拡張統計が採取されていない場合、動的統計
が採取されてヒストグラム／拡張統計を代替します。

23. 23
 SQL計画ディレクティブにより、SQL性能が改善
09:21:12 SQL> SELECT /*+ MONITOR */
09:21:12 2 DTL.*
09:21:12 3 FROM SALES SAL
09:21:12 4 , SALES_DETAIL DTL
09:21:12 5 WHERE SAL.RECEIPT_NUM = DTL.RECEIPT_NUM
09:21:12 6 AND TO_CHAR(SAL.SALES_DATE, 'YYYYMMDD')
09:21:12 7 = '20151101';
:
:
:
:
:
:
:
:
:
:
統計
----------------------------------------------------------
:
4301 consistent gets
0 physical reads
:
09:22:36 SQL> SET AUTOTRACE TRACEONLY;
09:22:36 SQL> -- aqkqdv23rmnj7
09:22:36 SQL> SELECT /*+ MONITOR */
09:22:36 2 DTL.*
09:22:36 3 FROM SALES SAL
09:22:36 4 , SALES_DETAIL DTL
09:22:36 5 WHERE SAL.RECEIPT_NUM = DTL.RECEIPT_NUM
09:22:36 6 AND TO_CHAR(SAL.SALES_DATE, 'YYYYMMDD')
09:22:36 7 = '20151101';
:
:
:
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- 1 Sql Plan Directive used for this statement
:
統計
----------------------------------------------------------
:
58 consistent gets
0 physical reads
:
SQL計画ディレクティブ と
動的統計 が同時に動作
SQL計画ディレクティブによる性能改善例
論理読込が大幅減少
して性能改善！

24. 24
SQL計画ディレクティブ動作時のSQL監視レポート
 Before
SQL計画
ディレク
ティブ
無効時
 After
SQL計画
ディレク
ティブ
有効時
================================================================…============…===================
| Id | Operation | Name | Rows |…| Rows |…| Activity Detail |
| | | | (Estim) |…| (Actual) |…| (# samples) |
================================================================…============…===================
| 0 | SELECT STATEMENT | | |…| 1 |…| |
| 1 | NESTED LOOPS | | 1 |…| 1 |…| Cpu (2) |
| 2 | NESTED LOOPS | | 1 |…| 870K |…| Cpu (12) |
| 3 | TABLE ACCESS FULL | SALES_DETAIL | 1 |…| 870K |…| |
| 4 | INDEX UNIQUE SCAN | SALES_PK | 1 |…| 870K |…| |
| 5 | TABLE ACCESS BY INDEX ROWID | SALES | 1 |…| 1 |…| |
================================================================…============…===================
===================================================================…============…===================
| Id | Operation | Name | Rows |…| Rows |…| Activity Detail |
| | | | (Estim) |…| (Actual) |…| (# samples) |
===================================================================…============…===================
| 0 | SELECT STATEMENT | | |…| 1 |…| |
| 1 | NESTED LOOPS | | 1 |…| 1 |…| |
| 2 | NESTED LOOPS | | 1 |…| 1 |…| |
| 3 | TABLE ACCESS FULL | SALES | 1 |…| 1 |…| |
| 4 | INDEX RANGE SCAN | SALES_DETAIL_I1 | 1 |…| 1 |…| |
| 5 | TABLE ACCESS BY INDEX ROWID | SALES_DETAIL | 1 |…| 1 |…| |
===================================================================…============…===================
結合の駆動表(外部表)が
870,000件で予測(Estim・
1件)と大幅にズレている。
予測(Estim) と 実測
(Actual)の差が無くなり、
適切な実行計画が
選択されている。

25. 25
 DBA_SQL_PLAN_DIRECTIVES／DBA_SQL_PLAN_DIR_OBJECTS
の両ディクショナリから、SQL計画ディレクティブの中身を垣間見れます。
– JOIN CARDINALITY～ や GROUP BY CARINALITY～等、色々と痕跡が残っている模様
SELECT DIRECTIVE_ID, REASON FROM DBA_SQL_PLAN_DIRECTIVES ORDER BY DIRECTIVE_ID;
DIRECTIVE_ID REASON
---------------------- ------------------------------------
:
1728506075998422865 GROUP BY CARDINALITY MISESTIMATE
1759424373409547847 JOIN CARDINALITY MISESTIMATE
1867368094826446021 SINGLE TABLE CARDINALITY MISESTIMATE
:
SELECT DIRECTIVE_ID, OWNER, OBJECT_NAME, SUBOBJECT_NAME FROM DBA_SQL_PLAN_DIR_OBJECTS
WHERE OWNER = 'AYSHIBAT' ORDER BY DIRECTIVE_ID;
DIRECTIVE_ID OWNER OBJECT_NAME SUBOBJECT_NAME
---------------------- --------- -------------- --------------------
5073690180799161771 AYSHIBAT SALES_DETAIL
:
11717631835078839377 AYSHIBAT SALES_DETAIL RECEIPT_NUM
16570908913880212990 AYSHIBAT SALES SALES_DATE
:
SQL計画ディレクティブ の 中身

26. 26
12c新機能：適応計画(Adaptive Plan)の概要
 適応計画(Adaptive Plan)の概要は以下の通り
– SQLの実行時に予測(実行計画)と実行統計が乖離してい
る場合に、実行計画を予め用意されていたサブプランへ
"動的"に切り替えて最適化する機能
– もっと具体的に言うと、NESTED LOOPS の
駆動表(外部表)の実測(Actual)が、予測(Estimate)と
大幅に乖離している場合に、結合操作を HASH JOIN に
"動的"に切り替えて性能劣化を防ぐ働きをする。

27. 27
 適応計画(Adaptive Plan)により、SQL性能が改善
06:51:22 SQL> SELECT /*+ MONITOR */
06:51:22 2 DTL.*
06:51:22 3 FROM SALES SAL
06:51:22 4 , SALES_DETAIL DTL
06:51:22 5 WHERE SAL.RECEIPT_NUM = DTL.RECEIPT_NUM
06:51:22 6 AND TO_CHAR(SAL.SALES_DATE, 'YYYYMMDD')
06:51:22 7 = '20151102';
870000行が選択されました。
:
:
:
:
:
:
統計
----------------------------------------------------------
：
178364 consistent gets
1885 physical reads
:
06:51:35 SQL> SELECT /*+ MONITOR */
06:51:35 2 DTL.*
06:51:35 3 FROM SALES SAL
06:51:35 4 , SALES_DETAIL DTL
06:51:35 5 WHERE SAL.RECEIPT_NUM = DTL.RECEIPT_NUM
06:51:22 6 AND TO_CHAR(SAL.SALES_DATE, 'YYYYMMDD')
06:51:22 7 = '20151102';
870000行が選択されました。
:
Note
-----
- this is an adaptive plan
統計
----------------------------------------------------------
:
3879 consistent gets
1962 physical reads
:
適応計画(Adaptive Plan)が有効
適応計画(Adaptive Plan)による性能改善例
論理読込が大幅減少
して性能改善！

28. 28
適応計画動作時 の SQL監視レポート
 Before
適応計画
無効時
 After
適応計画
有効時
================================================================…============…===================
| Id | Operation | Name | Rows |…| Rows |…| Activity Detail |
| | | | (Estim) |…| (Actual) |…| (# samples) |
================================================================…============…===================
| 0 | SELECT STATEMENT | | |…| 870K |…| Cpu (1) |
| 1 | NESTED LOOPS | | 1 |…| 870K |…| |
| 2 | NESTED LOOPS | | 1 |…| 870K |…| |
| 3 | TABLE ACCESS FULL | SALES_DETAIL | 1 |…| 870K |…| |
| 4 | INDEX UNIQUE SCAN | SALES_PK | 1 |…| 870K |…| |
| 5 | TABLE ACCESS BY INDEX ROWID | SALES | 1 |…| 870K |…| |
================================================================…============…===================
=================================================================…============…==============================
| Id | Operation | Name | Rows |…| Rows |…| Activity Detail |
| | | | (Estim) |…| (Actual) |…| (# samples) |
=================================================================…============…==============================
| 0 | SELECT STATEMENT | | |…| 870K |…| |
| 1 | HASH JOIN | | 1 |…| 870K |…| direct path write temp (1) |
| 2 | NESTED LOOPS | | 1 |…| 1 |…| |
| 3 | NESTED LOOPS | | 1 |…| 1 |…| |
| 4 | STATISTICS COLLECTOR | | |…| 870K |…| |
| 5 | TABLE ACCESS FULL | SALES_DETAIL | 1 |…| 870K |…| |
| 6 | INDEX UNIQUE SCAN | SALES_PK | 1 |…| |…| |
| 7 | TABLE ACCESS BY INDEX ROWID | SALES | 1 |…| |…| |
| 8 | TABLE ACCESS FULL | SALES | 1 |…| 2900 |…| |
=================================================================…============…==============================
NLの駆動表(外部表)が
870,000件で、
内部表に870,000回
アクセスしている。
結合の駆動表(外部表)が
870,000件で予測(Estim・
1件)と大幅にズレている。
NLは動作していない。
(Actual が Null)
HJが動作している。

29. 29
予測／実測が乖離していない場合は…
 適応計画(Adaptive Plan)が有効な実行計画でも、
予測と実測の乖離が無い場合は、素直にNL結合します。
====================================================================…============…=
| Id | Operation | Name | Rows |…| Rows |…|
| | | | (Estim) |…| (Actual) |…|
====================================================================…============…=
| 0 | SELECT STATEMENT | | |…| 0 |…|
| 1 | HASH JOIN | | 300 |…| 0 |…|
| 2 | NESTED LOOPS | | 300 |…| 1 |…|
| 3 | NESTED LOOPS | | 300 |…| 1 |…|
| 4 | STATISTICS COLLECTOR | | |…| 1 |…|
| 5 | TABLE ACCESS FULL | SALES | 1 |…| 1 |…|
| 6 | INDEX RANGE SCAN | SALES_DETAIL_I1 | 300 |…| 1 |…|
| 7 | TABLE ACCESS BY INDEX ROWID | SALES_DETAIL | 300 |…| 1 |…|
| 8 | TABLE ACCESS FULL | SALES_DETAIL | 300 |…| |…|
====================================================================…============…=
結合の駆動表(外部表)で
予測(Estim)と実測(Actual)
が一致している。
HJは動作していない。
(Actual が Null)
NLが動作している。

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

31. 31
固定化/最新化 と Bind Peek等 の 組み合わせ
 「固定化」「最新化」の ２つの統計運用と、
Bind Peek等の最適化機能との組み合わせモデルで、
今年も考えてみるZe!!!(｀･ω･)Ъ
– ①固定化運用＋最適化無し のモデル
– ②最新化運用＋最適化有り のモデル
– ③最新化運用＋最適化無し のモデル

32. 32
①固定化＋最適化無し モデルのSQL処理時間イメージ
時間経過(データ件数)
処理
時間 短
長
PLAN2
単一PLANを
使い続ける
動作するプ
ラン
去年のBind Peek をもっと使おうぜ！より

33. 33
時間経過(データ件数)
処理
時間 短
長
PLAN1 PLAN2 PLAN3
PLAN4
複数PLANのコスト(予測)
近接点で、各PLANを併用しなが
ら少しづつ遷移していくイメージ
動作するプ
ラン
②最新化＋最適化有り モデルのSQL処理時間イメージ
去年のBind Peek をもっと使おうぜ！より

34. 34
時間経過(データ件数)
処理
時間 短
長
PLAN2
PLAN4
ハズレのPLANを引いた
時の性能劣化が大きい 動作するプ
ラン
PLANのバリエーションも少ない。
(列統計／ヒストグラム未使用)
ある瞬間では単一PLANしか選択さ
れない(※複数PLAN併用不可)
③最新化＋最適化無し モデルのSQL処理時間イメージ
去年のBind Peek をもっと使おうぜ！より

35. 35
② と ③ の性能変動モデルケース比較
 「赤線」が直線に近いほど、リスクは低い。
 どっちが直線に近いか？？？と云うこと
②最新化＋最適化有り ③最新化＋最適化無し
去年のBind Peek をもっと使おうぜ！より

36. 36
ここまでが去年の話
ここに12cの新機能が加わると…
ここまで去年の話

37. 37
時間経過(データ件数)
処理
時間 短
長
PLAN1 PLAN2 PLAN3
PLAN4
・各種最適化機能による、
精度の高い多様な実行計画
・適応計画で動的補正もしつつ、
適応カーソル共有で複数プランを併用
動作するプラン
②'最新化＋最適化有り(12c) モデルのSQL処理時間ｲﾒｰｼﾞ
適応計画で動的
補正されたプラン
PLAN5 PLAN6

38. 38
②'最新化＋最適化有り(12c) モデルの評価
 実行計画の各種最適化機能により、予測精度が高く
性能も良い、多種多様なプランを複数使用／併用できる。
– 予測精度が高い ⇒ リスクが低いと云うこと。
 更に適応計画による実行計画の動的補正により、ハズレ
の実行計画によるリスクを、11gR2 より低く抑えられる。
– 予測精度の高さ と 併せて 2重 のリスクヘッジ
 要するに製品機能の進化によって、昔よりも統計最新化
運用のメリットは増え、リスクは減ってきている。
– 昔とは状況が変わってきている、、、と云うのがポイント

39. 39
① と ②' の性能変動モデルケース比較
 「赤線」が直線に近いほど、リスクは低い。
 どちらもリスクは低いと言えるが、性能の違いは一目瞭然
①固定化＋最適化無し ②' 最新化＋最適化有り(12c)

40. 40
② と ②' の性能変動モデルケース比較
 「赤線」が直線に近いほど、リスクは低い。
 12c新機能によって更に直線に近づいた ②' の組み合わせ
②最新化＋最適化有り ②' 最新化＋最適化有り(12c)

41. 41
③ と ②' の性能変動モデルケース比較
 どちらが良いか？もはや何も言うことは無いやで 彡(-)(-)
③最新化＋最適化無し ②' 最新化＋最適化有り(12c)

42. 42
更にこのスライドを振り返ってみる。
 最近対応したSQL性能トラブルのやり取り ※全て統計固定の環境
彡(ﾟ)(ﾟ) 「MView実体表の統計が0件やで。実行計画悪いやで。」
(´･ω･｀)「すみません。MViewって統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「索引の統計が0件で、実行計画悪いやで。」
( ^ω^) 「ごめんね。索引って統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「エンドユーザ様が使う研修環境の統計が0件/Null統計の嵐で、
まともなSQL性能が出てないンゴよ。お客さん激おこやで。」
(*^○^*)「研修環境なんて知らないんだ！本番しか管理しないんだ！研修環
境はデータ少ないのに、変な実行計画を選ぶOracleが悪いんだ！」
彡()()「」

43. 43
ウォーターフォールなPJで考えてみると…(1/2)
 以下のようなウォーターフォールな
プロジェクトで考えてみる。
要件定義／
設計フェーズ
テストフェーズ 運用フェーズ
タスク
(Design)
タスク
(Test)
タスク
(manage
ment)
設計
機能テスト
結合テスト
性能テスト
運用
要件定義

44. 44
ウォーターフォールなPJで考えてみると…(2/2)
 システムを作る時には有識者を入れて頑張るが、運用に
入ると、高コストな有識者を貼り付けるケースはレア。
要件定義／
設計フェーズ
テストフェーズ 運用フェーズ
タスク
(Design)
タスク
(Test)
タスク
(manage
ment)
設計
機能テスト
結合テスト
性能テスト
運用
要件定義
・ここは有識者を
入れて頑張る。
・ここに有識者を常時
貼り付けるケースは少ない。

45. 45
統計固定は運用負荷が高いと云うデメリットも…
 統計固定の運用はSQL性能が低いだけでなく、カットオー
バー後の運用負荷がキツい！と云うデメリットもあります。
– 本番環境 ⇔ 保守環境 ⇔ 検証環境 との統計同期／管理
– アプリ(表/索引)リリースに伴う統計情報の変更／同時リリース
– データ肥大後の統計採取検討／再テスト、etc...
 一方システムが運用フェーズに突入すると、統計やDBに
詳しい有識者を常時貼り付けるのは、コスト面で厳しい。
– 運用フェーズに有識者が居ない体制は、
「運用負荷がキツい！」と云うデメリットと相反する。

46. 46
有識者が居ないのに統計固定運用を採用すると…
 最近対応したSQL性能トラブルのやり取り ※全て統計固定の環境
彡(ﾟ)(ﾟ) 「MView実体表の統計が0件やで。実行計画悪いやで。」
(´･ω･｀)「すみません。MViewって統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「索引の統計が0件で、実行計画悪いやで。」
( ^ω^) 「ごめんね。索引って統計有るんでしたっけ？？？」
彡(ﾟ)(ﾟ) 「エンドユーザ様が使う研修環境の統計が0件/Null統計の嵐で、
まともなSQL性能が出てないンゴよ。お客さん激おこやで。」
(*^○^*)「研修環境なんて知らないんだ！本番しか管理しないんだ！研修環
境はデータ少ないのに、変な実行計画を選ぶOracleが悪いんだ！」
彡()()「」
【悲報】統計固定、リスクヘッジにならない。

47. 47
もう一度、良く考え直してみよう。
 カットオーバー後の体制や運用負荷、SQL性能が低い等
のデメリットを考慮せず、「バカの一つ覚え」みたいに
「統計固定最高!!!Bind Peek(等)は
無効化しか有り得ません!!!」ｷﾘｯ!
の様なガイドをしていませんか?

48. 48
勇次郎さん も お怒りです。

49. 49
マヂでもう一度、考え直してみよう。
統計最新化／最適化機能全開の組み合わせが、
性能／リスクヘッジの両面で選択肢に入る。
– 去年も言いましたが、少なくとも今は 統計固定／
Bind Peek(等)無効化一択 の時代じゃない。
– 統計固定運用は、逆にリスクになる事も…
ではどのようなシステムや体制が、この資料で
出してきたモデルにマッチするかと云うと、、、

50. 50
今年もここまで

51. 51
4章. まとめ

52. 52
まとめ
統計固定運用は、SQL性能が低くカットオーバー
後の運用負荷もキツいと云うデメリットがある。
– リスクヘッジ優先の方針だが、ピーキーな運用を強いられる。
– 運用フェーズにおける体制と覚悟が無いと、逆にリスク要因に
統計最新化／最適化機能全開の組み合わせは、
性能／リスクヘッジの両面で有力な選択肢に。
– DB12c の新機能によって、更に改善されている。
統計固定を *安易に* ガイドするのは、非推奨
– 思考停止してませんか？もう一度良く考え直してみましょう。

53. 53
最後にもっかい煽っとく。オプティマイザ統計固定／
Bind Peek(等)無効化 を *安易に* 推奨する輩は… …

54. 54
今年のお題(回答)
まだ統計固定で
消耗してるの？
統計最新化と最適化機能全開で、
ラクしながらリスクヘッジしよう！

55. 55
お詫び
 今年も文章は煽り気味ですが、その方が喰い付きが
良いだろうと云う目論見で、他意はありません。
 和むように、荒巻(スカルチノフ) を置いてきますね。。。

56. 56
画像引用元(引用順)
 グラップラー刃牙・板垣 恵介(著)・秋田書店(出版)
 スラムダンク・井上 雄彦(著)・集英社(出版)

57. 57
おわり
ご清聴、サンガツだったやで！