how to use the powerpoint template...2016/04/13 · 初期化パラメータ説明

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |

第166回夜な夜な! なにわオラクル塾

Oracle12c オプティマイザ最新情報

日本オラクル株式会社クラウド・テクノロジー事業統括データベースソリューション本部中部・西日本ソリューション部 2016年04月13日


以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

2


Program Agenda

実行計画最適化の強化

その他の統計情報に関する新機能

SQL計画管理(SPM)の新機能

パラレル実行に関する新機能

1

2

3

4

3


オプティマイザの改良の必要性

ルールベース

オプティマイザコストに基づく

オプティマイザの改良

CBO

CBO

オプティマイザがプロアクティブに適用できるように自己学習する

ルールが追随できない

Databases 新機能の追加

アドバイザや自動化ジョブでのりアクティブなチューニング

環境が変わると計画変更が求められる

データベースに対してリアルタイム性やアドホックさがより求められるリアクティブなチューングでは不十分


Oracle 12c(12.1.0.2)新機能(パフォーマンス改善機能) • 適応問合せ最適化

• 適応SQL計画管理

• 適応計画のSQLモニター・サポート

• 自動列グループ検出

• UNIONおよびUNION ALLによるブランチの同時実行

• 同時統計収集

• 複数フラッシュ・デバイスのデータベース・スマート・フラッシュ・キャッシュのサポート

• 動的統計

• パラレル・ステートメント・キューの拡張

• 増分統計の拡張

• システム統計の拡張

• 自動並列度の改善

• 新しいタイプのオプティマイザ統計

• バルク・ロードのオンライン統計収集

• ホーム外のマテリアライズド・ビュー・リフレッシュ

• グローバル一時表のセッションプライベート統計

• SQL計画ディレクティブ

• 同期マテリアライズド・ビュー・リフレッシュ

• Resource Managerのランナウェイ問合せ管理

5


非推奨となった機能

• 次の機能は、今回のリリースで非推奨となっており、将来のリリースではサポートされなくなる –ストアド・アウトライン

• 代替機能は、SQL計画ベースライン

– CURSOR_SHARING初期化パラメータのSIMILAR値 • 代替として、FORCEを使用

6


Program Agenda





1

2

3

4

7


実行計画最適化の強化 SQL実行時に統計を収集し、より適切なSQL実行計画を選択する • 最適な実行計画を生成するために既存の統計では十分でない場合に有用

• 以下の二つの仕組みで実行計画を適応

– 適応計画(Adaptive Plans): SQL 実行時に実行計画の適応を行う

– 適応統計(Adaptive Statistics)：SQL 実行時に得た統計を次回の実行時にフィードバックし、実行計画の適応を行う

• 動的統計(Dynamic Statistics)

• 自動再最適化(Automatic Reoptimization)

• SQL計画ディレクティブ(SQL Plan Directives)

8

適応問合せ最適化

適応計画 (Adaptive Plans)

適応統計 (Adaptive Statistics)

結合方法

パラレル配分方法

コンパイル時

実行時


適応計画(Adaptive Plans)とは

• 問合わせ実行時に収集した統計を基に最終的なSQL実行計画を決定

– 既存の統計を基にSQL実行計画を作成 (デフォルトプラン)

– 実行時に収集した統計をもとに実行計画の一部を実行時の条件に適したサブプランに切り替える

• 設定

– デフォルト有効

– 初期化パラメータで有効/無効の設定

• OPTIMIZER_FEATURES_ENABLE初期化パラメータが12.1.0.1以降

• OPTIMIZER_ADAPTIVE_REPORTING_ONLY初期化パラメータがfalse(デフォルト)

• レポート表示

– 適応計画によるSQL実行計画の変化を確認可能

9

パース

オプティマイゼーション

行ソースジェネレーター

実行

SQL 文入力

出力

実行計画の作成

実行時統計を収集し、ファイナルプランの決定

実行計画の最終決定は実行時


適応計画の仕組み実際の条件に応じてサブプランを切り替える • サブプラン

– 切り替え可能なSQL実行計画の一部分

– サブプランの種類 • 結合方法

• パラレル配分方法

• 切り替えのしきい値はオプティマイザが決定

– 例: order_items表から取り出す行数が 10 以上ならハッシュ結合を選択

10

SELECT product_name FROM order_items o, product_information p WHERE o.unit_price = 15 AND p.product_id = o.product_id

サブプラン

Hash Join Nested Loops Join

デフォルトプラン

行数が 10 以上行数が 10 より下


適応計画の動作イメージ 1. 既存の統計情報を基にデフォルトプランを作成

2. 統計コレクタが実際の統計(結合する行数など)を取得

3. 取得した統計を基に使用するサブプランを選択し、最終プランを決定

11

Hash Join

Table B scan Table A scan

Nested Loop Join

Index scan Table A scan

Hash Join

Table B scan

行数をカウント

デフォルトプラン(ネステッドループ結合を選択)

しきい値を超えたため

サブプランを変更

Nested Loop Join

Index scan

統計コレクタ

ファイナルプラン(最終的にハッシュ結合を選択)


適応計画実行例デフォルトプランの確認 • SQL文

• デフォルトプランの確認

12

SELECT /*+DEMO */ product_name FROM order_items o,

product_information p WHERE o.unit_price = 15 AND p.product_id =

o.product_id;

EXPLAIN PLAN FOR <SQL文>;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(FORMAT=>’BASIC +NOTE’));

Plan hash value: 1255158658

---------------------------------------------------------------

| Id | Operation | Name |

---------------------------------------------------------------

| 0 | SELECT STATEMENT | |

| 1 | NESTED LOOPS | |

| 2 | NESTED LOOPS | |

| 3 | TABLE ACCESS FULL | ORDER_ITEMS |

| 4 | INDEX UNIQUE SCAN | PRODUCT_INFORMATION_PK |

| 5 | TABLE ACCESS BY INDEX ROWID| PRODUCT_INFORMATION |

---------------------------------------------------------------

Note

-----

- this is an adaptive plan

デフォルトプランはネステッド・ループ結合を選択


適応計画実行例ファイナルプランの表示 • SQL 文の実行後、ファイナルプランを確認

13

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>’rowstats’));

Plan hash value: 1553478007

-----------------------------------------------------------------------------

| Id | Operation | Name | Starts | E-Rows | A-Rows |

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | 13 |

|* 1 | HASH JOIN | | 1 | 4 | 13 |

|* 2 | TABLE ACCESS FULL| ORDER_ITEMS | 1 | 4 | 13 |

| 3 | TABLE ACCESS FULL| PRODUCT_INFORMATION | 1 | 1 | 288 |

-----------------------------------------------------------------------------

… (略) …

Note

-----

- this is an adaptive plan

最終的にハッシュ結合を選択


適応計画のサブプランを出力

• サブプランを含んだSQL実行計画を表示 – 置き換えられる可能性のあるサブプランも表示

– 使用されないサブプランを示す印 (-) を表示

• 作成されたすべてのサブプランを確認可能

• 表示方法 – DBMS_XPLANファンクションのFORMATパラメータに’ADAPTIVE’をセット

14

