まだ統計固定で消耗してるの？ - bind peek をもっと使おうぜ！ 2015 edition -

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

柴田歩

2

免責事項／注意事項

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

3

自己紹介

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

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

2007年4月に中途で入社

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

4

コンテンツ

コレ

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













5

こうならんように、今年も頑張ります。

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

6

目次

１章. イントロダクション

２章. 前提知識

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

４章. まとめ

7

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

8

今年のお題

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

9

こんなガイド、してませんか？

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

10

範馬刃牙さんから一言

11

統計固定は果たして安全なんだろうか？

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

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

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

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

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

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

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

彡()()「」

12

統計固定はデメリットも多いのだが、、、

統計固定はデメリットも多いのだけど、そのデメリットには余り目が向いてない気がする。

にも関わらず、そのデメリットを考慮せずに統計固定を呪文のように唱え続るのは良くないすよ(ﾟεﾟ )

– そう云う人は割と多いんじゃないか？？？

Bind Peek等、実行計画で関連する機能も振りかえりつつ、もう一度考えてみる。

13

2章. 前提知識

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

SQLと云う言語の特徴

SQLと云う言語は、データ抽出時に「何を（What）抽出するか」の“条件”のみを記述し、「どうやって(How)抽出するか」を記述しない、他言語には無い特徴を有します。

– 多くの言語では、繰り返し（for～, while～）や条件分岐（if～, case～）などのアルゴリズムを記述する必要があります。

どうやって（How）データを抽出するか、即ちアルゴリズムの決定・制御は、RDBMS の Optimizer で行われます。

– Optimizer が決定したアルゴリズム = 実行計画です。

プログラム

“条件”のみを記述

Op

timiz

er

SQL データ

アルゴリズムを決定／制御

※Oracle DBA & Developer Day 2013 資料より

20

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

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

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

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

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

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

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

※Oracle DBA & Developer Day 2013 資料より

21

「予測」と「Bind Peek(他)」の関係

SQLの実行計画は「予測」で組み立てられ、「予測」である以上、ハズレから逃れられません。

– OracleDB に限らない、全てのRDBMSに共通した困難

そして「Bind Peek」を初めとした実行計画最適化機能は、

全て実行計画の予測精度を上げる、

あるいは予測を補正するために存在します。

– ハズレの実行計画を引く確率を下げる。

– あるいはハズレた予測(実行計画)を補正する。

これらの前提を踏まえた上で、次逝ってみよう！(｀･ω･)Ъ


22

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

SQL計画ディレクティブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31

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

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

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

– ②最新化運用＋最適化有りのモデル

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

32

①固定化＋最適化無しモデルのSQL処理時間イメージ

時間経過(データ件数)

処理時間短

長

PLAN2

単一PLANを使い続ける

動作するプラン


33


処理時間短

長

PLAN1 PLAN2 PLAN3

PLAN4

複数PLANのコスト(予測) 近接点で、各PLANを併用しながら少しづつ遷移していくイメージ


②最新化＋最適化有りモデルのSQL処理時間イメージ去年のBind Peek をもっと使おうぜ！より

34


処理時間短

長

PLAN2

PLAN4

ハズレのPLANを引いた時の性能劣化が大きい動作するプ

ラン

PLANのバリエーションも少ない。(列統計／ヒストグラム未使用)

ある瞬間では単一PLANしか選択されない(※複数PLAN併用不可)

③最新化＋最適化無しモデルのSQL処理時間イメージ去年のBind Peek をもっと使おうぜ！より

35

② と ③ の性能変動モデルケース比較「赤線」が直線に近いほど、リスクは低い。

どっちが直線に近いか？？？と云うこと

②最新化＋最適化有り ③最新化＋最適化無し


36

ここまでが去年の話

ここに12cの新機能が加わると…

ここまで去年の話

37


処理時間短

長

PLAN1 PLAN2 PLAN3

