More Related Content
Similar to 固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6- (20)
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
- 1. JPOUG Tech Talk Night #6
固定化か?最新化か?オプティマイザ
統計の運用をもう一度考える。
柴田 歩
2016年2月23日
- 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
- 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 して、
2回目以降の実行計画を最適化する機能
– 実行統計としてのカーディナリティを 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)
がズレている。
- 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 ★等価条件
###############################################################################
:
- 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等 の 組み合わせ
「固定化」「最新化」の 2つの統計運用と、
Bind Peek等の最適化機能との組み合わせモデルで、
今年も考えてみるZe!!!(`・ω・)Ъ
– ① 固定化運用+最適化無し のモデル
– ②'最新化運用+最適化有り(12c) のモデル
– ③ 最新化運用+最適化無し のモデル
まだ統計固定で消耗してるの?より
- 34. 34
時間経過(データ件数)
処理
時間 短
長
PLAN1 PLAN2 PLAN3
PLAN4
・各種最適化機能による、
精度の高い多様な実行計画
・適応計画で動的補正もしつつ、
適応カーソル共有で複数プランを併用
動作するプラン
②'最新化+最適化有り(12c) モデルのSQL処理時間イメージ
適応計画で動的
補正されたプラン
PLAN5 PLAN6
まだ統計固定で消耗してるの?より
- 35. 35
① と ②' の性能変動モデルケース比較
「赤線」が直線に近いほど、リスクは低い。
どちらもリスクは低いと言えるが、性能の違いは一目瞭然
①固定化+最適化無し ②' 最新化+最適化有り(12c)
まだ統計固定で消耗してるの?より
- 36. 36
② と ②' の性能変動モデルケース比較
「赤線」が直線に近いほど、リスクは低い。
12c新機能によって更に直線に近づいた ②' の組み合わせ
②最新化+最適化有り ②' 最新化+最適化有り(12c)
まだ統計固定で消耗してるの?より
- 37. 37
③ と ②' の性能変動モデルケース比較
どちらが良いか?もはや何も言うことは無いやで 彡(-)(-)
③最新化+最適化無し ②' 最新化+最適化有り(12c)
まだ統計固定で消耗してるの?より
- 40. 40
SQLのアルゴリズムは「予測」で組み立てられる。
SQL の アルゴリズム≒実行計画 は、オプティマイザが
最適と考えられるものを「予測」して組み立てます。
そして「予測」である以上、必ずハズレのケースが出てきます。
– ハズレの実行計画を引くと、性能問題として顕在化!
– SQLの特徴に由来する、全てのRDBMSに共通した本質的な困難
– 各ベンダやオープンソースのRDBMSは、このSQLの本質的な困難に
立ち向かうべく、日々凌ぎを削っています。(もちろんOracleも!)
まずこのハズレの実行計画の存在を意識/認識しておくのが、
本セミナーの出発点となります。
※Oracle DBA & Developer Day 2013 資料より
- 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
これらのドキュメントは、
ある一貫した設計思想に
基づいて作成されている!
- 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 資料より
- 49. 49
JPOUG Advent Calendar 2014 の まとめ
SQLのアルゴリズム=実行計画は予測で
組み立てられ、予測ゆえのハズレが不可避
– 全ての RDBMS に共通した、SQLが抱える本質的な困難
Bind Peek を初めとした実行計画の最適化機能
は、予測精度を向上/補正するための機能
– SQL の本質的な困難に、真正面から挑んでいる!
これらを *安易に* 無効化するのは、非推奨
– 思考停止してませんか?もう一度良く考え直してみましょう。
Bind Peek をもっと使おうぜ!より
- 51. 51
時間経過(データ件数)
処理
時間 短
長
PLAN1 PLAN2 PLAN3
PLAN4
・各種最適化機能による、
精度の高い多様な実行計画
・適応計画で動的補正もしつつ、
適応カーソル共有で複数プランを併用
動作するプラン
②'最新化+最適化有り(12c) モデルのSQL処理時間イメージ
適応計画で動的
補正されたプラン
PLAN5 PLAN6
まだ統計固定で消耗してるの?より
- 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後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い
- 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後の運用
負荷は②と同等
×
最適化機能無しのため
②より劣化リスクは高い
- 71. 71
②' は バランスが良いから勧めてるんやで。
②' は トータルバランス、特に 運用負荷 と リスクヘッジ
のバランスがそこそこに良いので、よくお勧めしてます。
経験上、運用がプアなお客様だとこのモデルの方が上手く
廻って、結果としてリスクヘッジになると感じてます。
‒ さっきも説明した通り、①は運用がプアだと悲惨そのもの
SQL性能が良いのは、まあ言うたらオマケやね彡(゚)(゚)
No
統計情報運用/
最適化機能モデル SQL性能 運用負荷 性能劣化リスク
②'
最新化運用+
最適化有り(12c)
◎
新鮮で高精度な統計と
最適化機能の組合せ
◎
自動化運用を
重要視したモデル
○
12cの各種補正機能により、
ハズレのリスクが低下
- 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$)
- 78. 78
③ と ②' の性能変動モデルケース比較
どちらが良いか?もはや何も言うことは無いやで 彡(-)(-)
③最新化+最適化無し ②' 最新化+最適化有り(12c)
まだ統計固定で消耗してるの?より