select * from table(dbms_xplan.display_cursor(format=>‘adaptive'));


サブプランの出力

15

---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | * 1 | HASH JOIN | | 4 | 948 | |- 2 | NESTED LOOPS | | | | |- 3 | NESTED LOOPS | | 4 | 948 | |- 4 | STATISTICS COLLECTOR | | | | | * 5 | TABLE ACCESS FULL | ORDER_ITEMS | 4 | 72 | |- * 6 | INDEX UNIQUE SCAN | PRODUCT_INFORMATION_PK | 1 | | |- 7 | TABLE ACCESS BY INDEX ROWID| PRODUCT_INFORMATION | 1 | 219 | | 8 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 219 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID") 5 - filter("O"."UNIT_PRICE"=15) 6 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID") Note ----- - this is an adaptive plan (rows marked '-' are inactive)

サブプラン (Hash と Nested Loop) を表示

使用されないものには Id に ’ - ‘ を表示


適応計画の確認

• v$SQL ビューの IS_RESOLVED_ADAPTIVE_PLAN 列 – 実行したSQL文の実行計画が適応計画の場合は値が入る

– 適応計画ではない場合は NULL

• SQL実行計画の Note セクション –適応計画の場合は Note セクションに表示

16

SELECT sql_id, is_resolved_adaptive_plan AP FROM v$sql WHERE sql_id='9vtk6ymuv5yr0';

SQL_ID AP

------------- ---

9vtk6ymuv5yr0 Y

Note ----- - this is an adaptive plan


適応計画の確認

• SQL監視での確認(12.1.0.2-) –リアルタイムSQL監視機能で実行計画が適応計画かどうかを表示

• その現在のステータス(解決中または解決済)を表示

–現在の計画、完全計画または最終計画を選択できるリストを提供

17


適応計画の制御

• 初期化パラメータ OPTIMIZER_ADAPTIVE_REPORTING_ONLY で有効/無効を設定 –デフォルトは有効 ( 設定値: FALSE )

– ALTER SYSTEM、ALTER SESSION による設定が可能

• OPTIMIZER_ADAPTIVE_REPORTING_ONLY を TRUE に設定した場合 –レポートのためのモードとなり、実行計画の変更は行わない

–適応計画に必要な統計の収集は実施

18


適応計画のレポート出力

• SQL実行計画の適応内容を表示

– 変更前と変更後の実行計画を表示

– 実行計画が変化しない場合はファイナルプランのみを表示

• SQL実行時の実行計画を変更せずに、適応計画による実行計画の変化を確認可能

– 適応計画の影響をテスト

• 表示方法

1. レポート・モードに設定

• 初期化パラメータ OPTIMIZER_ADAPTIVE_REPORTING_ONLYをTRUEにセット

2. SQL文を実行

3. DBMS_XPLAN.DISPLAY_CURSOR ファンクションの FORMAT パラメータに ’REPORT’ をセットして SQL実行計画を表示

19

select * from table(dbms_xplan.display_cursor(format=>‘report'));


適応計画のレポート出力 (抜粋)

20

------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 7 (100)| | | 1 | NESTED LOOPS | | | | | | | 2 | NESTED LOOPS | | 4 | 948 | 7 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | ORDER_ITEMS | 4 | 72 | 3 (0)| 00:00:01 | |* 4 | INDEX UNIQUE SCAN | PRODUCT_INFORMATION_PK | 1 | | 0 (0)| | | 5 | TABLE ACCESS BY INDEX ROWID| PRODUCT_INFORMATION | 1 | 219 | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------

…(略)… Adaptive plan: ------------- This cursor has an adaptive plan, but adaptive plans are enabled for reporting mode only. The plan that would be executed if adaptive plans were enabled is displayed below.

Plan hash value: 1255158658 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 7 (100)| | |* 1 | HASH JOIN | | 4 | 128 | 7 (0)| 00:00:01 | |* 2 | TABLE ACCESS FULL| ORDER_ITEMS | 4 | 48 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| PRODUCT_INFORMATION | 1 | 20 | 1 (0)| 00:00:01 |

------------------------------------------------------------------------------------------

デフォルトプランと

適応計画により変更したSQL実行計画を表示


適応統計

• オプティマイザが生成する実行計画の品質は、統計情報の品質に依存

• 複雑すぎるSQL文では実表の統計のみでは不十分な場合がある –そのような場合に、オプティマイザは統計情報を適応統計で増強する

• 適応統計のタイプとして以下が存在 –動的統計

–自動再最適化

– SQL計画ディレクティブ

21


動的統計

• SQL文のコンパイル時に、最適な実行計画を生成するために使用可能な統計が十分にあるかどうかを検討し、動的統計を使用するかどうかを判断 –使用可能な統計が不十分な場合、オプティマイザは動的統計を使用して統計を増強

–以前の動的サンプリングでは、統計情報が欠落しているか、不十分な場合に統計情報を補完 • 動的サンプリングはOracle 12cから動的統計(Dynamic Statistics)という名称に変更

– Oracle 12c では全てのSQL文に対して動的統計が有用かどうか、どのレベルで使用するかを自動的に決定することが可能

• 収集した統計は永続的であり、他のクエリからも使用可能

22


動的統計の強化

• 設定パラメータとヒントの名前は変更なし –初期化パラメータ: OPTIMIZER_DYNAMIC_SAMPLING

• サンプリングレベルに新しく「11」が追加

• 初期化パラメータOPTIMIZER_DYNAMIC_SAMPLING を 11 に設定することで動的統計が有用か判断

–ヒント: DYNAMIC_SAMPLING

• 実行計画のNote部分にlevel=AUTOを表示

23

Note

-----

- dynamic sampling used for this statement (level=AUTO)


自動再最適化(Automatic Reoptimization)とは

• 2回目以降のSQL実行時に実行計画を適応

– 実行時に収集した統計が見積もりと大きく異なる場合、その情報を記録

– 次回SQL実行時に記録した統計を使用して実行計画を作成

• 見積もりから作成したSQL実行計画を修正

– 既存の統計が不正確

– SQL文の述語が複雑など

• 適応計画では解決できないSQL実行計画も修正可能

– 結合の順番など

24

オプティマイザ SQL実行計画

カーソルに情報を記録

統計情報 1 回目の実行

オプティマイザ SQL実行計画

記録された情報を使用して実行計画を作成

統計情報 2 回目の実行


自動再最適化(Automatic Reoptimization)の種類

• 再最適化機能の種類

– 統計フィードバック

• SQL実行時に収集した統計を使用して実行計画を作成

• Oracle 11g R2 ではカーディナリティ・フィードバックと呼ばれていた

– パフォーマンス・フィードバック

• 収集した統計(例えば CPU time )を使用してパラレル度を改善

• SQL実行時に収集した情報は SQL 計画ディレクティブを使用して保持

– Oracle 11g R2 のカーディナリティ・フィードバックは保存されない

• レポートの表示

– 自動再最適化によるSQL実行計画の変化を確認可能

25


再最適化機能の種類(1) 統計フィードバック

• Oracle11g R2ではカーディナリティ・フィードバックと呼ばれていた

– カーディナリティの見積りが誤っている繰返し問合せの計画を自動的に改善 • 統計がない、統計が不正確である、述語が複雑であるなどの理由でカーディナリティを正しく見積ることができない場合がある

• 統計フィードバックを使用した再最適化のプロセス

– SQL文の初回実行時に、オプティマイザが実行計画を生成

• 次のような場合に、共有SQL領域の統計フィードバックの監視を有効化する

– 表に統計がない場合

– 接続フィルタ述語または選言フィルタ述語が表に複数ある場合

– オプティマイザが選択性の見積りを正確に計算できないような複雑な演算子が述語に含まれる場合

• 実行の最後に、オプティマイザは最初のカーディナリティの見積りと、実行時の実際の行数を比較

• 見積りが実際のカーディナリティと大きく異なる場合、オプティマイザは以降に使用するために正しい見積りを保存

– オプティマイザは、最初の実行時に取得された情報を他のSQL文が有効に利用できるようにSQL計画ディレクティブも作成

– 初回実行後、統計フィードバックの監視を無効化

– SQL再実行時は、修正されたカーディナリティの見積りを使用

26


再最適化機能の種類(2) パフォーマンス・フィードバック

• 繰返し実行されるSQL文の自動選択されたパラレル度を改善する機能

– PARALLEL_DEGREE_POLICYをADAPTIVEに設定することで動作(デフォルトはMANUAL)

• パフォーマンス・フィードバックを使用した再最適化のプロセス

– SQL文の初回実行時に、オプティマイザはパラレルに実行するかどうか、実行する場合はパラレル度をどうするかを決定 • オプティマイザは、文の推定パフォーマンスに基づいてパラレル度を選択

• すべての文に対して追加のパフォーマンス監視が有効

– SQL文の初回実行の最後に、オプティマイザは以下を比較 • オプティマイザによって選択されたパラレル度

• SQL実行時に収集されたパフォーマンス統計(CPU時間など)に基づいて計算されたパラレル度

– 2つの値が大幅に異なる場合、そのSQL文は再解析の対象となり、初回の実行統計がフィードバックとして保存

– SQL再実行時は、初回実行時に収集されたパフォーマンス統計を使用して、より適切なパラレル度を決定

27


自動再最適化の確認

• v$SQLビューのIS_REOPTIMIZABLE列 –次回SQL実行時に再最適化による適応が行われるかを示す

• Y: 次回にSQL実行計画を再最適化する

• N: 次回にSQL実行計画を再最適化しない

• R: レポートモードでコンパイルされたため、再最適化しない

• v$SQL_SHARED_CURSORビューのUSE_FEEDBACK_STATS列 –次回SQL実行時に再解析を行う場合はYを格納

• Oracle 11g R2と同様の動作

28


自動再最適化の制御

• 初期化パラメータ OPTIMIZER_ADAPTIVE_REPORTING_ONLY で有効/無効を設定 –デフォルトは有効 ( 設定値: FALSE )


–適応計画と同じ初期化パラメータ

• OPTIMIZER_ADAPTIVE_REPORTING_ONLY を TRUE に設定した場合 –レポートのためのモードとなり、SQL実行計画の変更は行わない

–自動再最適化に必要な統計の収集は実施

29


自動再最適化の実行例 1 回目のSQL実行時に統計の乖離を認識 SQL文の実行

実行計画を確認

30

SELECT /*TEST*/ o.order_id, v.product_name FROM orders o,

( SELECT order_id, product_name FROM order_items o, product_information p

WHERE p.product_id = o.product_id AND list_price < 50 AND min_price

< 40 ) v

WHERE o.order_id = v.order_id;

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | | | 269 |

| 1 | NESTED LOOPS | | 1 | 1 | 269 |

| 2 | MERGE JOIN CARTESIAN| | 1 | 4 | 9135 |

|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 1 | 87 |

| 4 | BUFFER SORT | | 87 | 105 | 9135 |

| 5 | INDEX FULL SCAN | ORDER_PK | 1 | 105 | 105 |

|* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 9135 | 1 | 269 |

---------------------------------------------------------------------------------

見積もりと実際の統計が離れている


自動再最適化の実行例 2回目のSQL実行時にSQL実行計画を再最適化 • 2回目のSQL実行時のSQL実行計画

31

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | 269 |

| 1 | NESTED LOOPS | | 1 | 269 | 269 |

|* 2 | HASH JOIN | | 1 | 313 | 269 |

|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 87 | 87 |

| 4 | INDEX FAST FULL SCAN| ORDER_ITEMS_UK | 1 | 665 | 665 |

|* 5 | INDEX UNIQUE SCAN | ORDER_PK | 269 | 1 | 269 |

---------------------------------------------------------------------------------

…(略) …

Note

-----

- statistics feedback used for this statement

実際の条件に適応した

見積もりになった

実行計画が変更された

Note部分にstatistics

feedback の出力


自動再最適化の実行例再最適化を行った子カーソルを作成 • 2回目のSQL実行後のカーソルの状態

32

select sql_id, PLAN_HASH_VALUE, child_number, is_reoptimizable

from v$sql where sql_text like '%TEST%';

SQL_ID PLAN_HASH_VALUE CHILD_NUMBER IS_

--------------------------------------- --------------- ------------ ---

46cxwf85u43ga 1906736282 0 Y

46cxwf85u43ga 35479787 1 N

再最適化が終了した子カーソルはIS_REOPTIMIZABLE列をNと表示


自動再最適化のレポート出力

• SQL実行計画の再最適化内容を表示 – 変更前と再最適化後の実行計画を表示

–実行計画を変更せずに、再最適化による実行計画の変化を確認可能

• 表示方法 1. レポート・モードに設定

• 初期化パラメータ OPTIMIZER_ADAPTIVE_REPORTING_ONLYをTRUEにセット

2. SQL文を実行

3. DBMS_XPLAN.DISPLAY_CURSOR ファンクションの FORMAT パラメータに ’REPORT’ をセットしてSQL実行計画を表示

33

select * from table(dbms_xplan.display_cursor(format=>’report’));


自動再最適化のレポート出力変更前のSQL実行計画に加えて、自動再最適化により変更した実行計画を表示

34

--------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 6 (100)| | | 1 | NESTED LOOPS | | 1 | 40 | 6 (0)| 00:00:01 | | 2 | MERGE JOIN CARTESIAN| | 4 | 128 | 6 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 28 | 5 (0)| 00:00:01 | | 4 | BUFFER SORT | | 105 | 420 | 1 (0)| 00:00:01 | | 5 | INDEX FULL SCAN | ORDER_PK | 105 | 420 | 1 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 1 | 8 | 0 (0)| | --------------------------------------------------------------------------------------------- --(略)-- Reoptimized plan: ----------------- This cursor is marked for automatic reoptimization, but automatic reoptimization is enabled for reporting mode only. The plan that would be selected on the next execution if automatic reoptimization were enabled is displayed below. Plan hash value: 35479787 ---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 269 | 10760 | 7 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 269 | 10760 | 7 (0)| 00:00:01 | |* 2 | HASH JOIN | | 313 | 11268 | 7 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 87 | 2436 | 5 (0)| 00:00:01 | | 4 | INDEX FAST FULL SCAN| ORDER_ITEMS_UK | 665 | 5320 | 2 (0)| 00:00:01 | |* 5 | INDEX UNIQUE SCAN | ORDER_PK | 1 | 4 | 0 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------

変更前と再最適化した場合のプランを表示


SQL 計画ディレクティブとは

• オプティマイザがより適したSQL実行計画を作成するための追加情報や指示 –欠落した統計の収集

–列グループの統計の作成

–動的統計の収集

• SQL実行時にカーディナリティが誤って見積もられた場合、ディレクティブを作成 –作成したディレクティブはSYSAUX表領域に格納し、永続化

• DBMS_SPDパッケージで管理 –ディレクティブ保持期間の変更など

35

SQL 計画ディレクティブ

列グループ統計が未作成だ動的統計を収集しよう

オプティマイザ

SQL文


SQL 計画ディレクティブとは似たパターンのSQL文には同じディレクティブを使用 • 特定のSQL文やSQL_IDに紐づきではない

• SELECT リストを除いた問合せ式の構造に収集

36

SELECT * FROM customers WHERE cust_state_province=‘CA’ AND country_id=52790;

SELECT * FROM customers WHERE cust_state_province=‘MA’ AND country_id=52790;

SELECT cust_city FROM customers WHERE cust_state_province=‘MA’ AND country_id=52790;

SELECT * FROM customers WHERE cust_state_province='CA' AND CUST_CITY='Los Angeles‘;

次のSQL文は異なるディレクティブを使用

以下のSQL文は同じディレクティブを使用する


SQL 計画ディレクティブ動作イメージ SQL 計画ディレクティブの作成

37

select * from

customers where

city=‘LA’ and

country=‘USA’;

1. SQL 文発行

共有SQL 領域

Cursor: select * from customers ….

Directive: Use DS for cardinarity ..

共有プール

2. オプティマイザが実行計画を決定

3. カーディナリティ見積もりの誤りを発見

動的統計のディレクティブを作成

ディレクティブは定期的にディスクに書き込まれる

SYSAUX


DBA_SQL_PLAN_DIRECTIVES DBA_SQL_PLAN_DIR_OBJECTS


SQL 計画ディレクティブ動作イメージ SQL 計画ディレクティブの使用

38

select * from

customers where

city=‘BOSTON’ and

country=‘USA’;

4 .列の値が異なるSQL 文を発行

共有SQL領域

Cursor: select * from customers ….

共有プール

5. オプティマイザがディレクティブを確認

city列とcountry列に

関するディレクティブを発見

SYSAUX


6. オプティマイザはディレ

クティブの指示を受けてSQL実行計画を決定

7. 次回の統計収集時にcity列とcountry列の列グループの統計を作成

DBA_SQL_PLAN_DIRECTIVES DBA_SQL_PLAN_DIR_OBJECTS


SQL 計画ディレクティブの管理 DBMS_SPDパッケージ • ディレクティブの保持期間設定

–使用されないディレクティブは53週後に自動的にパージ(デフォルト)

– DBMS_SPD.SET_PREFSプロシージャで期間を設定

• ディレクティブの削除 – DROP_SQL_PLAN_DIRECTIVEプロシージャでdirective_idを指定

39

DBMS_SPD.SET_PREFS('SPD_RETENTION_WEEKS', '4');

DBMS_SPD.DROP_SQL_PLAN_DIRECTIVE(<directive_id>);

例: 保持期間を4週間に設定


SQL 計画ディレクティブの制御

• 初期化パラメータ OPTIMIZER_ADAPTIVE_FEATURES で有効/無効を設定 –デフォルトは有効 ( 設定値: TRUE )


• 無効に設定した場合、他の適応機能も無効化される –適応計画、自動再最適化 (*)

–レポート・モードの設定(optimizer_adaptive_reporting_only=true)とは異なり、実行時統計の収集も行わない

40

OPTIMIZER_ADAPTIVE_FEATURES

SQL 計画ディレクティブ

適応計画

自動再最適化(*)

(*) 将来の対応。現在のリリースでは無効にできない


SQL 計画ディレクティブ実行例 SQL文の実行と実行計画の確認 • SQL文の実行

• SQL実行計画の確認

41

SELECT /*+gather_plan_statistics*/ * FROM customers WHERE cust_state_province='CA' AND country_id=52790;

-------------------------------------------------------------------------------

| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |

-------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | 3341 |00:00:00.02 | 1734 |

|* 1 | TABLE ACCESS FULL| CUSTOMERS | 1 | 20 | 3341 |00:00:00.02 | 1734 |

-------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(("CUST_STATE_PROVINCE"='CA' AND "COUNTRY_ID"=52790))

見積もりと実際の統計が大きく離れている

→ SQL 計画ディレクティブを作成


SQL 計画ディレクティブ実行例作成されたSQL計画ディレクティブを確認 • ディレクティブを確認

42

select o.object_name, o.subobject_name, o.object_type, d.type, d.state, d.reason

from dba_sql_plan_directives d, dba_sql_plan_dir_objects o where d.directive_id=o.directive_id and o.owner = 'SH';

OBJECT_NA SUBOBJECT_NAME OBJECT TYPE STATE REASON

--------- ------------------- ------ ---------------- ----- --------------------------------

CUSTOMERS CUST_STATE_PROVINCE COLUMN DYNAMIC_SAMPLING NEW SINGLE TABLE CARDINALITY MISESTIMATE

CUSTOMERS COUNTRY_ID COLUMN DYNAMIC_SAMPLING NEW SINGLE TABLE CARDINALITY MISESTIMATE

CUSTOMERS TABLE DYNAMIC_SAMPLING NEW SINGLE TABLE CARDINALITY MISESTIMATE


SQL 計画ディレクティブ実行例

• 変数の値が異なるSQL文を実行

43

SELECT /*+gather_plan_statistics*/ * FROM customers WHERE cust_state_province='MA' AND country_id=52790;

-----------------------------------------------------------------------------------------

| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |

-----------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | 181 |00:00:00.03 | 1535 |

|* 1 | TABLE ACCESS FULL| CUSTOMERS | 1 | 208 | 181 |00:00:00.03 | 1535 |

-----------------------------------------------------------------------------------------

… (略) …

Note

-----

- dynamic statistics used: dynamic sampling (level=3)

- 1 Sql Plan Directive used for this statement

値をCAからMAに変更

動的統計を実施して

SQL実行計画を作成


SQL 計画ディレクティブ実行例列統計の作成 • 統計の収集

• 統計の確認

44

exec dbms_stats.gather_table_stats(user, ‘CUSTOMERS’);

select table_name, extension_name, extension from user_stat_extensions;

CUSTOMERS

SYS_STS#S#WF25Z#QAHIHE#MOFFMM_

("CUST_STATE_PROVINCE","COUNTRY_ID")

ディレクティブにより列統計が作成された


SQL 計画ディレクティブによる永続化 SQL 計画ディレクティブと自動再最適化 • SQL実行時に認識した統計が不十分であるという情報はディレクティブを使用して永続化される

• 自動再最適化の統計情報を持ったカーソルがエージアウトなどで存在しない場合、ディレクティブを使用して統計を補完

45

SQL文の実行(初回)

自動再最適化を実施

カーソルが残っている場合

ディレクティブにより動的統計の収集を実施

・実行時統計のメモリ上への保存

・SQL 計画ディレクティブの作成

カーソルがエージアウトなどで存在しない場合

同じSQL文の実行


Program Agenda





1

2

3

4

46



• バルク・ロードのオンライン統計収集

• 同時統計収集

• グローバル一時表のセッション固有統計

• ヒストグラムの強化

47


バルク・ロードのオンライン統計収集

• Oracle 12cからバルク・ロード操作の中で統計の収集を自動的に実施 –ユーザによる統計収集を必要としない

• 表統計収集のための追加の表スキャンをしない

• これまではバルク・ロード後に手動で統計収集

• 以下のSQL文実行時に収集 – CREATE TABLE AS SELECT

– INSERT INTO … SELECT (空テーブルへのダイレクト・パス・インサート)

• 表統計、列統計を収集 –インデックス統計、ヒストグラムは収集しない

48


バルク・ロードのオンライン統計収集の設定

• 設定 – デフォルト設定で有効

– 無効にする場合、ヒントを設定

NO_GATHER_OPTIMIZER_STATISTICS

49

CREATE TABLE T1 AS SELECT /*+NO_GATHER_OPTIMIZER_STATISTICS */ * FROM SH.CUSTOMERS;


バルク・ロードのオンライン統計収集に関する注意

• 以下の条件の表はオンライン統計収集が行われない – sysのようなOracle所有のスキーマ

– ネステッド表

– 索引構成表(IOT)

– 外部表

– グローバル一時表(トランザクション固有一時表)

– バーチャル列を持つ表

– 表プリファレンスのPUBLISHがFALSEにセットされた表

– 表プリファレンスのINCREMENTALがTRUEにセットされたパーティション表に、パーティションを指定せずにバルク・ロードを実施した場合

• 収集されない: INSERT INTO salses SELECT …

• 収集される: INSERT INTO sales PARTITION (sales_q4_2000) SELECT …

50


バルク・ロードのオンライン統計収集実行例

• SQL文の実行

• 統計の確認

51

CREATE TABLE TEST AS SELECT * FROM SH.CUSTOMERS;

SELECT NUM_ROWS,BLOCKS FROM USER_TAB_STATISTICS WHERE TABLE_NAME='TEST';

NUM_ROWS BLOCKS

------------ ----------

55500 1550

SELECT COLUMN_NAME, NUM_DISTINCT, NOTES FROM USER_TAB_COL_STATISTICS;

COLUMN_NAME NUM_DISTINCT NOTES

----------- -------------- -------------------

CUST_ID 55500 STATS_ON_LOAD

DBA_TAB_COL_STATISTICS

ビューのNOTES列にSTATS_ON_LOADの値が入る

自動的に統計を収集


オプティマイザ統計の同時収集

• 複数のオブジェクトに対し統計情報を並行収集 –表、パーティション、サブパーティション、索引

• マルチCPU環境では総収集時間の短縮が可能

52

統計の収集(database/schema/dictionary)

グローバル統計収集

Table 1

Partition 1

Partition 2

グローバル統計収集

Table 2

Table 3

ジョブ 1

ジョブ

3.1

ジョブ 2

ジョブ

3.2 ジョブ

3.3

ジョブ 3 (コーディネーター)

(グローバル統計収集)

各オブジェクトに対して統計収集のジョブを作成


オプティマイザ統計の同時収集

• Oracle 11g R2 (11.2.0.2) から統計情報の同時収集を導入

• Oracle 12cでは以下の場合も並行収集が可能 –複数のパーティション表

–自動統計収集ジョブ

• データベースのジョブ機能を使用して統計を収集 – Oracle Scheduler および Advanced Queuing を使用してジョブの作成、管理を実施

–サイズが非常に小さい、あるいは空のパーティションは別の小さいオブジェクトと一つのジョブにまとめられる

• ジョブの数の制御にはパラメータ JOB_QUEUE_PRCESSESを使用可能

53


オプティマイザ統計の同時収集の設定

• 設定 – DBMS_STATS.SET_GLOBAL_PREFファンクションを用いて、

CONCURRENTプリファレンスを設定 (デフォルト無効: OFF)

• MANUAL: 手動統計収集時に同時収集

• AUTOMATIC : 自動統計収集時に同時収集

• ALL: 手動、自動統計収集時に同時収集

• OFF: 同時収集しない (デフォルト)

• 注意 –同時統計収集の実行によるシステム・リソースの消費に注意

• リソース・マネージャを使用したリソース管理

54

DBMS_STATS.SET_GLOBAL_PREFS('CONCURRENT',‘ALL’);


オプティマイザ同時統計収集の監視

• DBA_OPTSTAT_OPERATION_TASKS

–ステータス、開始時間、終了時間の監視が可能

55

TARGET TARGET_TYPE JOB_NAME STATUS TO_CHHAR(START_T

----------------- ------------------------- -------------- ------------ -----------------

OPT.PT1 TABLE (COORDINATOR JOB) ST$SD88_1 IN PROGRESS 03:08:06

OPT.PT2 TABLE ST$SD88_2_B2 IN PROGRESS 03:08:09

OPT.PT2.P3 TABLE PARTITION ST$SD88_2_B2 IN PROGRESS 03:08:43

OPT.PT1.P4 TABLE PARTITION ST$T128_2_B2 IN PROGRESS 03:08:07

OPT.PT1.P2 TABLE PARTITION ST$T128_1_B3 IN PROGRESS 03:08:45

…


グローバル一時表のセッション固有統計グローバル一時表の概要 • グローバル一時表には二つの種類がある

–セッション固有一時表

–トランザクション固有一時表

• セッション固有一時表はセッション中のみデータを保持する表 –一時表内のデータを参照、変更できるのはそのセッション自身のデータのみ

–セッションの終了により、表内のデータを失う

• トランザクション固有一時表はトランザクション中のみデータを保持する表 –トランザクションの終了により、表内のデータを失う

56


セッション固有一時表の統計収集

• これまでは全てのセッションで一つの統計情報を共有して使用

• Oracle 12cではそれぞれのセッションで異なる統計情報を保持(デフォルト) –そのセッションで使用するデータに合わせた統計を収集可能

57

11g

セッション固有一時表

セッション 1 セッション 2

統計情報 1 統計情報 1 データ 1 データ 2

同一の統計情報を使用

12c

セッション固有一時表

セッション 1 セッション 2

統計情報 1 統計情報 2 データ 1 データ 2

セッション毎の統計情報を使用


セッション固有一時表の統計収集の設定

• デフォルトはセッション固有の統計を収集 –一つの統計情報を全てのセッションで使用する設定も可能

• 設定 –表プリファレンスのGLOBAL_TEMP_TABLE_STATSで設定

58

DBMS_STATS.SET_GLOBAL_PREFS('GLOBAL_TEMP_TABLE_STATS', 'SESSION');

設定値

GLOBAL_TEMP_TABLE_STATSの値有効化の設定

SESSION セッション毎の統計情報を保持(デフォルト)

SHARED セッション間で統計情報を共有


セッション固有一時表の統計収集

• 収集した統計は DBA_TAB_STATISTICSなどのディクショナリから確認可能 –収集した統計の種類を表示するSCOPE列を導入

• セッション固有統計のみ収集した状態 (デフォルト)

59

SELECT TABLE_NAME, NUM_ROWS, SCOPE FROM USER_TAB_STATISTICS WHERE TABLE_NAME = ’TEST’;

TABLE_NAME NUM_ROWS BLOCKS SCOPE

--------------- ---------- ---------- ---------------------

TEST SHARED

TEST 5 1 SESSION


セッション固有一時表の統計収集実行例セッション毎に異なる統計を使用 • 異なるデータを持つセッション固有一時表での実行計画

– セッション1に 5行、セッション2に 2行をINSERTし、統計収集を実施

– それぞれのセッションでSQL実行計画を確認

60

------------------------------------------

| Id | Operation | Name | Rows |

------------------------------------------

| 0 | SELECT STATEMENT | | 5 |

| 1 | TABLE ACCESS FULL| TEST | 5 |

------------------------------------------

Note

-----

- Global temporary table session private

statistics used

------------------------------------------

| Id | Operation | Name | Rows |

------------------------------------------

| 0 | SELECT STATEMENT | | 2 |

| 1 | TABLE ACCESS FULL| TEST | 2 |

------------------------------------------

Note

-----

- Global temporary table session private

statistics used

セッション1 セッション2

Noteセクションに出力


トランザクション固有一時表の統計収集

• これまでは統計収集操作によりデータを失う動作 – DBMS_STATS.GATHER_TABLE_STATSがCOMMIT処理を発行

– COMMIT処理により表内のデータを失った状態で統計を収集

• Oracle 12cではDBMS_STATS.GATHER_TABLE_STATSを実行してもデータを失わずに統計を収集可能(デフォルト)

• 設定 – DBMS_STATS.SET_GLOBAL_PREFSファンクションから設定

• セッション固有一時表と同じ設定

61

DBMS_STATS.SET_TABLE_PREFS ('GLOBAL_TEMP_TABLE_STATS','SESSION');


トランザクション固有一時表の統計収集実行例

• トランザクション固有一時表の統計収集 –トランザクション固有一時表にデータをINSERTし、統計収集を実施

–統計情報の確認

62

TABLE_NAME NUM_ROWS SCOPE

---------- ---------- -------

TEST 5 SESSION

TABLE_NAME NUM_ROWS

---------- ----------

TEST 0

Oracle 12c のトランザクション固有一時表

参考：Oracle 11g のトランザクション固有一時表

格納したデータを用いた統計が収集される


トランザクション固有一時表の統計収集

• トランザクション固有一時表に対してコミットを行わないよう拡張されたプロシージャ

63

• GATHER_TABLE_STATS

• DELETE_TABLE_STATS

• DELETE_COLUMN_STATS

• DELETE_INDEX_STATS

• SET_TABLE_STATS

• SET_COLUMN_STATS

• SET_INDEX_STATS

• GET_TABLE_STATS

• GET_COLUMN_STATS

• GET_INDEX_STATS


ヒストグラム

• ヒストグラムは列データの分布状況を表し、データの偏りをオプティマイザに伝える –オプティマイザはヒストグラムを使用して最適なSQL実行計画を選択

–ヒストグラムが無い場合、オプティマイザはデータが均等に分布すると考えるため、適切な実行計画を選択できないことがある

64

C1 件数

A 1000件

B 1000件

C 1件

C1列のデータ分布


個別値はA、B、C の3つ

データC は全体の 1/3 を占めていると推測

→ 全表スキャンを選択

ヒストグラムが無い場合

SELECT .. FROM T WHERE C1=‘C’

SQL文


ヒストグラムの種類

• Oracle 11g のヒストグラム – 2種類のヒストグラムを使用

• 頻度ヒストグラム (Frequency Histogram)

• 高さ調整済ヒストグラム (Height-Balanced Histogram)

– バケットの数の最大値は254

• Oracle 12cのヒストグラム

–より正確な見積もりを得るために新しいヒストグラム2つを導入 • 上位頻度ヒストグラム(Top Frequency

Histograms)

• ハイブリッド・ヒストグラム(Hybrid Histograms)

–バケットの数の最大値を2048に拡張

65


頻度ヒストグラム(Oracle 11g)

• 個別値の数がヒストグラム収集時に指定したバケット数以下の場合に生成 –バケットは1から254まで指定可能

• 各バケットに同一のデータを格納

• データの個数はDBA_TAB_HISTOGRAMSビューの ENDPOINT_NUMBER(エンドポイント番号)列の差分から把握

66

エンドポイント値: 1

エンドポイント番号: 3

データをバケットに配分したイメージ

バケット1 バケット2 バケット3

1

1 1 2 2

3 3

3 3

3 3

3





エンドポイント番号の差分から個数の把握が可能 e.g. 値3の個数は 12-5=7個


高さ調整済ヒストグラム(Oracle 11g)

• 個別値の数がバケット数より多い場合に作成

• 頻度ヒストグラムほど正確ではないがデータ数の偏りを把握可能 –各バケットにほぼ同数にデータを分配

–連続するバケットのエンドポイント値が同じ場合、最後のバケットに圧縮

–データ数の偏りはエンドポイント番号列の差分から把握

67





7

9 9 10 11

8 9 10 11

12 12

11





エンドポイント番号の差分からデータ数の偏りを把握可能

バケット7

12

12

12 12 12

12 11 11

同じエンドポイント値のためバケット7に圧縮


上位頻度ヒストグラム

• データ件数の大部分を占めるデータに対して正確な見積もりを計算するヒストグラム

– 上位 n 個の個別値のデータ個数を把握 (n=バケット数)

– 上位 n 個の個別値がデータの大部分を占める場合にこのヒストグラムを作成

• データの個数が少なく、統計的に有意でないデータを無視することで、データの大部分を占めるデータに対しての正確な見積もりを計算

68


4個のバケット数でヒストグラムを作成

1 1

1

4 4

2 3

5 5

1

4 4

4

5 5

3

データ

•各バケットに個別値が分配される

•個別値の数はエンドポイント番号列から把握が可能

•C1=2の値は非ポピュラー値であり、統計上有意でないため無視される

バケット1

バケット3

バケット2

バケット4

1

1

1

4 4

3 3

5 5

1

4 4

4

5 5


上位頻度ヒストグラムの作成条件

• 統計収集のサンプリング率がデフォルト設定(AUTO_SAMPLE_SIZE)

• 指定したバケット数より多い個別値を持つ

• 上位 n 個のデータが占める割合(%)がしきい値 p 以上になる(n=バケット数) –しきい値(p)はバケットの数をnとした場合、 p=(1-(1/n))*100

69

例. バケットの数が 254 (デフォルト) の場合 p = (1-(1/254))*100 → 99.6 % 上位 254 個の個別値の占める割合が上記 p の値以上の場合は、上位頻度ヒストグラムを作成


上位頻度ヒストグラム作成例

• sh.countries表のcountry_subregion_id列 –個別値の数 8個

–バケット数 6 で統計を収集 • しきい値 p = (1-(1/6))*100 = 83.3%

• 上位 6 個の占める割合 91.3%

70

COLUMN_NAME NUM_BUCKETS HISTOGRAM

----------- ----------- --------------

COUNTRY_SUB 6 TOP-FREQUENCY

REGION_ID

USER_TAB_COL_STATISTICSビュー

ENDPOINT_NUMBER ENDPOINT_VALUE

--------------- --------------

1 52792

6 52793

8 52794

10 52797

12 52798

21 52799

USER_HISTOGRAMSビュー作成されたヒストグラム

上位頻度ヒストグラムを作成

COUNTRY_SUBREGION_ID COUNT(*)

-------------------- ----------

52792 1

52793 5

52794 2

52795 1

52796 1

52797 2

52798 2

52799 9

COUNTRY_SUBREGION_ID列の個別値の数


ハイブリッド・ヒストグラム

• 上位頻度ヒストグラムの条件から外れる場合に作成

• 高さ調整済ヒストグラムと頻度ヒストグラムの両方の特徴を組み合わせる

– 高さ調整済みヒストグラム同様に各バケットに値を割り振る

– その後、同じ値が複数のバケットに入らないように値を移動

– 各バケットのエンドポイント値の個数をエンドポイント繰返しカウント列(ENDOPOINT_REPEAT_COUNT) に記録

• オプティマイザはエンドポイント繰返しカウントを使用してエンドポイント値の個数を把握

71



8 8

9

9

9 11

10 11

11

11 11

11

11

12 13 エンドポイント値: 9

エンドポイント繰返しカウント: 3






ハイブリッド・ヒストグラム高さ調整済ヒストグラムとの比較

• 高さ調整済ヒストグラムは、歪みがあってもポピュラー値と認識されない場合がある

– (例) 二つのバケットの大部分を一つのデータが占めるが、エンドポイント値は一つ

• ハイブリッド・ヒストグラムではこのような値に対してよりよい見積もりが可能

72

エンドポイント値

9

高さ調整済ヒストグラム




値11は複数のバケットのエンドポイント値ではないため、非ポピュラー値とみなされる

8 8

9

9

9

11 10 11

11 11

11 11 11

12 13

8 8

9

9

9

11

10 11

11

11 11

11

11

12 13


11


13 エンドポイント値: 9






エンドポイント値 11 の個数がわかる


ハイブリッド・ヒストグラム作成例

• sh.products表のprod_subcategory_id列

• 個別値の数 22個

• バケット数 10で統計を収集

– しきい値 p = (1-(1/10))*100 = 90%

– 上位10個の占める割合 75%

73

COLUMN_NAME NUM_BUCKETS HISTOGRAM

----------- ----------- --------------

PROD_SUBCAT 10 HYBRID

EGORY_ID

USER_TAB_COL_STATISTICSビュー

ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_REPEAT_COUNT

--------------- -------------- ---------------------

1 2011 1

13 2014 8

26 2032 6

36 2036 4

… … …

72 2056 5

USER_HISTOGRAMSビュー作成されたヒストグラム

ハイブリッド・ヒストグラムを作成

PROD_SUBCATEGORY_ID COUNT(*)

------------------- ----------

2011 1

2012 2

2013 2

2014 8

… …

2056 5

COUNTRY_SUBREGION_ID列の個別値の数


作成されるヒストグラム

74

頻度ヒストグラム

上位頻度ヒストグラム


個別値の数が指定したバケット数以下

上位頻度ヒストグラム作成の条件を満たす

YES NO

YES NO 頻度ヒストグラム

高さ調整済ヒストグラム

個別値の数が指定したバケット数以下

YES NO

12c 11g

※統計収集時のサンプリング率 (estimate_percent) をデフォルト値(AUTO_SAMPLE_SIZE)以外に設定(サンプリング率を指定)した場合は、高さ調整済みヒストグラムあるいは頻度ヒストグラムを作成する


Program Agenda





1

2

3

4

75


SQL 計画管理(SQL Plan Management)（SPM）概要

• SQL実行計画の変更による性能低下を防止する

– 使用するSQL実行計画は計画ベースラインに登録

– 新規のSQL実行計画は計画履歴に追加

• 検証を受け、承認されたSQL実行計画は計画ベースラインに登録され使用できる状態になる

76

SYSAUX SQL 管理ベース

Statement Log

計画履歴

計画ベースライン

GB

HJ

HJ

GB

NL

NL

GB

HJ

HJ

未承認のSQL実行計画は使用されない

承認済みのSQL

実行計画を使用


Oracle 11gのSQL計画ベースラインの展開(evolve)

• 新しいSQL実行計画が検出された場合、承認済みSQL実行計画となる前に検証が必要

– 新しく追加されたSQL実行計画のパフォーマンスを評価

– 検証されたSQL実行計画を承認するかを管理者が決定

• 検証の実行

– DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEファンクション

– SQL チューニングアドバイザ

77

SYSAUX SQL 管理ベース

Statement Log

計画履歴

計画ベースライン

GB

HJ

HJ

GB

NL

NL

パフォーマンスの比較検証

未承認の実行計画の方がよいパフォーマンスの場合、承認され、計画ベースラインに登録


SQL 計画管理 (SPM) の機能強化適応SQL計画管理(Adaptive SQL Plan Management) • 自動メンテナンス・ウィンドウで動作するSQL実行計画展開タスクを提供

– SPM展開アドバイザ (Evolve Advisor) タスク(SYS_AUTO_SPM_EVOLVE_TASK)

–未承認のSQL実行計画をランク付けして検証プロセスを実行 • 新しく見つかったSQL実行計画が最もランクが高い

–既存のSQL実行計画より性能がよければ承認(デフォルト) • 承認しない設定も可能

78

DBMS_SPM.SET_EVOLVE_TASK_PARAMETER('SYS_AUTO_SPM_EVOLVE_TASK‘,'ACCEPT_PLANS', 'TRUE');

e.g. よい性能の結果なら実行計画を承認


手動によるSQL実行計画展開 SQL実行計画展開タスクのファンクションを提供（推奨は自動実行） • DBMS_SPMパッケージに手動実行可能なファンクションを提供

• 展開タスクの手動実行や自動実行のスケジュールを作成することが可能 – e.g. 週次で展開タスクを実行し、レポートを確認してからSQL実行計画を承認する

79

展開タスク管理のファンクション抜粋

ファンクション名内容

CREATE_EVOLVE_TASK 展開タスクの作成、SQLハンドルやプラン名を指定可能

EXECUTE_EVOLVE_TASK 展開タスクの実行

REPORT_EVOLVE_TASK 展開タスクのレポートを表示

IMPLEMENT_EVOLVE_TASK レポートの推奨するSQL実行計画を承認


SQL 計画管理 (SPM) の機能強化 DBMS_XPLAN.DISPLAY_PLAN_BASELINE表示の変更 • これまではSQL文をコンパイルして作成したSQL実行計画を表示

• Oracle12c ではSQL管理ベースに格納されたSQL実行計画の行を取り出して表示

– 新しい実行計画が計画履歴に追加されたときに、SQL実行計画の行もSQL管理ベースに格納

• SQL実行計画が再作成できない場合の分析に有用(必要な索引や表がない場合など)

80

display_plan_baseline実行 SQL実行計画行の取得

SQL 管理ベース

GB

HJ

HJ

ベースライン作成時にSQL実行計画行を格納


DBMS_XPLAN.DISPLAY_PLAN_BASELINE表示の変更 (計画ベースラインからの表示)

81

-- DBMS_XPLAN.DISPLAY_PLAN_BASELINE表示 select * from table(dbms_xplan.display_sql_plan_baseline (plan_name=>'SQL_PLAN_91j9mbgt3qabd447b331a')); PLAN_TABLE_OUTPUT ------------------------------------------------ SQL handle: SQL_90c5335bf23b296d SQL text: select employee_id, last_name from hr.emp where employee_id = 101 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Plan name: SQL_PLAN_91j9mbgt3qabd447b331a Plan id: 1148924698 Enabled: YES Fixed: NO Accepted: YES Origin: MANUAL-LOAD Plan rows: From dictionary -------------------------------------------------------------------------------- Plan hash value: 4024650034 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 1 (100)| | | 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 12 | 1 (0)| 00:00:01 | |* 2 | INDEX UNIQUE SCAN | EMP_PK | 1 | | 0 (0)| | --------------------------------------------------------------------------------------

-- 検証作業 -- Primary Key 制約索引として EMP_PK索引を作成 alter table hr.emp add constraint emp_pk primary key (employee_id); -- EMP_PK 索引を使った実行計画が生成される select employee_id, last_name from hr.emp where employee_id = 101; -- SQL管理ベースに格納 -- Primary Key 制約を削除 alter table hr.emp drop primary key;


Program Agenda





1

2

3

4

82


パラレル実行の強化

• パラレル文のキューイングの強化

• パラレル分散方法の適応

• パラレル度の再最適化

83


パラレル文のキューイング Oracle 11g R2のキューイング • 大量のパラレル実行が行われている場合に、パラレル実行のダウングレードを防止

• リソース使用状況によるパラレル度(DOP)のダウングレードを回避するために実装

– 設定方法：PARALLEL_DEGREE_POLICYをAUTOに設定

84

SQL文の実行 SQL文が解析され、Oracleが自動的にDOPを割り当て

16 32 64 128

FIFO キュー

十分なスレーブプロセスが確保できるのならば、即時実行する

要求されたスレーブプロセス数が獲得されたら、先頭のSQL文からデキューされ、実行される

8 128

十分なスレーブプロセスが確保できない場合、キューに入る


パラレル文のキューイング Oracle 11g R2のキューイング

• キューイングは一定のしきい値を超える場合に行われる –初期化パラメータPARALLEL_SERVERS_TARGETの値がしきい値

–使用されているパラレル実行プロセスがこの値を超える処理から、キューイングが行われる

85

32

80

4 CPU_COUNT

PARALLEL_SERVERS_TARGET

PARALLEL_MAX_SERVERS

4CPUのマシンの場合

利用できるスレーブプロセス数の上限

クエリーがキューに入るまでに利用できるスレーブ数


パラレル文のキューイングの強化 Oracle 12c クリティカルなパラレル文を優先的に実行

• Oracle12c ではクリティカルなパラレル文の優先実行が可能

– キューをバイパスして即時実行

– parallel_servers_targetを超えて実行可能

• 設定

– 特定のコンシューマー・グループをクリティカルとマーク

– 計画ディレクティブで設定

• 確認

– DBA_RSRC_PLAN_DIRECTIVES ビューのPARALLEL_STMT_CRITICAL列にBYPASS_QUEUEと表示

86

PARALLEL_STMT_CRITICAL => ‘BYPASS_QUEUE’


パラレル文のキューイングの強化キューイング設定例)コンシューマーグループの作成

87

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DBMS_RESOURCE_MANAGER.CREATE_PLAN('PQ_TEST_PLAN');

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('PQ_CRITICAL_GROUP');

-- クリティカルなSQL実行用のSQL 計画ディレクティブを作成

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'PQ_TEST_PLAN','PQ_CRITICAL_GROUP', parallel_stmt_critical => 'BYPASS_QUEUE');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'PQ_TEST_PLAN', 'OTHER_GROUPS', 'no degree limit');

DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

END;

/


パラレル文のキューイングの強化キューイング設定例)コンシューマーグループの設定確認

88

SELECT PLAN, GROUP_OR_SUBPLAN, PARALLEL_STMT_CRITICAL FROM

DBA_RSRC_PLAN_DIRECTIVES WHERE PARALLEL_STMT_CRITICAL = 'BYPASS_QUEUE';

PLAN GROUP_OR_SUBPLAN PARALLEL_STMT_CRITICAL

--------------- -------------------- ------------------------------------

PQ_TEST_PLAN PQ_CRITICAL_GROUP BYPASS_QUEUE


パラレル分散方法の適応実行時に収集した統計をベースに分散方法を決定 • パラレル実行ではソート、集計、結合などの操作のためにパラレル実行プロセス間でデータを再分配する

• Oracleデータベースには複数のパラレル分散方法が存在 – e.g. ハッシュ方法、ブロードキャスト方法など

• Oracle 12c ではハイブリッド・ハッシュ分散方法を導入 –実行時に収集した統計から最終的な分散方法を決定(適応計画の1つ)

• 実際の行数がしきい値以上の場合はハッシュを使用

• しきい値より少ない場合はブロードキャストに切り替わる

–しきい値はパラレル度の2倍で定義

89


パラレル度の再最適化パフォーマンス統計をフィードバックしてパラレル度を改善 • SQL実行時に収集した統計を使用して、次回実行時の自動パラレル度

(AutoDOP) をより適切に決定 –自動再最適化の1つ

• 動作 –初回実行時にオプティマイザがパラレル度を決定

–実行の最後に以下を比較 • オプティマイザが選択したパラレル度

• 実行時に収集したパフォーマンス統計(例えばCPU Time)に基づいて計算したパラレル度

–両者が大きく異なる場合はその文を再解析の対象とし、統計を記録

–次回のSQL実行時に、記録した統計を使用してより適切なパラレル度を決定

90


パラレル実行の制御

• 初期化パラメーターPARALLEL_DEGREE_POLICY で制御 –デフォルトはすべて無効 (設定値: MANUAL)

– ALTER SESSION, ALTER SYSTEMで設定の変更が可能

91

PARALLEL_DEGREE_POLICYの設定値

MANUAL LIMITED AUTO ADAPTIVE

自動パラレル度設定 × ○ ○ ○

In-Memory Parallel実行 × × ○ ○

Parallel Statementキューイング × × ○ ○

Performance Feedback × × × ○

自動パラレル度 (Auto DOP)設定の強化ユーザが自動パラレル度の影響力を制御可能なパラメータを導入

初期化パラメータ PARALLEL_DEGREE_LEVEL 自動パラレル度で計算されたパラレル度にユーザが強弱の割合(%)を指定可能


まとめ

• Oracle12c では、オプティマイザの自己学習機能が強化 – SQL実行時に統計情報を収集し、より最適な実行計画を選択(適応計画)

–実行時に収集した統計情報を次以降の実行時に反映(適応計画) • 統計情報収集（動的統計)

