固定化か？最新化か？オプティマイザ統計の運用をもう一度考える。 -JPOUG...

JPOUG Tech Talk Night #6

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

2

免責事項／注意事項

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

3

自己紹介

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

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

2007年4月に中途で入社

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

4

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

5

コンテンツ

DDD 2013 SQLチューニングに必要な考え方と最新テクニック

http://www.oracle.com/technetwork/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-















6

過去の JPOUG Advent Calendar では

烈海王先生っぽい誰か (自主規制)

7

こんな感じで

範間刃牙さんっぽい誰か (自主規制)

8

統計固定派／Bind Peek否定派を

範間勇次郎さんっぽい誰か (自主規制)

9

散々煽り続けて来た訳ですが

安西先生っぽい誰か (自主規制)

10

今回も(統計固定派/Bind Peek否定派を)煽ってやるやで～～彡(^)(^)

ジョセフ・ジョースターさんっぽい誰か (自主規制)

11

目次

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

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

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

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

５章. まとめ

12

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

13

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

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

10gR2までの動作は...

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




1の場合初回のPLAN で固定

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

10000の場合


16

11gR1で「適応カーソル共有」が導入 11gR1からは「適応カーソル共有(Adaptive Cursor Sharing)」導入で、複数の実行計画を併用するようになった。

– Bind Peek を無効化した場合は、当機能も無効化されます。




10000の場合 1の場合

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

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


17

関連機能： Cardinality Feedback の概要

11gR2からの新機能

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

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

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

– KROWN# 147614


18

関連機能：Dynamic Sampling の概要

9iR2からの機能

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

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

– KROWN#55982

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

12c からは他クエリからも参照可能


19

関連機能：ヒストグラムの概要

ヒストグラムは、列内のデータ配分が均一ではない場合に、CBO の予測を補正するために採取する統計情報

例えば以下のように列Xの値に偏りがある場合、ヒストグラムを採取すると、CBOがカーディナリティを正確に予測できるようになります。

列A(PK) … 列X(FLG列) …

1 … 0 …

2 … 0 …

3 … 0 …

： :

99 … 0 …

100 … 1 …

大半が"0"でごく一部が"1"

20

関連機能：拡張統計の概要

拡張統計は "列グループの統計"と"式の統計"があり、ヒストグラムとほぼ同様の動作をして、CBOのカーディナリティ予測を精緻化します。

– "列グループの統計"は列同士の値に相関があるケースで、それらの列をWHERE句に同時記述した際の予測を精緻化します。

– "式の統計" は関数／計算式等を適用したWHERE句の絞り込み条件のカーディナリティ予測を精緻化します。

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

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

関連機能：SQLワークロード(col_usage$)

SQLワークロード(col_usage$)

– 実行されたSQLのフィルタ述語(WHERE句の条件)を記録して、ヒストグラムや拡張統計を採取するためのエントリとして保持しておく機能

– 統計最新化と併用することで、SQLのWHERE句で使用されている列のヒストグラムや拡張統計が自動採取され、実行計画の予測精度が上がってSQL性能向上が期待できる。

– DBMS_STATSパッケージのREPORT_COL_USAGEファンクションでSQLワークロード(col_usage$)の内容を参照可能です。

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

12c新機能：SQL計画ディレクティブの概要

SQL計画ディレクティブ

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

– 統計最新化と併用することで、不足しているヒストグラムや拡張統計が自動採取され、実行計画の予測精度が上がってSQL性能向上が期待できる。

– 加えて、SQL計画ディレクティブが存在する状態でヒストグラムや拡張統計が採取されていない場合、動的統計が採取されてヒストグラム／拡張統計を代替します。

まだ統計固定で消耗してるの？より

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

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

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

12c新機能：適応計画(Adaptive Plan)の概要

適応計画(Adaptive Plan)の概要は以下の通り

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

– もっと具体的に言うと、NESTED LOOPS の駆動表(外部表)の実測(Actual)が、予測(Estimate)と大幅に乖離している場合に、結合操作を HASH JOIN に "動的"に切り替えて性能劣化を防ぐ働きをする。


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

適応計画動作時の 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