PLAN4

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

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


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

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

PLAN5 PLAN6

38

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

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

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

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

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

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

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

39

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

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

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

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

40

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

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

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

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

41

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

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

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

42

更にこのスライドを振り返ってみる。








彡()()「」

43

ウォーターフォールなPJで考えてみると…(1/2)

以下のようなウォーターフォールなプロジェクトで考えてみる。

要件定義／

設計フェーズテストフェーズ運用フェーズ

タスク

(Design)

タスク

(Test)

タスク

(manage

ment)

設計

機能テスト

結合テスト

性能テスト

運用

要件定義

44

ウォーターフォールなPJで考えてみると…(2/2)

システムを作る時には有識者を入れて頑張るが、運用に入ると、高コストな有識者を貼り付けるケースはレア。

要件定義／

設計フェーズテストフェーズ運用フェーズ

タスク

(Design)

タスク

(Test)

タスク

(manage

ment)

設計

機能テスト

結合テスト

性能テスト

運用

要件定義

・ここは有識者を入れて頑張る。

・ここに有識者を常時貼り付けるケースは少ない。

45

統計固定は運用負荷が高いと云うデメリットも…

統計固定の運用はSQL性能が低いだけでなく、カットオーバー後の運用負荷がキツい！と云うデメリットもあります。

– 本番環境 ⇔ 保守環境 ⇔ 検証環境との統計同期／管理

– アプリ(表/索引)リリースに伴う統計情報の変更／同時リリース

– データ肥大後の統計採取検討／再テスト、etc...

一方システムが運用フェーズに突入すると、統計やDBに詳しい有識者を常時貼り付けるのは、コスト面で厳しい。

– 運用フェーズに有識者が居ない体制は、

「運用負荷がキツい！」と云うデメリットと相反する。

46

有識者が居ないのに統計固定運用を採用すると…








彡()()「」

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

47

もう一度、良く考え直してみよう。

カットオーバー後の体制や運用負荷、SQL性能が低い等のデメリットを考慮せず、「バカの一つ覚え」みたいに

「統計固定最高!!!Bind Peek(等)は無効化しか有り得ません!!!」ｷﾘｯ! の様なガイドをしていませんか?

48

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

49

マヂでもう一度、考え直してみよう。

統計最新化／最適化機能全開の組み合わせが、性能／リスクヘッジの両面で選択肢に入る。

– 去年も言いましたが、少なくとも今は統計固定／Bind Peek(等)無効化一択の時代じゃない。

– 統計固定運用は、逆にリスクになる事も…

ではどのようなシステムや体制が、この資料で出してきたモデルにマッチするかと云うと、、、

50

今年もここまで

51

4章. まとめ

52

まとめ

統計固定運用は、SQL性能が低くカットオーバー後の運用負荷もキツいと云うデメリットがある。 – リスクヘッジ優先の方針だが、ピーキーな運用を強いられる。

– 運用フェーズにおける体制と覚悟が無いと、逆にリスク要因に

統計最新化／最適化機能全開の組み合わせは、性能／リスクヘッジの両面で有力な選択肢に。 – DB12c の新機能によって、更に改善されている。

統計固定を *安易に* ガイドするのは、非推奨 – 思考停止してませんか？もう一度良く考え直してみましょう。

53

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

54

今年のお題(回答)

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

統計最新化と最適化機能全開で、ラクしながらリスクヘッジしよう！

55

お詫び

今年も文章は煽り気味ですが、その方が喰い付きが良いだろうと云う目論見で、他意はありません。

和むように、荒巻(スカルチノフ) を置いてきますね。。。

56

画像引用元(引用順)

グラップラー刃牙・板垣恵介(著)・秋田書店(出版)

スラムダンク・井上雄彦(著)・集英社(出版)

57

おわり

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

まだ統計固定で消耗してるの？ - bind peek をもっと使おうぜ！ 2015 edition -

Technology