• 統計の補足(SQL計画ディレクティブ)

• 統計情報のフィードバック(自動再最適化)

• より多くの環境において最適な実行計画が選択され、適切な性能を維持

92


オプティマイザ関連情報

• ホワイトペーパー – What to Expect From The Optimizer in Database 12c

– SQL Plan Management with Oracle Database 12c

– Understanding Optimizer Statistics with Oracle Database 12c

– Best Practices for Gathering Optimizer Statistics with Oracle Database 12c

• Optimizer Blog

– http://blogs.oracle.com/optimizer

• Oracle.com

– http://www.oracle.com/technetwork/database/focus-areas/bi-datawarehousing/dbbi-tech-info-optmztn-092214.html

93

http://blogs.oracle.com/optimizer

http://www.oracle.com/technetwork/database/focus-areas/bi-datawarehousing/dbbi-tech-info-optmztn-092214.html














オプティマイザの初期化パラメータ（一部）初期化パラメータ説明 CURSOR_SHARING SQL文のリテラル値をバインド変数に変換する。オプティマイザは、実際のリテラル値でなくバインド変数の有無に基づいて実行計画を生成し、

FORCEを設定すると、既存のカーソルの共有時やカーソル・プランが最適ではない場合に新しいカーソルを作成が可能。EXACTに設定すると、同一のテキストを含む文のみで同じカーソルを共有する。