予測／実測が乖離していない場合は… 適応計画(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

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

「固定化」「最新化」の２つの統計運用と、 Bind Peek等の最適化機能との組み合わせモデルで、今年も考えてみるZe!!!(｀･ω･)Ъ

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

– ②'最新化運用＋最適化有り(12c) のモデル

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


34

時間経過(データ件数)

処理時間短

長

PLAN1 PLAN2 PLAN3

PLAN4

・各種最適化機能による、精度の高い多様な実行計画

・適応計画で動的補正もしつつ、適応カーソル共有で複数プランを併用

動作するプラン

②'最新化＋最適化有り(12c) モデルのSQL処理時間ｲﾒｰｼﾞ

適応計画で動的補正されたプラン

PLAN5 PLAN6


35

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

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

どちらもリスクは低いと言えるが、性能の違いは一目瞭然

①固定化＋最適化無し ②' 最新化＋最適化有り(12c)


36

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

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

12c新機能によって更に直線に近づいた ②' の組み合わせ

②最新化＋最適化有り ②' 最新化＋最適化有り(12c)


37

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

どちらが良いか？もはや何も言うことは無いやで彡(-)(-)

③最新化＋最適化無し ②' 最新化＋最適化有り(12c)


38

準備運動完了

39

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

40

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

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

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

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

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

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

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

※Oracle DBA & Developer Day 2013 資料より

41

まずはコレ

42

SQLはアルゴリズムを書く必要が無いので、誰でも比較的簡単に書ける。

SQLはアルゴリズムが "予測" で組み立てられ、"ハズレ" を引く可能性が常にある。

全てのRDBMSに共通した、長所／短所が一体化したSQLと云う言語のこの特徴を受け容れるところから、全てが始まる！(｀･ω･)Ъ

実行計画は"ハズレ"が有り得るのを受け容れる！

43

AYU三部作(※←今考えた)



コレ




















44

AYU三部作(※←今考えた)



コレ







これらのドキュメントは、ある一貫した設計思想に

基づいて作成されている！














45

CBO の性能を引き出して「予測」の精度を上げると云う設計思想

その設計思想とは……？

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…リザルト・セットの適用

今回紹介するチューニング案


47

紹介したチューニング案の方向性について今回紹介したのは、全て「予測(Estimate)」と「実測(Actual)」の乖離を補正する方向性でチューニングを実施しています。

既に述べた通り、下記のようなチューニングも可能でした。

– 案5 … ヒントや SPM による実行計画操作

– 案6 … パラレル・クエリ化

– 案7 … SQL修正(WHERE句書き換え)

– 案8 … SQL修正(WITH句によるサブクエリ切り出し)

– 案9 … Dynamic Sampling適用

– 案10…新規索引付与

– 案11…リザルト・セットの適用

チューニングの正解は1つではありません。併せて利用しましょう。


48

CBO の「予測」と「実測」の乖離を補正する方向性のチューニング

CBO の性能を引き出す(その1)

49

JPOUG Advent Calendar 2014 のまとめ

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

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

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


50

CBOの予測精度を向上／補正する機能

– Bind Peek／適応カーソル共有

– ヒストグラム／拡張統計

– Cardinality Feedback

– 動的統計(Dynamic Sampling)


– SQL計画ディレクティブ

– 適応計画(Adaptive Plan)

– SQLプロファイル

51

時間経過(データ件数)

処理時間短

長

PLAN1 PLAN2 PLAN3

PLAN4

・各種最適化機能による、精度の高い多様な実行計画

・適応計画で動的補正もしつつ、適応カーソル共有で複数プランを併用

動作するプラン

②'最新化＋最適化有り(12c) モデルのSQL処理時間ｲﾒｰｼﾞ

適応計画で動的補正されたプラン

PLAN5 PLAN6


52

②'最新化＋最適化有り(12c) モデルの評価

実行計画の各種最適化機能により、予測精度が高く性能も良い、多種多様なプランを複数使用／併用できる。

– 予測精度が高い ⇒ リスクが低いと云うこと。

更に適応計画による実行計画の動的補正により、ハズレの実行計画によるリスクを、11gR2 より低く抑えられる。

– 予測精度の高さと併せて 2重のリスクヘッジ

要するに製品機能の進化によって、昔よりも統計最新化運用のメリットは増え、リスクは減ってきている。

– 昔とは状況が変わってきている、、、と云うのがポイント


53

フレッシュな統計と各種最適化機能による、予測精度が高くて性能も良い実行計画


54

Oracle の実行計画最適化機能は、 CBOの予測精度向上のために存在している。

これらをフル活用して予測精度を上げると云う設計思想は、SQLの特徴に真正面から立ち向かう、いわば王道なんやで。

統計固定派／Bind Peek否定派の皆さん、思い出しましたか？

– 特にBind Peek を"常に"悪者扱いしている、そこの貴方！m9(｀･ω･´)

皆さん、思いだしたやろか？彡(^)(^)

55

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

56

このガイド

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

57

違います。

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

58

こうです。

「ミッションクリティカルなシステムでは、 Oracle Database の有識者を常時アサインしておくことが推奨です。」

「その Oracle Database の有識者が、オプティマイザ統計を常時管理／固定するのを前提に、Bind Peek等を無効化します。」

「常時貼り付いた有識者が実行計画を固定することにより、SQL性能劣化のリスクを抑制します。」

59

これを曲解して、こんな感じにすると……

(^w^)「取り敢えず Bind Peek は無効化した方がエエらしいで。統計は採らんで放っとこ。」

(^w^) 「0件統計？NULL統計？知らんわそんなん。有名なコンサルさんの本にも書いとるし、 Oracle Database が何とかしてくれるやろ。イザとなったらサポートに押し付けたろ。」

(^w^)「ミッションクリティカル(笑)なシステムを隠しパラメータ(笑)で安定させるワイ、おしゃれでカッコええやな～～。」ﾊﾅﾀｶｰ

60

こうなってしまう。(※全部実話、涙)

最近対応したSQL性能トラブルのやり取り ※全て統計固定の環境

彡(ﾟ)(ﾟ) 「MView実体表の統計が0件やで。実行計画悪いやで。」

(´･ω･｀)「すみません。MViewって統計有るんでしたっけ？？？」

彡(ﾟ)(ﾟ) 「索引の統計が0件で、実行計画悪いやで。」

( ^ω^) 「ごめんね。索引って統計有るんでしたっけ？？？」

彡(ﾟ)(ﾟ) 「エンドユーザ様が使う研修環境の統計が0件/Null統計の嵐で、まともなSQL性能が出てないンゴよ。お客さん激おこやで。」

(*^○^*)「研修環境なんて知らないんだ！本番しか管理しないんだ！研修環境はデータ少ないのに、変な実行計画を選ぶOracleが悪いんだ！」

彡()()「」

【悲報】統計固定、リスクヘッジにならない。


61

なぜこうなってしまうのか？それは……

それは "性能劣化リスク" でしか評価してないから。

No 統計情報運用／最適化機能モデル性能劣化リスク

① 固定化運用＋最適化無し

◎ 性能変動の要素がデータ増

以外無く、低リスク

② 最新化運用＋最適化有り

△ ハズレの実行計画の可能性

をゼロにはできない

③ 最新化運用＋最適化無し

× 最適化機能無しのため ②より劣化リスクは高い

採用！

62

最低限、これ位の軸(例)で評価せんと(アカン)

"SQL性能" "運用負荷" "性能劣化リスク" の 3軸による評価例

No 統計情報運用／最適化機能モデル SQL性能運用負荷性能劣化リスク


× 低精度な統計に加え最適化機能無し

× 新アプリや新環境リリース時

のメンテナンス負荷




◎ 新鮮で高精度な統計と最適化機能の組合せ

◎ 自動化運用を重要視したモデル




△ 最適化機能無しのため ①よりも性能は低い

◎ C/O後の運用負荷は②と同等


63

①のモデルは運用がピーキー

①はリスクヘッジ重視だが運用負荷がピーキーでキツい

















64

①のモデルは運用がプア(有識者不在)だと……

①で運用がプア(有識者不在)だと、悲惨！(オール×)






× 【悲報】統計固定、

リスクヘッジにならない。










65

①を上手く運用するには、以下の要素が必要

– Oracle Database の有識者

– その有識者を貼り付ける体制(コスト意識)

– 何よりも重要なのは、「Oracle Database の CBO など信用できない！SQLの実行計画は我々自身の手で管理、運用するのだ！」と云うモチベーション

このモチベーションが欠けたまま、「ミッションクリティカル」とか「隠しパラメータ」とかの言葉に踊らされて、これを安易に採用すると……

①のモデルを上手く運用するための要素

66

こうなる。(しつこい

最近対応したSQL性能トラブルのやり取り ※全て統計固定の環境

彡(ﾟ)(ﾟ) 「MView実体表の統計が0件やで。実行計画悪いやで。」

(´･ω･｀)「すみません。MViewって統計有るんでしたっけ？？？」

彡(ﾟ)(ﾟ) 「索引の統計が0件で、実行計画悪いやで。」

( ^ω^) 「ごめんね。索引って統計有るんでしたっけ？？？」

彡(ﾟ)(ﾟ) 「エンドユーザ様が使う研修環境の統計が0件/Null統計の嵐で、まともなSQL性能が出てないンゴよ。お客さん激おこやで。」

(*^○^*)「研修環境なんて知らないんだ！本番しか管理しないんだ！研修環境はデータ少ないのに、変な実行計画を選ぶOracleが悪いんだ！」

彡()()「」

【悲報】統計固定、リスクヘッジにならない。


67

②のモデルはトータルのバランスが良い。

②は"性能" "運用" "リスク" のバランスに優れている。

















68

②' は 12c新機能の恩恵で更に良くなっている。

②' は 12c新機能の恩恵で、リスクが更に低くなっている。








②' 最新化運用＋最適化有り(12c)



○ 12cの各種補正機能により、ハズレのリスクが低下





69

②(②') を勧めると、良く言われます。

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

70

違います。

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

71

②' はバランスが良いから勧めてるんやで。

②' はトータルバランス、特に運用負荷とリスクヘッジのバランスがそこそこに良いので、よくお勧めしてます。

経験上、運用がプアなお客様だとこのモデルの方が上手く廻って、結果としてリスクヘッジになると感じてます。

‒ さっきも説明した通り、①は運用がプアだと悲惨そのもの

SQL性能が良いのは、まあ言うたらオマケやね彡(ﾟ)(ﾟ)






72

更にこの(②')モデル、新しい世界が待っている。

更にこの(②')モデル、新しい世界が待っています。

実行計画の各種最適化機能と、オプティマイザ統計の最新化運用が組み合わさると…

‒ヒストグラム

‒拡張統計(列グループ統計／式の統計)

‒SQLワークロード(col_usage$)

‒SQL計画ディレクティブ

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

各種最適化機能と、最新化運用が組み合わさると…


実行計画

⑥ヒント句









実データ


インフラ



• ①様々なSQLが実行 ⇒ ②多様なSQL計画ディレクティブ／SQLワークロードが蓄積 ⇒ ③多様なヒストグラム／拡張統計が採取 ⇒ ④更に性能の良い実行計画が選択！




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


③SQL計画ディレクティブや SQLワークロード(COL_USAGE$)により、多様なヒストグラム／

拡張統計が採取される。

75



実行計画

⑥ヒント句









実データ


インフラ







Directive 1

Directive 2

Directive 3

Directive 4

Workload 1

Workload 2

Workload 3

Workload 4




④性能の良い実行計画が選択される。





・進化する統計！・進化する実行計画！・進化するSQL性能！

76

③のモデルは中途半端だけど、割と多い

③は中途半端、安全神話"Bind Peek無効化"の負の遺産？
















77

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

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

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

「安全神話」の意味

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

– hatena keywordより


78

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

どちらが良いか？もはや何も言うことは無いやで彡(-)(-)

③最新化＋最適化無し ②' 最新化＋最適化有り(12c)


79

統計は最新化するけど、とりあえず Bind Peek等は無効化しとこう、みたいなノリ？

– ノールック"Bind Peek(等)無効化"

– 脊髄反射な"Bind Peek(等)無効化"

ちゃんとメリ／デメを整理して判断できとりますか？よくよく考えた方が、エエんちゃいますか？ – Bind Peek等を無効化していても、

オプティマイザ統計を最新化している時点で実行計画は変動するんやで彡(-)(-)

③のモデルの採用は、よくよく考えるんやで！

80

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

81

最新化運用＋最適化有りのモデルを積極的に

採用したことが有る人、

挙手！( ﾟωﾟ)ﾉ

82

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

83

負のサイクル

Bind Peek(等) は使ったことない、不安だ。 ↓

不採用 ↓

Bind Peek(等) は使ったことない、不安だ。 ↓

不採用 ↓

Bind Peek(等) は使ったことｎ(以下、ループ

84

安心して下さい、使ってますよ。

とにかく明るい安村さんっぽい誰か (自主規制)

85

ワイ(AYU)の過去PJで振り返ってみる。

ワイ(AYU)、以前から最新化運用＋最適化有りのモデルを推進していて、そこそこ採用して貰った実績アリ。

それらの過去PJで、振り返ってみるやで彡(^)(^)

– 2011年～2012年、某Upgrade案件(9iR2⇒11gR2)

– 2012年～2013年、某複数システム集約案件(11gR2)

– 2013年～2014年、某マルチスタンバイ・Data Guard案件(11gR2)

86

2011年～2012年、某Upgrade案件(9iR2⇒11gR2)

同時8サブシステムのUpgrade(9iR2⇒11gR2)プロジェクト

87

2011年～2012年、某Upgrade案件(9iR2⇒11gR2)

同時8サブシステムのUpgrade(9iR2⇒11gR2)プロジェクト

CBO廻りの問題は無く、無事本番カットオーバー

※後にサブシステムD も統計最新化＋最適化有りモデルに移行

88

2012年～2013年、某複数システム集約案件(11gR2)

自動統計採取と最適化機能を併用し、インスタンス・ケージングで 2Node RAC に複数システムを集約

System A

RAC Node #1

RAC Node #2

System B

System C

89

2012年～2013年、某複数システム集約案件(11gR2)

自動統計採取と最適化機能を併用し、インスタンス・ケージングで 2Node RAC に複数システムを集約

System A

RAC Node #1

RAC Node #2

System B

System C 運用負荷の低減と性能担保を両立し、コスト削減も実現！

※公開事例にもなりました。

90

2013年～2014年、某マルチスタンバイ・Data Guard案件(11gR2)

非Exaな某マルチスタンバイ・Data Guard案件(11gR2)

あらゆる機能を生かす方針で、最新化運用＋最適化有りのモデルを採用

Primary

Standby Standby

REDOログ転送/適用

Data Guard Broker

91

2013年～2014年、某マルチスタンバイ・Data Guard案件(11gR2)

非Exaな某マルチスタンバイ・Data Guard案件(11gR2)

あらゆる機能を生かす方針で、最新化運用＋最適化有りのモデルを採用

Primary

Standby Standby

REDOログ転送/適用

Data Guard Broker

性能廻り／可用性関連の問題無しで、年単位での無停止稼働を今も継続中

92

更に、某案件でのあるSQLの実行時間推移グラフ某案件(12cR1)での、あるSQLの実行時間推移グラフ ※ポイントポイントでオプティマイザ統計を採取

過去現在

SQL性能が時間経過と共に改善している。

93

更に、某案件でのあるSQLの実行時間推移グラフ某案件(12cR1)での、あるSQLの実行時間推移グラフ ※ポイントポイントでオプティマイザ統計を採取

過去現在

・進化する統計！・進化する実行計画！・進化するSQL性能！

94



実行計画

⑥ヒント句









実データ


インフラ







Directive 1

Directive 2

Directive 3

Directive 4

Workload 1

Workload 2

Workload 3

Workload 4




④更に性能の良い実行計画が選択される。





95



実行計画

⑥ヒント句









実データ


インフラ







Directive 1

Directive 2

Directive 3

Directive 4

Workload 1

Workload 2

Workload 3

Workload 4




④性能の良い実行計画が選択される。





この新しい世界をまさに実現！

96

５章. まとめ

97

まとめ

まずは実行計画は"予測"であり、"ハズレ"が有り得ると云う事実を受け容れること。

– チューニングや運用設計の視野が広がり、引き出しも増える。

統計固定化＋最適化無しの運用は今後も生き残るが、メリットは相対的に薄れつつある。

– 「とりあえず Bind Peek は無効化」はダメ、絶対。

統計最新化＋最適化有りの運用と 12cR1 の組み合わせで、新しい世界が広がる！

– 進化する統計！進化する実行計画！進化するSQL性能！

– CBOの機能を抑え込んで制御するのではなく、 CBOの機能を引き出して予測精度を上げると云う設計思想

98

あなたはどちらを選びますか？

統計固定化のストイックな世界統計最新化のやさしい世界

99

お詫び

相変わらず内容は煽り全開ですが、その方が喰い付きが良いだろうと云う目論見で、他意はありません。

和むように、しまむらくんを置いてきますね。。。

100

QA＆ディスカッション

何でもどうぞ！

101

おわり

ご清聴、サンガツだったやで！

固定化か？最新化か？オプティマイザ統計の運用をもう一度考える。 -JPOUG...

Technology

Transcript of 固定化か？最新化か？オプティマイザ統計の運用をもう一度考える。 -JPOUG...