2016/2/23(火) に 開催された JPOUG Tech Talk Night #6 で 語った、 Oracle Database の オプティマイザ統計運用 についてのスライドやで 彡(ﾟ)(ﾟ) 　JPOUG Tech Talk Night #6 　固定化か？最新化か？オプティマイザ統計の運用をもう一度考える。 - 柴田 歩 - 　http://www.jpoug.org/2016/01/21/ttn6 　 　2/23(火) の JPOUG Tech Talk Night #6 で Oracle Database の オプティマイザ統計運用 について語ります。 　http://d.hatena.ne.jp/gonsuke777/20160121/1453342953 キーワード：Bind Peek, バインドピーク, オプティマイザ統計, Oracle Database

1. JPOUG Tech Talk Night #6
固定化か？最新化か？オプティマイザ
統計の運用をもう一度考える。
柴田 歩
2016年2月23日

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

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

4. 4
Oracle 3柴田 の 三国志！(雑コラ

5. 5
コンテンツ
 DDD 2013 SQLチューニングに
必要な考え方と最新テクニック
 http://www.oracle.com/techn
etwork/jp/ondemand/ddd-
2013-2051348-ja.html
コレ
 ブログ「ねら～ITエンジニア雑記」
 http://d.hatena.ne.jp/gonsuke777/
 Bind Peek をもっと使おうぜ！
-JPOUG Advent Calendar 2014-
 http://d.hatena.ne.jp/gonsuke777/
20141205/1417710300
 まだ統計固定で消耗してるの？
-JPOUG Advent Calendar 2015-
 http://d.hatena.ne.jp/gonsuke777/
20151208/1449587953

6. 6
過去 の JPOUG Advent Calendar では
烈海王先生
っぽい誰か
(自主規制)

7. 7
こんな感じで
範間刃牙さん
っぽい誰か
(自主規制)

8. 8
統計固定派／Bind Peek否定派を
範間勇次郎
さんっぽい誰か
(自主規制)

9. 9
散々煽り続けて来た訳ですが
安西先生
っぽい誰か
(自主規制)

10. 10
今回も(統計固定派/Bind Peek否定派を)煽ってやるやで～～彡(^)(^)
ジョセフ・
ジョースター
さんっぽい誰か
(自主規制)

11. 11
目次
 １章. 前提知識(主に過去資料の振り返り)
 ２章. 皆が忘れてるCBOの大事なことを、ワイが思い出させたる！
 ３章. 統計固定／Bind Peek(等)無効化をぶった斬る！
 ４章. で、最新化運用＋最適化有りって実際どうなのよ？
 ５章. まとめ

12. 12
1章. 前提知識(主に過去
資料の振り返り)

13. 13
この章は
超高速で巻きます

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
関連機能：ヒストグラム の 概要
 ヒストグラムは、列内のデータ配分が均一ではない場合
に、CBO の予測を補正するために採取する統計情報
 例えば以下のように列Xの値に偏りがある場合、ヒスト
グラムを採取すると、CBOがカーディナリティを正確に
予測できるようになります。
列A(PK) … 列X(FLG列) …
1 … 0 …
2 … 0 …
3 … 0 …
： :
99 … 0 …
100 … 1 …
大半が"0"で
ごく一部が"1"

20. 20
関連機能：拡張統計 の 概要
 拡張統計は "列グループの統計"と"式の統計"があり、ヒ
ストグラムとほぼ同様の動作をして、CBOのカーディナ
リティ予測を精緻化します。
– "列グループの統計"は列同士の値に相関があるケース
で、それらの列をWHERE句に同時記述した際の予測
を精緻化します。
– "式の統計" は関数／計算式等を適用したWHERE句の
絞り込み条件のカーディナリティ予測を精緻化しま
す。

21. 21
 拡張統計(式統計)採取後の実行統計
10:48:08 SQL> SELECT /*+ MONITOR */
10:48:08 2 A.*
10:48:08 3 FROM TEST_TABLE_A A
10:48:08 4 , TBL_B B
10:48:08 5 WHERE A.P_NO2 = B.P_NO
10:48:08 6 AND A.P_CHAR = B.P_CHAR
10:48:08 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801';
1102 rows selected.
Elapsed: 00:00:04.71
：
Statistics
----------------------------------------------------------
8994 consistent gets
59 physical reads
13:47:45 SQL> SELECT /*+ MONITOR */
13:47:45 2 A.*
13:47:45 3 FROM TEST_TABLE_A A
13:47:45 4 , TBL_B B
13:47:45 5 WHERE A.P_NO2 = B.P_NO
13:47:45 6 AND A.P_CHAR = B.P_CHAR
13:47:45 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801';
1102 rows selected.
Elapsed: 00:00:00.16
:
Statistics
----------------------------------------------------------
1301 consistent gets
0 physical reads
性能改善!
拡張統計による性能改善例
※Oracle DBA & Developer Day 2013 資料より

22. 22
 Before
 After
===================================================================================
| Id | Operation | Name | Rows | Rows | Activity Detail |
| | | | (Estim) | (Actual) | (# samples) |
===================================================================================
| 0 | SELECT STATEMENT | | | 1102 | |
| 1 | HASH JOIN | | 30012 | 1102 | Cpu (5) |
| 2 | TABLE ACCESS FULL | TBL_B | 300 | 11 | |
| 3 | TABLE ACCESS FULL | TEST_TABLE_A | 3M | 3M | |
===================================================================================
================================================================================================
| Id | Operation | Name | Rows | Rows | Activity Detail |
| | | | (Estim) | (Actual) | (# samples) |
================================================================================================
| 0 | SELECT STATEMENT | | | 1102 | |
| 1 | NESTED LOOPS | | | 1102 | |
| 2 | NESTED LOOPS | | 1106 | 1102 | |
| 3 | TABLE ACCESS FULL | TBL_B | 11 | 11 | |
| 4 | INDEX RANGE SCAN | TEST_TABLE_A_I1 | 100 | 1102 | |
| 5 | TABLE ACCESS BY INDEX ROWID | TEST_TABLE_A | 101 | 1102 | |
================================================================================================
拡張統計動作時のSQL監視レポート
※Oracle DBA & Developer Day 2013 資料より
予測(Estim) と 実測
(Actual)の差が無くなり、
適切な実行計画が
選択されている。
結合の駆動表(外部表)の
予測(Estim)と実測(Actual)
がズレている。

23. 23
関連機能：SQLワークロード(col_usage$)
 SQLワークロード(col_usage$)
– 実行されたSQLのフィルタ述語(WHERE句の条件)を記録
して、ヒストグラムや拡張統計を採取するためのエントリ
として保持しておく機能
– 統計最新化と併用することで、SQLのWHERE句で使用さ
れている列のヒストグラムや拡張統計が自動採取され、
実行計画の予測精度が上がってSQL性能向上が期待できる。
– DBMS_STATSパッケージのREPORT_COL_USAGEファ
ンクションでSQLワークロード(col_usage$)の内容を参
照可能です。

24. 24
SQLワークロード(col_usage$)の出力例
 DBMS_STATS.REPORT_COL_USAGEファンクション
による SQLワークロード(col_usage$)の出力例です。
SET LONG 1000000;
SET LONGC 1000000;
SET LINESIZE 1000;
SET PAGESIZE 0;
SELECT DBMS_STATS.REPORT_COL_USAGE(NULL, NULL) FROM DUAL;
：
###############################################################################
COLUMN USAGE REPORT FOR STDBYPERF.STATS$FILE_HISTOGRAM
......................................................
1. DB_UNIQUE_NAME : EQ EQ_JOIN ★等価条件&結合条件
2. FILE# : EQ EQ_JOIN ★等価条件&結合条件
3. INSTANCE_NAME : EQ EQ_JOIN ★等価条件&結合条件
4. SINGLEBLKRDTIM_MILLI : EQ_JOIN ★結合条件
5. SNAP_ID : EQ ★等価条件
###############################################################################
：

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

26. 26
 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計画ディレクティブによる性能改善例
論理読込が大幅減少
して性能改善！
まだ統計固定で消耗してるの？より

27. 27
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)の差が無くなり、
適切な実行計画が
選択されている。
まだ統計固定で消耗してるの？より

28. 28
 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計画ディレクティブ の 中身
まだ統計固定で消耗してるの？より

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

30. 30
 適応計画(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)による性能改善例
論理読込が大幅減少
して性能改善！
まだ統計固定で消耗してるの？より

31. 31
適応計画動作時 の 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が動作している。
まだ統計固定で消耗してるの？より

32. 32
予測／実測が乖離していない場合は…
 適応計画(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が動作している。
まだ統計固定で消耗してるの？より

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

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

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

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

37. 37
③ と ②' の性能変動モデルケース比較
 どちらが良いか？もはや何も言うことは無いやで 彡(-)(-)
③最新化＋最適化無し ②' 最新化＋最適化有り(12c)
まだ統計固定で消耗してるの？より

38. 38
準備運動完了

39. 39
２章. 皆が忘れてるCBOの大
事なことを、ワイが思い出さ
せたる！

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

41. 41
まずはコレ

42. 42
SQLはアルゴリズムを書く必要が無いので、
誰でも比較的簡単に書ける。
SQLはアルゴリズムが "予測" で組み立てら
れ、"ハズレ" を引く可能性が常にある。
全てのRDBMSに共通した、長所／短所が一
体化したSQLと云う言語のこの特徴を受け容
れるところから、全てが始まる！(｀･ω･)Ъ
実行計画は"ハズレ"が有り得るのを受け容れる！

43. 43
AYU三部作(※←今考えた)
 DDD 2013 SQLチューニングに
必要な考え方と最新テクニック
 http://www.oracle.com/techn
etwork/jp/ondemand/ddd-
2013-2051348-ja.html
コレ
 ブログ「ねら～ITエンジニア雑記」
 http://d.hatena.ne.jp/gonsuke777/
 Bind Peek をもっと使おうぜ！
-JPOUG Advent Calendar 2014-
 http://d.hatena.ne.jp/gonsuke777/
20141205/1417710300
 まだ統計固定で消耗してるの？
-JPOUG Advent Calendar 2015-
 http://d.hatena.ne.jp/gonsuke777/
20151208/1449587953

44. 44
AYU三部作(※←今考えた)
 DDD 2013 SQLチューニングに
必要な考え方と最新テクニック
 http://www.oracle.com/techn
etwork/jp/ondemand/ddd-
2013-2051348-ja.html
コレ
 ブログ「ねら～ITエンジニア雑記」
 http://d.hatena.ne.jp/gonsuke777/
 Bind Peek をもっと使おうぜ！
-JPOUG Advent Calendar 2014-
 http://d.hatena.ne.jp/gonsuke777/
20141205/1417710300
 まだ統計固定で消耗してるの？
-JPOUG Advent Calendar 2015-
 http://d.hatena.ne.jp/gonsuke777/
20151208/1449587953
これらのドキュメントは、
ある一貫した設計思想に
基づいて作成されている！

45. 45
CBO の性能を引き出し
て「予測」の精度を上
げると云う設計思想
その設計思想とは……？

46. 46
チューニング案の一覧
 今回のSQLでは下記に挙げるチューニングで性能が改善しました。
– 案1 … DBMS_STATSによる統計情報採取
– 案2 … 拡張統計の採取
– 案3 … SQLプロファイル適用(by DBMS_SQLTUNE)
– 案4 … CardinalityFeedbackの使用
– 案5 … ヒント や SPM による実行計画操作
– 案6 … パラレル・クエリ化
– 案7 … SQL修正(WHERE句書き換え)
– 案8 … SQL修正(WITH句によるサブクエリ切り出し)
– 案9 … Dynamic Sampling適用
– 案10…新規索引付与
– 案11…リザルト・セットの適用
今回紹介する
チューニング案
※Oracle DBA & Developer Day 2013 資料より

47. 47
紹介したチューニング案の方向性について
 今回紹介したのは、全て「予測(Estimate)」と「実測(Actual)」の
乖離を補正する方向性でチューニングを実施しています。
 既に述べた通り、下記のようなチューニングも可能でした。
– 案5 … ヒント や SPM による実行計画操作
– 案6 … パラレル・クエリ化
– 案7 … SQL修正(WHERE句書き換え)
– 案8 … SQL修正(WITH句によるサブクエリ切り出し)
– 案9 … Dynamic Sampling適用
– 案10…新規索引付与
– 案11…リザルト・セットの適用
 チューニングの正解は1つではありません。併せて利用しましょう。
※Oracle DBA & Developer Day 2013 資料より

48. 48
CBO の「予測」と「実
測」の乖離を補正する
方向性のチューニング
CBO の 性能を引き出す(その1)

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

50. 50
CBOの予測精度を
向上／補正する機能
– Bind Peek／適応カーソル共有
– ヒストグラム／拡張統計
– Cardinality Feedback
– 動的統計(Dynamic Sampling)
CBO の 性能を引き出す(その2)
– SQL計画ディレクティブ
– 適応計画(Adaptive Plan)
– SQLプロファイル

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

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

53. 53
フレッシュな統計と各種
最適化機能による、予測
精度が高くて性能も良い
実行計画
CBO の 性能を引き出す(その3)

54. 54
Oracle の実行計画最適化機能は、
CBOの予測精度向上のために存在している。
これらをフル活用して予測精度を上げると
云う設計思想は、SQLの特徴に真正面から
立ち向かう、いわば王道なんやで。
統計固定派／Bind Peek否定派の
皆さん、思い出しましたか？
– 特にBind Peek を"常に"悪者扱いしている、そこの貴方！m9(｀･ω･´)
皆さん、思いだしたやろか？彡(^)(^)

55. 55
３章. 統計固定／
Bind Peek(等)無効化
をぶった斬る！

56. 56
このガイド
「ミッションクリティカルなシステムでは、
Bind Peek等 は 無効化 して、
オプティマイザ統計も固定して、
SQL性能を安定させることが推奨です。 」

57. 57
違います。
「ミッションクリティカルなシステムでは、
Bind Peek等 は 無効化 して、
オプティマイザ統計も固定して、
SQL性能を安定させることが推奨です。 」

58. 58
こうです。
「ミッションクリティカルなシステムでは、
Oracle Database の 有識者 を 常時アサイン
しておくことが推奨です。」
「その Oracle Database の 有識者が、
オプティマイザ統計を常時管理／固定する
のを前提に、Bind Peek等を無効化します。」
「常時貼り付いた有識者が実行計画を固定すること
により、SQL性能劣化のリスクを抑制します。」

59. 59
これを曲解して、こんな感じにすると……
 (^w^)「取り敢えず Bind Peek は 無効化した方が
エエらしいで。統計は採らんで放っとこ。」
 (^w^) 「0件統計？NULL統計？知らんわそんなん。
有名なコンサルさんの本にも書いとるし、
Oracle Database が 何とかしてくれるやろ。
イザとなったらサポートに押し付けたろ。」
 (^w^)「ミッションクリティカル(笑)なシステムを
隠しパラメータ(笑)で安定させるワイ、
おしゃれでカッコええやな～～。」ﾊﾅﾀｶｰ

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

61. 61
なぜこうなってしまうのか？それは……
 それは "性能劣化リスク" でしか評価してないから。
No
統計情報運用／
最適化機能モデル 性能劣化リスク
①
固定化運用＋
最適化無し
◎
性能変動の要素がデータ増
以外無く、低リスク
②
最新化運用＋
最適化有り
△
ハズレの実行計画の可能性
をゼロにはできない
③
最新化運用＋
最適化無し
×
最適化機能無しのため
②より劣化リスクは高い
採用！

62. 62
最低限、これ位の軸(例)で評価せんと(アカン)
 "SQL性能" "運用負荷" "性能劣化リスク" の 3軸による評価例
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
◎
性能変動の要素がデータ増
以外無く、低リスク
②
最新化運用＋
最適化有り
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
△
ハズレの実行計画の可能性
をゼロにはできない
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

63. 63
①のモデルは運用がピーキー
 ①はリスクヘッジ重視だが運用負荷がピーキーでキツい
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
◎
性能変動の要素がデータ増
以外無く、低リスク
②
最新化運用＋
最適化有り
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
△
ハズレの実行計画の可能性
をゼロにはできない
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

64. 64
①のモデルは運用がプア(有識者不在)だと……
 ①で運用がプア(有識者不在)だと、悲惨！(オール×)
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
×
【悲報】統計固定、
リスクヘッジにならない。
②
最新化運用＋
最適化有り
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
△
ハズレの実行計画の可能性
をゼロにはできない
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

65. 65
①を上手く運用するには、以下の要素が必要
– Oracle Database の 有識者
– その有識者を貼り付ける体制(コスト意識)
– 何よりも重要なのは、「Oracle Database の CBO
など信用できない！SQLの実行計画は我々自身の
手で管理、運用するのだ！」と云うモチベーション
このモチベーションが欠けたまま、「ミッション
クリティカル」とか「隠しパラメータ」とかの
言葉に踊らされて、これを安易に採用すると……
①のモデルを上手く運用するための要素

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

67. 67
②のモデルはトータルのバランスが良い。
 ②は"性能" "運用" "リスク" の バランス に優れている。
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
◎
性能変動の要素がデータ増
以外無く、低リスク
②
最新化運用＋
最適化有り
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
△
ハズレの実行計画の可能性
をゼロにはできない
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

68. 68
②' は 12c新機能の恩恵で更に良くなっている。
 ②' は 12c新機能の恩恵で、リスクが更に低くなっている。
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
◎
性能変動の要素がデータ増
以外無く、低リスク
②'
最新化運用＋
最適化有り(12c)
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
○
12cの各種補正機能により、
ハズレのリスクが低下
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

69. 69
②(②') を勧めると、良く言われます。
「AYUさん、何もそんなに性能を限界まで
追い求め無くても良いんじゃないですか？」

70. 70
違います。
「AYUさん、何もそんなに性能を限界まで
追い求め無くても良いんじゃないですか？」

71. 71
②' は バランスが良いから勧めてるんやで。
 ②' は トータルバランス、特に 運用負荷 と リスクヘッジ
のバランスがそこそこに良いので、よくお勧めしてます。
 経験上、運用がプアなお客様だとこのモデルの方が上手く
廻って、結果としてリスクヘッジになると感じてます。
‒ さっきも説明した通り、①は運用がプアだと悲惨そのもの
 SQL性能が良いのは、まあ言うたらオマケやね彡(ﾟ)(ﾟ)
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
②'
最新化運用＋
最適化有り(12c)
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
○
12cの各種補正機能により、
ハズレのリスクが低下

72. 72
更にこの(②')モデル、新しい世界が待っている。
更にこの(②')モデル、新しい世界が待っています。
実行計画の各種最適化機能と、オプティマイザ統
計の最新化運用が組み合わさると…
‒ヒストグラム
‒拡張統計(列グループ統計／式の統計)
‒SQLワークロード(col_usage$)
‒SQL計画ディレクティブ

73. 73
• Oracle Databaseにおいては、Cost Base Optimizer = CBO にSQLテキストや
オプティマイザ統計等の様々な情報がインプットされて、実行計画が生成されます。
Oracle Database 12c の実行計画生成の仕組み
オプティマイザ
(CBO)
実行計画
⑥ヒント句
①SQLテキスト/Bind変数
②オブジェクト構造
③初期化パラメータ
⑦アウトライン
／SPM(11g以降)
⑧SQL Profile凡例 実線(－)⇒必須情報
破線(…)⇒追加情報
④システム統計
⑤オプティマイザ統計
実データ
SQL性能
(レスポンス)
インフラ
⑨Cardinality
Feedback(11gR2以降)
⑩Dynamic Sampling
(12c以降:動的統計)
実行計画
の生成
⑪SQL計画ディレク
ティブ(12c以降)
⑫適応計画
(12c以降)
⑫SQLワークロード
(COL_USAGE$)

74. 74
各種最適化機能と、最新化運用が組み合わさると…
オプティマイザ
(CBO)
実行計画
⑥ヒント句
①SQLテキスト/Bind変数
②オブジェクト構造
③初期化パラメータ
⑦アウトライン
／SPM(11g以降)
⑧SQL Profile凡例 実線(－)⇒必須情報
破線(…)⇒追加情報
④システム統計
⑤オプティマイザ統計
実データ
SQL性能
(レスポンス)
インフラ
⑨Cardinality
Feedback(11gR2以降)
⑩Dynamic Sampling
(12c以降:動的統計)
• ①様々なSQLが実行 ⇒ ②多様なSQL計画ディレクティブ／SQLワークロードが蓄積
⇒ ③多様なヒストグラム／拡張統計が採取 ⇒ ④更に性能の良い実行計画が選択！
⑪SQL計画ディレク
ティブ(12c以降)
⑫適応計画
(12c以降)
⑫SQLワークロード
(COL_USAGE$)
Directive 1
Directive 2
Directive 3
Directive 4
Workload 1
Workload 2
Workload 3
Workload 4
①多様なSQLが実行される。
②多様なSQLに伴う、多様なSQL計画ディレク
ティブ や SQLワークロード(COL_USAGE$)が
格納／蓄積されていく。
④更に性能の良い実行
計画が選択される。
Histogram 1 Histogram 2
Histogram 3 Histogram 4
③SQL計画ディレクティブ や SQLワークロード
(COL_USAGE$)により、多様なヒストグラム／
拡張統計が採取される。

75. 75
各種最適化機能と、最新化運用が組み合わさると…
オプティマイザ
(CBO)
実行計画
⑥ヒント句
①SQLテキスト/Bind変数
②オブジェクト構造
③初期化パラメータ
⑦アウトライン
／SPM(11g以降)
⑧SQL Profile凡例 実線(－)⇒必須情報
破線(…)⇒追加情報
④システム統計
⑤オプティマイザ統計
実データ
SQL性能
(レスポンス)
インフラ
⑨Cardinality
Feedback(11gR2以降)
⑩Dynamic Sampling
(12c以降:動的統計)
• ①様々なSQLが実行 ⇒ ②多様なSQL計画ディレクティブ／SQLワークロードが蓄積
⇒ ③多様なヒストグラム／拡張統計が採取 ⇒ ④更に性能の良い実行計画が選択！
⑪SQL計画ディレク
ティブ(12c以降)
⑫適応計画
(12c以降)
⑫SQLワークロード
(COL_USAGE$)
Directive 1
Directive 2
Directive 3
Directive 4
Workload 1
Workload 2
Workload 3
Workload 4
①多様なSQLが実行される。
②多様なSQLに伴う、多様なSQL計画ディレク
ティブ や SQLワークロード(COL_USAGE$)が
格納／蓄積されていく。
④性能の良い実行計
画が選択される。
Histogram 1 Histogram 2
Histogram 3 Histogram 4
③SQL計画ディレクティブ や SQLワークロード
(COL_USAGE$)により、多様なヒストグラム／
拡張統計が採取される。
・進化する統計！
・進化する実行計画！
・進化するSQL性能！

76. 76
③のモデルは中途半端だけど、割と多い
 ③は中途半端、安全神話"Bind Peek無効化"の負の遺産？
No
統計情報運用／
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
①
固定化運用＋
最適化無し
×
低精度な統計に
加え最適化機能無し
×
新アプリや新環境リリース時
のメンテナンス負荷
◎
性能変動の要素がデータ増
以外無く、低リスク
②'
最新化運用＋
最適化有り(12c)
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
○
12cの各種補正機能により、
ハズレのリスクが低下
③
最新化運用＋
最適化無し
△
最適化機能無しのため
①よりも性能は低い
◎
C/O後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い

77. 77
Bind Peek無効化が安全神話と化してないか？
Bind Peek無効化は昔から言われ続けた結果、
「安全神話」と化しているのではないか？
「安全神話」の意味
– 絶対安全だという信頼感。言外に根拠のない
思い込み、錯覚にすぎないという含みがある。
安全性が保たれている時はこの言葉は使用されず、
崩れた時に使用される。
– hatena keywordより
Bind Peek をもっと使おうぜ！より

78. 78
③ と ②' の性能変動モデルケース比較
 どちらが良いか？もはや何も言うことは無いやで 彡(-)(-)
③最新化＋最適化無し ②' 最新化＋最適化有り(12c)
まだ統計固定で消耗してるの？より

79. 79
統計は最新化するけど、とりあえず
Bind Peek等は無効化しとこう、みたいなノリ？
– ノールック"Bind Peek(等)無効化"
– 脊髄反射な"Bind Peek(等)無効化"
ちゃんとメリ／デメを整理して判断できとります
か？よくよく考えた方が、エエんちゃいますか？
– Bind Peek等 を 無効化していても、
オプティマイザ統計を最新化している時点で
実行計画は変動するんやで彡(-)(-)
③のモデルの採用は、よくよく考えるんやで！

80. 80
４章. で、最新化運用＋
最適化有りって実際どう
なのよ？

81. 81
最新化運用＋最適化有り
のモデルを積極的に
採用したことが有る人、
挙手！( ﾟωﾟ)ﾉ

82. 82
おそらく
ほとんど居ない？

83. 83
負のサイクル
Bind Peek(等) は使ったことない、不安だ。
↓
不採用
↓
Bind Peek(等) は使ったことない、不安だ。
↓
不採用
↓
Bind Peek(等) は使ったことｎ(以下、ループ

84. 84
安心して下さい、使ってますよ。
とにかく明るい安村
さんっぽい誰か
(自主規制)

85. 85
ワイ(AYU)の過去PJで振り返ってみる。
ワイ(AYU)、以前から 最新化運用＋最適化有り の
モデルを推進していて、そこそこ採用して貰った
実績アリ。
それらの過去PJで、振り返ってみるやで彡(^)(^)
– 2011年～2012年、某Upgrade案件(9iR2⇒11gR2)
– 2012年～2013年、某複数システム集約案件(11gR2)
– 2013年～2014年、
某マルチスタンバイ・Data Guard案件(11gR2)

86. 86
2011年～2012年、某Upgrade案件(9iR2⇒11gR2)
 同時8サブシステムのUpgrade(9iR2⇒11gR2)プロジェクト

87. 87
2011年～2012年、某Upgrade案件(9iR2⇒11gR2)
 同時8サブシステムのUpgrade(9iR2⇒11gR2)プロジェクト
CBO廻りの問題は無く、
無事本番カットオーバー
※後に サブシステムD も 統計最新化＋最適化有り モデル に 移行

88. 88
2012年～2013年、某複数システム集約案件(11gR2)
 自動統計採取と最適化機能を併用し、インスタンス・
ケージング で 2Node RAC に 複数システムを集約
System A
RAC
Node #1
RAC
Node #2
System B
System C

89. 89
2012年～2013年、某複数システム集約案件(11gR2)
 自動統計採取と最適化機能を併用し、インスタンス・
ケージング で 2Node RAC に 複数システムを集約
System A
RAC
Node #1
RAC
Node #2
System B
System C
運用負荷の低減と性能担保を
両立し、コスト削減も実現！
※公開事例にもなりました。

90. 90
2013年～2014年、
某マルチスタンバイ・Data Guard案件(11gR2)
 非Exaな 某マルチスタンバイ・Data Guard案件(11gR2)
 あらゆる機能を生かす方針で、最新化運用＋最適化有り のモデルを採用
Primary
Standby Standby
REDOログ
転送/適用
Data Guard Broker

91. 91
2013年～2014年、
某マルチスタンバイ・Data Guard案件(11gR2)
 非Exaな 某マルチスタンバイ・Data Guard案件(11gR2)
 あらゆる機能を生かす方針で、最新化運用＋最適化有り のモデルを採用
Primary
Standby Standby
REDOログ
転送/適用
Data Guard Broker
性能廻り／可用性関連の
問題無しで、年単位での
無停止稼働を今も継続中

92. 92
更に、某案件でのあるSQLの実行時間推移グラフ
某案件(12cR1)での、あるSQLの実行時間推移グラフ
※ポイントポイントでオプティマイザ統計を採取
過去 現在
SQL性能が時間経過と
共に改善している。

93. 93
更に、某案件でのあるSQLの実行時間推移グラフ
某案件(12cR1)での、あるSQLの実行時間推移グラフ
※ポイントポイントでオプティマイザ統計を採取
過去 現在
・進化する統計！
・進化する実行計画！
・進化するSQL性能！

94. 94
各種最適化機能と、最新化運用が組み合わさると…
オプティマイザ
(CBO)
実行計画
⑥ヒント句
①SQLテキスト/Bind変数
②オブジェクト構造
③初期化パラメータ
⑦アウトライン
／SPM(11g以降)
⑧SQL Profile凡例 実線(－)⇒必須情報
破線(…)⇒追加情報
④システム統計
⑤オプティマイザ統計
実データ
SQL性能
(レスポンス)
インフラ
⑨Cardinality
Feedback(11gR2以降)
⑩Dynamic Sampling
(12c以降:動的統計)
• ①様々なSQLが実行 ⇒ ②多様なSQL計画ディレクティブ／SQLワークロードが蓄積
⇒ ③多様なヒストグラム／拡張統計が採取 ⇒ ④更に性能の良い実行計画が選択！
⑪SQL計画ディレク
ティブ(12c以降)
⑫適応計画
(12c以降)
⑫SQLワークロード
(COL_USAGE$)
Directive 1
Directive 2
Directive 3
Directive 4
Workload 1
Workload 2
Workload 3
Workload 4
①多様なSQLが実行される。
②多様なSQLに伴う、多様なSQL計画ディレク
ティブ や SQLワークロード(COL_USAGE$)が
格納／蓄積されていく。
④更に性能の良い実行
計画が選択される。
Histogram 1 Histogram 2
Histogram 3 Histogram 4
③SQL計画ディレクティブ や SQLワークロード
(COL_USAGE$)により、多様なヒストグラム／
拡張統計が採取される。

95. 95
各種最適化機能と、最新化運用が組み合わさると…
オプティマイザ
(CBO)
実行計画
⑥ヒント句
①SQLテキスト/Bind変数
②オブジェクト構造
③初期化パラメータ
⑦アウトライン
／SPM(11g以降)
⑧SQL Profile凡例 実線(－)⇒必須情報
破線(…)⇒追加情報
④システム統計
⑤オプティマイザ統計
実データ
SQL性能
(レスポンス)
インフラ
⑨Cardinality
Feedback(11gR2以降)
⑩Dynamic Sampling
(12c以降:動的統計)
• ①様々なSQLが実行 ⇒ ②多様なSQL計画ディレクティブ／SQLワークロードが蓄積
⇒ ③多様なヒストグラム／拡張統計が採取 ⇒ ④更に性能の良い実行計画が選択！
⑪SQL計画ディレク
ティブ(12c以降)
⑫適応計画
(12c以降)
⑫SQLワークロード
(COL_USAGE$)
Directive 1
Directive 2
Directive 3
Directive 4
Workload 1
Workload 2
Workload 3
Workload 4
①多様なSQLが実行される。
②多様なSQLに伴う、多様なSQL計画ディレク
ティブ や SQLワークロード(COL_USAGE$)が
格納／蓄積されていく。
④性能の良い実行計
画が選択される。
Histogram 1 Histogram 2
Histogram 3 Histogram 4
③SQL計画ディレクティブ や SQLワークロード
(COL_USAGE$)により、多様なヒストグラム／
拡張統計が採取される。
この新しい世界を
まさに実現！

96. 96
５章. まとめ

97. 97
まとめ
まずは実行計画は"予測"であり、"ハズレ"が
有り得ると云う事実を受け容れること。
– チューニングや運用設計の視野が広がり、引き出しも増える。
統計固定化＋最適化無しの運用は今後も
生き残るが、メリットは相対的に薄れつつある。
– 「とりあえず Bind Peek は 無効化」は ダメ、絶対。
統計最新化＋最適化有り の 運用 と
12cR1 の 組み合わせ で、新しい世界が広がる！
– 進化する統計！進化する実行計画！進化するSQL性能！
– CBOの機能を抑え込んで制御するのではなく、
CBOの機能を引き出して予測精度を上げると云う設計思想

98. 98
あなたはどちらを選びますか？
 統計固定化 の ストイックな世界  統計最新化 の や さ し い 世界

99. 99
お詫び
 相変わらず内容は煽り全開ですが、その方が喰い付きが
良いだろうと云う目論見で、他意はありません。
 和むように、しまむらくん を置いてきますね。。。

100. 100
QA＆ディスカッション
何でもどうぞ！

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