DB_FILE_MULTIBLOCK_READ_COUNT 全表スキャンや高速全索引スキャン時に単一I/Oで読み取られるブロックの個数を指定する。このパラメータの値を使用して、全表スキャンと高速全索引スキャンのコストを計算。値が大きいほど全表スキャンのコストは低くなり、索引スキャンより全表スキャンを選択する。

OPTIMIZER_ADAPTIVE_REPORTING_ONLY

自動再最適化と適応計画のレポート作成モードを制御。デフォルトは、レポート作成モードオフ(false)のため、適応最適化が有効。trueに設定した場合は、レポート作成のみのモード。この場合は、データベースで適応最適化に必要な情報が収集されるものの、計画変更は発生しない。

OPTIMIZER_MODE データベース・インスタンスの起動時にオプティマイザ・モードを設定。ALL_ROWS、FIRST_ROWS_n、FIRST_ROWSの値が使用可能。

OPTIMIZER_INDEX_CACHING ネステッド・ループと索引プローブのコスト分析を制御。値0-100の範囲はバッファ・キャッシュ内の索引ブロックの割合を示し、値に応じてネステッド・ループおよびINリスト・イテレータの索引キャッシュに関するオプティマイザの前提条件が変更される。この値が100の場合、索引ブロックの100%がキャッシュされている可能性があり、索引キャッシュを優先して実行計画に変更される可能性があるためパラメータの設定時には注意する。

OPTIMIZER_INDEX_COST_ADJ 索引プローブのコストを調整する。値の範囲は、1から10000です。デフォルト値100の場合、オプティマイザは、標準のコスト・モデルに基づいて索引をアクセス・パスとして評価。値10は、索引アクセス・パスの標準コストの1/10コストであることを意味する。

OPTIMIZER_INMEMORY_AWARE インメモリー、表拡張、ブルーム・フィルタのコスト・モデルを含むすべてのインメモリー・オプティマイザ機能を有効(TRUE)または無効(FALSE)する。パラメータをFALSEに設定すると、オプティマイザはSQL文の最適化中に表のインメモリー・プロパティを無視する。

OPTIMIZER_USE_INVISIBLE_INDEXES 非表示の索引の使用を有効化または無効化する。

RESULT_CACHE_MODE 結果キャッシュの対象を制御する。MANUAL(デフォルト)の場合、RESULT_CACHEヒントを使用して、結果がキャッシュされるようにする必要がある。FORCEに設定するとすべての結果がキャッシュに格納される。RESULT_CACHE_MODEをFORCEにする場合、正当性やパフォーマンスを考慮する。

RESULT_CACHE_MAX_SIZE 結果キャッシュに割り当てられているメモリーを変更する。指定された値を超えない範囲で32KBの最大倍数まで丸められる。丸め値が0の場合は結果キャッシュが無効化される。

RESULT_CACHE_MAX_RESULT 各結果で使用可能な結果キャッシュのサイズを比率で指定する。デフォルト値は5%で、1から100の任意のパーセント値を指定可能。

RESULT_CACHE_REMOTE_EXPIRATION リモート・データベース・オブジェクトに依存する結果の有効時間(分単位)を指定する。デフォルトは0でリモート・オブジェクトを使用して結果がキャッシュされない。0以外の値にすると、結果で参照されるリモート表が変更された場合などに、失効した回答が生成される可能性がある

STAR_TRANSFORMATION_ENABLED オプティマイザはスター・クエリーのスター型変換のコストを計算する(trueの場合)。

94

how to use the powerpoint template...2016/04/13 · 初期化パラメータ 説明

Documents

how to use the powerpoint template...2016/04/13 · 初期化パラメータ説明