sqlチューニング&メモリチューニングに 必要な考 …...2014/03/12 ·...
TRANSCRIPT
SQLチューニング&メモリチューニングに必要な考え方と最新テクニック
THIRD PARTY COMPANY LOGO
日本オラクル株式会社 テクノロジー製品事業統括本部 支社ソリューション本部 西日本グループ 2014年03月12日
第121回 夜な夜な! なにわオラクル塾
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 2
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
目的とゴール
3
• SQLチューニングにおける様々な「戦術」をつかむ
• ORA-4031撲滅
• 共有プールの性質の理解
• メモリ設計・監視のポイント
目的
SQLチューニングで有効となるテクニックとメモリ障害の予防を知る
ゴール
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
本セミナーの内容に関する注意
• 本資料の内容
• 製品仕様に関する正式な情報ではなく、プロジェクトで調査を行い把握した内容を記載
• プロジェクトで得られた経験を基にした、具体的な一次サイジングの指針および値
• 実際には、必要領域は処理内容や処理タイミングに依存するため、
テストによりサイズを検討ください
• 前提環境
• Oracle Database 11g Release2
• 自動SGA管理
4
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
Program Agenda
SQLと云う言語の特徴
「予測」と「実測」の乖離を補正せよ!
• Oracle Databaseの機能を活用した最新テクニック
共有プールの基本的理解
設計~テスト~運用フェーズでの検討事項
• 管理方式選定
• 一次サイジング(自動SGA前提)
• 監視・チューニング(自動SGA前提)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLと云う言語の特徴について
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLという言語の特徴(1)
• SQLと云う言語は、過去を振り返ってみても
最も成功した言語/標準規格の一つ
• 何故成功したのか?
• それはどうやって(How)データを抽出するかを書かずに、
何を(What)抽出するかという“条件”のみを記述する仕様
• 多くの言語では、繰り返し(for~)や条件分岐(if~)などの
アルゴリズムを記述する必要がある
• アルゴリズムを書かない(※書く必要が無い)のが、
SQLと云う言語の最大の特徴
7
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLという言語の特徴(2)
• どうやって(How)データを抽出するか、即ちアルゴリズムの
決定・制御は、RDBMS のオプティマイザで行われる
• オプティマイザが決定したアルゴリズム=実行計画
• オプティマイザはSQLテキストや統計情報などを基に、
適切な実行計画を予測して組み立てる
8
プログラム
“条件”のみを記述
Op
timiz
er SQL データ
アルゴリズムを決定/制御
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
アルゴリズムを書かないことによるメリット
• アルゴリズムを書かないことによる最大のメリット
言語の習得が「簡単」
• エンジニアではない現場のお客様でも、
SQLなら書くことは可能
• 習得が簡単ということは、生産性の高さ=コスト削減にも繋がっている
• エンジニアの確保が容易
• 一般的にアプリケーション作成の工数も少なく済む
9
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
アルゴリズムを書かないことによるデメリット
• アルゴリズムを書かないことによる最大のデメリット
「性能」に関する問題が出やすい
• 適切ではないアルゴリズム(実行計画)による、著しい性能劣化
• アルゴリズム(実行計画)変動に伴う、性能変動(劣化)
• SQLを使うユーザ(開発者)は、性能が悪くなり易い良くない実行計画と
なるSQLも書くことができる
• 多くのユーザは必要なデータが抽出できれば良く、実行計画など気にしない
• 一部ユーザ が無意識に強烈な実行計画のSQLをリリースすることもある
10
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
参考:某チューニング案件の超巨大SQL実行計画
• SQLテキストで6700行以上、40表以上を結合したSELECT文の実行計画
• 実行計画のステップ数換算で 、実に500ステップ以上の超巨大SQL
11
…(中略)…
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
振り返ってもう一度このスライド
• どうやって(How)データを抽出するか、即ちアルゴリズムの
決定・制御は、RDBMS のオプティマイザで行われる
• オプティマイザが決定したアルゴリズム=実行計画
• オプティマイザはSQLテキストや統計情報などを基に、
適切な実行計画を予測して組み立てる
12
プログラム
“条件”のみを記述
Op
timiz
er SQL データ
アルゴリズムを決定/制御
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
本セクションのキーワードの一つ:「予測」
• どうやって(How)データを抽出するか、即ちアルゴリズムの
決定・制御は、RDBMS のオプティマイザで行われる
• オプティマイザが決定したアルゴリズム=実行計画
• オプティマイザはSQLテキストや統計情報などを基に、
適切な実行計画を予測して組み立てる
13
プログラム
“条件”のみを記述
Op
timiz
er SQL データ
アルゴリズムを決定/制御
ココ!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLのアルゴリズムは「予測」で組み立てられる
• SQL の アルゴリズム≒実行計画 は、オプティマイザが
最適と考えられるものを「予測」して組み立てる
• そして「予測」である以上、必ずハズレのケースがある
• ハズレの実行計画の場合、性能問題として顕在化!
• SQLの特徴に由来する、全てのRDBMSに共通した本質的な困難
• 各ベンダやオープンソースのRDBMSは、このSQLの本質的な困難に
立ち向かうべく、日々凌ぎを削っている(もちろんOracleも!)
• まずこのハズレの実行計画の存在を意識/認識しておくのが、
SQLチューニングの出発点
14
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」と「個別最適」の使い分け
• SQLチューニングの手法は、全体最適にマッチする手法と、
個別最適に適した手法の2つに大別
• 全体最適にマッチする手法の例
• 適切なSQL(SQLコーディング・ガイド、コード・インスペクション、等)
• 適切な統計(常時最新化されたフレッシュな統計、最大件数想定の固定値、等)
• 適切な索引(一意キー索引、追加索引、等)
• 実行計画最適化機能(BindPeek, Dynamic Sampling, Cardinality Feedback等)
• 個別最適にマッチする手法の例
• ヒント
• SQL計画管理(SPM/11gR1以降)、アウトライン(10gR2以前)
• SQLプロファイル
15
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」と「個別最適」の適用イメージ(1)
16
SQLの重要度
処理 時間 短
長
低 高
全体最適
個別最適
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」と「個別最適」の適用イメージ(2)
17
SQLの重要度
処理 時間 短
長
低 高
全体最適
個別最適 ・適切な統計
・適切なSQL
・実行計画 最適化機能 (Bind Peek,
Dynamic Sampling,
Cardinality Feedback, 等)
・適切な索引 ・ヒストグラム
・拡張統計
・ヒント
・SPM(or アウトライン)
・SQLプロファイル
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」と「個別最適」の適用イメージ(3)
18
SQLの重要度
処理 時間 短
長
低 高
全体最適
個別最適 ・適切な統計
・適切なSQL
・実行計画 最適化機能 (Bind Peek,
Dynamic Sampling,
Cardinality Feedback, 等)
・適切な索引 ・ヒストグラム
・拡張統計
・ヒント
・SPM(or アウトライン)
・SQLプロファイル
序
終
まず初めは全体最適な手法で、実行 計画全体の予測精度を上げる!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」と「個別最適」の適用イメージ(4)
19
SQLの重要度
処理 時間 短
長
低 高
全体最適
個別最適
予測精度向上でハズレの実行計画を 引くリスクを低減し、個別最適の範囲を
極小化する!と云う設計思想
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「全体最適」のち「個別最適」の考え方
• まずは「全体最適」の設計思想で、実行計画全体の
予測精度を向上させることが必要
• 「個別最適」の必要性は無くなるわけではない
• 何故か?
• ハズレの実行計画の存在が理由
• SQLの仕組み上、ハズレの実行計画は不可避であると云う認識が必要
• ハズレの実行計画は有るものとして、「個別最適」でチューニングする
• これ以降「個別最適」のチューニングで有効なテクニックを紹介
20
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
「予測」と「実測」の乖離を補正せよ! Oracle Databaseの機能を活用した
最新テクニック
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLチューニングの流れ(1)
22
遅いSQLの特定(sql_id特定)
実行計画のボトルネック特定
目標達成!!
Tuning案① Tuning案② Tuning案③ Tuning案④
KROWN#141864
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLチューニングの流れ(2)
23
遅いSQLの特定(sql_id特定)
実行計画のボトルネック特定
目標達成!!
Tuning案① Tuning案② Tuning案③ Tuning案④
Oracle Database の 機能を利用した、ボトルネック特定方法を紹介
• DBMS_XPLAN.DISPLAY_CURSOR で実行統計を出力する方法 (参考KROWN#141531)
• DBMS_SQLTUNE.REPORT_SQL_MONITOR による リアルタイム監視SQLのレポーティング
KROWN#141531
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLチューニングの流れ(3)
24
遅いSQLの特定(sql_id特定)
実行計画のボトルネック特定
目標達成!!
Tuning案① Tuning案② Tuning案③ Tuning案④
複数のチューニング案を 疑似ワークショップ形式
で紹介
• 複数のチューニング案を覚えて、引き出しを増やす
• チューニングの引き出しを増やすことが、上級者への近道!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN と
DBMS_SQLTUNE による
実行計画のボトルネック特定
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR の概要
• 実行計画を出力するためのPL/SQLパッケージ(標準機能)
• ボトルネック特定を行いたいSQLの sql_id を調査
• 対象SQLの完了を待つか、Ctrl+C等 で強制終了
• 対象SQLの完了後、下記SQLを実行して
対象SQL の実行計画/実行統計を出力
• formatパラメータに ALLSTATSオプションを付与
26
SELECT * FROM TABLE(
DBMS_XPLAN.DISPLAY_CURSOR(
'対象SQL の sql_id', NULL, 'ALL ALLSTATS LAST'));
KROWN#141531
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR の制限事項
• 10gR1以降の機能
• ALLSTATS書式を有効化する場合
• 下記の「どちらか」を満たして、実行統計が採取される状態で SQL を実行する
• 初期化パラメータ「STATISTICS_LEVEL = ALL」を設定
※セッション単位(ALTER SESSION~)でも設定可能
• SQL に /*+ gather_plan_statistics */ヒントを付与
• 対象SQLが終了すると、実行統計が共有プールのカーソルに反映
• SQLが完全に終了するか、Ctrl+C等で強制終了
• 強制終了させた場合は、強制終了時点までの実行統計が反映
• SQL終了前に実行計画を出力しても、実行統計は出ない
27
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR の実行例
• 実行例(※一部の出力行/出力項目を省略)
28
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------------------------- SQL_ID 80w7gaz4dywud, child number 0 ------------------------------------- SELECT /*+ gather_plan_statistics */ C.DATBI, C.HI_PR, C.LOW_PR, : Plan hash value: 3232858554 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name |…| E-Rows |E-Bytes|…| E-Time | A-Rows | A-Time |…| ------------------------------------------------------------------------------------------------------------------ -- | 0 | SELECT STATEMENT | |…| | |…| | 5924 |00:00:53.45 |…| | 1 | SORT ORDER BY | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.45 |…| | 2 | VIEW | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.43 |…| | 3 | SORT UNIQUE | |…| 414 | 47610 |…| 00:02:43 | 5924 |00:00:53.42 |…| | 4 | WINDOW SORT | |…| 414 | 47610 |…| 00:02:43 | 53460 |00:00:53.33 |…| |* 5 | HASH JOIN | |…| 2722 | 305K|…| 00:02:43 | 53460 |00:00:52.69 |…| | 6 | TABLE ACCESS BY INDEX ROWID| DBN_FTBPR900 |…| 3640 | 145K|…| 00:02:43 | 54338 |00:00:52.49 |…| |* 7 | INDEX SKIP SCAN | DBN_FTBPR900PK |…| 2 | |…| 00:02:43 | 54338 |00:00:51.98 |…| |* 8 | TABLE ACCESS FULL | DBN_FTBAT045 |…| 11477 | 829K|…| 00:00:01 | 22310 |00:00:00.01 |…| ---------------------------------------------------------------------------------------------------------------------- :
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR による解析(1)
• 注目ポイント1
• SQLの実行統計(「実測」の処理件数(A-Rows)/処理時間(A-Time))に注目
29
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); : Plan hash value: 3232858554 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name |…| E-Rows |E-Bytes|…| E-Time | A-Rows | A-Time |…| ------------------------------------------------------------------------------------------------------------------ -- | 0 | SELECT STATEMENT | |…| | |…| | 5924 |00:00:53.45 |…| | 1 | SORT ORDER BY | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.45 |…| | 2 | VIEW | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.43 |…| | 3 | SORT UNIQUE | |…| 414 | 47610 |…| 00:02:43 | 5924 |00:00:53.42 |…| | 4 | WINDOW SORT | |…| 414 | 47610 |…| 00:02:43 | 53460 |00:00:53.33 |…| |* 5 | HASH JOIN | |…| 2722 | 305K|…| 00:02:43 | 53460 |00:00:52.69 |…| | 6 | TABLE ACCESS BY INDEX ROWID| DBN_FTBPR900 |…| 3640 | 145K|…| 00:02:43 | 54338 |00:00:52.49 |…| |* 7 | INDEX SKIP SCAN | DBN_FTBPR900PK |…| 2 | |…| 00:02:43 | 54338 |00:00:51.98 |…| |* 8 | TABLE ACCESS FULL | DBN_FTBAT045 |…| 11477 | 829K|…| 00:00:01 | 22310 |00:00:00.01 |…| ---------------------------------------------------------------------------------------------------------------------- :
実行統計
ここが遅そう…
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR による解析(2)
• 注目ポイント2
• 実行統計(Actual)と CBO予測(Estimate)の乖離に注目
30
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); : Plan hash value: 3232858554 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name |…| E-Rows |E-Bytes|…| E-Time | A-Rows | A-Time |…| ------------------------------------------------------------------------------------------------------------------ -- | 0 | SELECT STATEMENT | |…| | |…| | 5924 |00:00:53.45 |…| | 1 | SORT ORDER BY | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.45 |…| | 2 | VIEW | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.43 |…| | 3 | SORT UNIQUE | |…| 414 | 47610 |…| 00:02:43 | 5924 |00:00:53.42 |…| | 4 | WINDOW SORT | |…| 414 | 47610 |…| 00:02:43 | 53460 |00:00:53.33 |…| |* 5 | HASH JOIN | |…| 2722 | 305K|…| 00:02:43 | 53460 |00:00:52.69 |…| | 6 | TABLE ACCESS BY INDEX ROWID| DBN_FTBPR900 |…| 3640 | 145K|…| 00:02:43 | 54338 |00:00:52.49 |…| |* 7 | INDEX SKIP SCAN | DBN_FTBPR900PK |…| 2 | |…| 00:02:43 | 54338 |00:00:51.98 |…| |* 8 | TABLE ACCESS FULL | DBN_FTBAT045 |…| 11477 | 829K|…| 00:00:01 | 22310 |00:00:00.01 |…| ---------------------------------------------------------------------------------------------------------------------- :
CBOは2件アクセスと予測しているが、実際は54338件にアクセス
実行統計 CBO予測
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR による解析(3)
• 前2ページの解析より、実行計画の Id 7 がボトルネックに
なっていると判断
31
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); : Plan hash value: 3232858554 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name |…| E-Rows |E-Bytes|…| E-Time | A-Rows | A-Time |…| ------------------------------------------------------------------------------------------------------------------ -- | 0 | SELECT STATEMENT | |…| | |…| | 5924 |00:00:53.45 |…| | 1 | SORT ORDER BY | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.45 |…| | 2 | VIEW | |…| 414 | 28566 |…| 00:02:43 | 5924 |00:00:53.43 |…| | 3 | SORT UNIQUE | |…| 414 | 47610 |…| 00:02:43 | 5924 |00:00:53.42 |…| | 4 | WINDOW SORT | |…| 414 | 47610 |…| 00:02:43 | 53460 |00:00:53.33 |…| |* 5 | HASH JOIN | |…| 2722 | 305K|…| 00:02:43 | 53460 |00:00:52.69 |…| | 6 | TABLE ACCESS BY INDEX ROWID| DBN_FTBPR900 |…| 3640 | 145K|…| 00:02:43 | 54338 |00:00:52.49 |…| |* 7 | INDEX SKIP SCAN | DBN_FTBPR900PK |…| 2 | |…| 00:02:43 | 54338 |00:00:51.98 |…| |* 8 | TABLE ACCESS FULL | DBN_FTBAT045 |…| 11477 | 829K|…| 00:00:01 | 22310 |00:00:00.01 |…| ---------------------------------------------------------------------------------------------------------------------- :
・処理時間の実行統計(A-time)が多い。 ・処理件数のCBO予測(E-Rows)と実行統計(A-Rows)が乖離している。
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの概要
• SQLチューニングのための機能を提供するPL/SQLパッケージ(オプション)
• チューニング対象のSQLのsql_idを特定
• 対象SQL の リアルタイムSQL監視レポートを出力例
※対象SQLが実行中でも可能
32
SET LONG 1000000
SET LONGC 1000000
VAR c_rep CLOB;
EXEC :c_rep := DBMS_SQLTUNE.REPORT_SQL_MONITOR(sql_id => '対象SQLのsql_id');
PRINT c_rep;
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの制限事項
• 11gR1以降の機能
• DBMS_SQLTUNEパッケージを使用するためには
Enterprise Edition の Tuning Packオプションライセンスが必要
• リアルタイムSQL監視の対象となる(※V$SQL_MONITORビューに載る)ため下記の「どれか」が満たされる必要
• SQL の処理時間が5秒以上
• SQL に MONITORヒントを付与
• パラレル・クエリー
33
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの実行例 • 実行例(※一部の出力行/出力項目を省略)
34
SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text ------------------------------ SELECT B762.R_DIST_CODE || B762.R_CUSTOMER_CODE … Global Stats =================================================================== | Elapsed | Cpu | IO | Other | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | =================================================================== | 1268 | 1267 | 0.03 | 0.29 | 15317 | 1 | 1MB | =================================================================== SQL Plan Monitoring Details (Plan Hash Value=546406420) ====================================================================================================================== | Id | Operation | Name | Rows |…| Execs | Rows |…| Activity | Activity Detail | | | | | (Estim) |…| | (Actual) |…| (%) | (# samples) | ====================================================================================================================== | 0 | SELECT STATEMENT | | |…| 1 | |…| | | | 1 | SORT UNIQUE | | 6011 |…| 1 | 0 |…| | | | 2 | UNION-ALL | | |…| 1 | 1105 |…| | | | : | : | : | : |…| :| : |…| : | : | | 7 | VIEW | VM_NWVW_1 | 7 |…| 1 | |…| | | | -> 8 | HASH GROUP BY | | 7 |…| 1 | 0 |…| 92.11 | Cpu (1168) | | -> 9 | HASH JOIN | | 2M |…| 1 | 980M |…| 7.57 | Cpu (96) | | 10 | INDEX RANGE SCAN | KUAB11101 | 6021 |…| 1 | 2635 |…| | | | : | : | : | : |…| :| : |…| : | : | | 20 | TABLE ACCESS FULL | CUAB111 | 2635 |…| 1 | 2635 |…| | | ======================================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(1) • 注目ポイント1…実行統計(SQLの「実際」の処理時間/処理件数)に注目
35
SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text ------------------------------ SELECT B762.R_DIST_CODE || B762.R_CUSTOMER_CODE … Global Stats =================================================================== | Elapsed | Cpu | IO | Other | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | =================================================================== | 1268 | 1267 | 0.03 | 0.29 | 15317 | 1 | 1MB | =================================================================== SQL Plan Monitoring Details (Plan Hash Value=546406420) ====================================================================================================================== | Id | Operation | Name | Rows |…| Execs | Rows |…| Activity | Activity Detail | | | | | (Estim) |…| | (Actual) |…| (%) | (# samples) | ====================================================================================================================== | 0 | SELECT STATEMENT | | |…| 1 | |…| | | | 1 | SORT UNIQUE | | 6011 |…| 1 | 0 |…| | | | 2 | UNION-ALL | | |…| 1 | 1105 |…| | | | : | : | : | : |…| :| : |…| : | : | | 7 | VIEW | VM_NWVW_1 | 7 |…| 1 | |…| | | | -> 8 | HASH GROUP BY | | 7 |…| 1 | 0 |…| 92.11 | Cpu (1168) | | -> 9 | HASH JOIN | | 2M |…| 1 | 980M |…| 7.57 | Cpu (96) | | 10 | INDEX RANGE SCAN | KUAB11101 | 6021 |…| 1 | 2635 |…| | | | : | : | : | : |…| :| : |…| : | : | | 20 | TABLE ACCESS FULL | CUAB111 | 2635 |…| 1 | 2635 |…| | | ======================================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(2) • 注目ポイント2…実行統計(Actual)と CBO予測(Estimate)の乖離に注目
36
SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text ------------------------------ SELECT B762.R_DIST_CODE || B762.R_CUSTOMER_CODE … Global Stats =================================================================== | Elapsed | Cpu | IO | Other | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | =================================================================== | 1268 | 1267 | 0.03 | 0.29 | 15317 | 1 | 1MB | =================================================================== SQL Plan Monitoring Details (Plan Hash Value=546406420) ====================================================================================================================== | Id | Operation | Name | Rows |…| Execs | Rows |…| Activity | Activity Detail | | | | | (Estim) |…| | (Actual) |…| (%) | (# samples) | ====================================================================================================================== | 0 | SELECT STATEMENT | | |…| 1 | |…| | | | 1 | SORT UNIQUE | | 6011 |…| 1 | 0 |…| | | | 2 | UNION-ALL | | |…| 1 | 1105 |…| | | | : | : | : | : |…| :| : |…| : | : | | 7 | VIEW | VM_NWVW_1 | 7 |…| 1 | |…| | | | -> 8 | HASH GROUP BY | | 7 |…| 1 | 0 |…| 92.11 | Cpu (1168) | | -> 9 | HASH JOIN | | 2M |…| 1 | 980M |…| 7.57 | Cpu (96) | | 10 | INDEX RANGE SCAN | KUAB11101 | 6021 |…| 1 | 2635 |…| | | | : | : | : | : |…| :| : |…| : | : | | 20 | TABLE ACCESS FULL | CUAB111 | 2635 |…| 1 | 2635 |…| | | ======================================================================================================================
実行統計(待機イベント付き)
実行統計(トータル)
CBO予測
CBOは2M件アクセスと予測しているが、実際は980M件にアクセス
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(3) • 前2ページの解析より、実行計画の Id 8,9 がボトルネックと判断
37
SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text ------------------------------ SELECT B762.R_DIST_CODE || B762.R_CUSTOMER_CODE … Global Stats =================================================================== | Elapsed | Cpu | IO | Other | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | =================================================================== | 1268 | 1267 | 0.03 | 0.29 | 15317 | 1 | 1MB | =================================================================== SQL Plan Monitoring Details (Plan Hash Value=546406420) ====================================================================================================================== | Id | Operation | Name | Rows |…| Execs | Rows |…| Activity | Activity Detail | | | | | (Estim) |…| | (Actual) |…| (%) | (# samples) | ====================================================================================================================== | 0 | SELECT STATEMENT | | |…| 1 | |…| | | | 1 | SORT UNIQUE | | 6011 |…| 1 | 0 |…| | | | 2 | UNION-ALL | | |…| 1 | 1105 |…| | | | : | : | : | : |…| :| : |…| : | : | | 7 | VIEW | VM_NWVW_1 | 7 |…| 1 | |…| | | | -> 8 | HASH GROUP BY | | 7 |…| 1 | 0 |…| 92.11 | Cpu (1168) | | -> 9 | HASH JOIN | | 2M |…| 1 | 980M |…| 7.57 | Cpu (96) | | 10 | INDEX RANGE SCAN | KUAB11101 | 6021 |…| 1 | 2635 |…| | | | : | : | : | : |…| :| : |…| : | : | | 20 | TABLE ACCESS FULL | CUAB111 | 2635 |…| 1 | 2635 |…| | | ======================================================================================================================
・処理時間の実行統計(Activity Detail)が多い。 ・処理件数のCBO予測(Rows Estim)と実行統計(Rows Actual)が乖離している。
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
リアルタイムSQL監視による確認 • テキスト形式と同等の情報を、GUIのオペレーションで参照可能
38
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN/DBMS_SQLTUNEの比較
39
DBMS_XPLAN.DISPLAY_CURSOR
(ALLSTATS書式)
DBMS_SQLTUNE.
REPORT_SQL_MONITOR
バージョン 10gR1以降 11gR1以降
有償オプション 不要 要Tuning Pack
事前準備
どちらかを事前に仕込む必要アリ
STATISTICS_LEVEL=ALL
gather_plan_statistics
ヒント付与
SQLが5秒以上、又はパラレル・クエリなら不要
非パラレル かつ 5秒未満の場合はMONITORヒント付与
採取可能な
情報 実行統計(行数/処理時間)
実行統計(行数/処理時間/
トータル統計/待機イベント)
SQL終了要否 対象SQLが終了しているか、Ctrl+C等で強制終了させる必要がある。
対象SQLが実行中でも
情報採取可能
有償オプションが必要な DBMS_SQLTUNE の方が総じて優秀
但し DBMS_XPLAN でしか採取できない情報もある
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
疑似ワークショップによる
SQLチューニング案の紹介
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
疑似ワークショップの目的
• ワークショップの目的は SQLチューニングの
ネタ/引き出し(選択肢)を増やすこと
• 上級者への入り口
• チューニングのネタ/引き出しが増えれば、
目標到達への可能性が広がる
• 複数あるチューニング案の一部を紹介
• SQLチューニングを疑似体験して、引き出しを増やしましょう!
41
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
疑似ワークショップの課題SQL
• チューニング対象のSQL
• TEST_TABLE_A表 と TBL_B表 を結合する SQL
42
チューニング前
-- g9gnrhjwajfnn
SELECT /*+ MONITOR */
A.*
FROM
TEST_TABLE_A A,
TBL_B B
WHERE A.P_NO2 = B.P_NO
AND A.P_CHAR = B.P_CHAR
AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801';
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQL実行時間とAUTOTRACE統計
• チューニング前のSQL実行時間/AUTOTRACE統計
• 下記の実行時間(Elapsed)と負荷(gets/reads)を減らすのが、
SQLチューニングのセオリー
43
チューニング前
10:39:35 SQL> SELECT /*+ MONITOR */ 10:39:35 2 A.* 10:39:35 3 FROM TEST_TABLE_A A 10:39:35 4 , TBL_B B 10:39:35 5 WHERE A.P_NO2 = B.P_NO 10:39:35 6 AND A.P_CHAR = B.P_CHAR 10:39:35 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801'; 1102 rows selected. Elapsed: 00:00:12.44 : Statistics ---------------------------------------------------------- 8923 consistent gets 5985 physical reads
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN.DISPLAY_CURSOR結果
44
チューニング前
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('g9gnrhjwajfnn', NULL, 'ADVANCED ALLSTATS LAST')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- SQL_ID g9gnrhjwajfnn, child number 0 ------------------------------------- SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A , TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801' Plan hash value: 960095112 ------------------------------------------------------------------------------------------------ | Id | Operation | Name || E-Rows |E-Bytes|| E-Time | A-Rows | A-Time || ------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | || | || | 1102 |00:00:10.41 || |* 1 | HASH JOIN | || 81 | 2349 || 00:00:01 | 1102 |00:00:10.41 || | 2 | TABLE ACCESS FULL| TEST_TABLE_A || 26 | 416 || 00:00:01 | 2600K|00:00:01.49 || |* 3 | TABLE ACCESS FULL| TBL_B || 300 | 3900 || 00:00:01 | 11 |00:00:00.09 || ------------------------------------------------------------------------------------------------
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
DBMS_SQLTUNE.REPORT_SQL_MONITOR結果
45
チューニング前
SQL Text ------------------------------ SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A , TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801‘ : Global Stats ================================================================================ | Elapsed | Cpu | IO | Fetch | Buffer | Read | Read | Write | Write | | Time(s) | Time(s) | Waits(s) | Calls | Gets | Reqs | Bytes | Reqs | Bytes | ================================================================================ | 11 | 8.06 | 2.90 | 75 | 8936 | 108 | 26MB | 305 | 74MB | ================================================================================ SQL Plan Monitoring Details (Plan Hash Value=960095112) =========================================================================================================== | Id | Operation | Name | Rows || Rows || Activity | Activity Detail | | | | | (Estim) || (Actual) || (%) | (# samples) | =========================================================================================================== | 0 | SELECT STATEMENT | | || 1102 || | | | 1 | HASH JOIN | | 81 || 1102 || 90.91 | Cpu (9) | | | | | || || | direct path write temp (1) | | 2 | TABLE ACCESS FULL | TEST_TABLE_A | 26 || 3M || 9.09 | Cpu (1) | | 3 | TABLE ACCESS FULL | TBL_B | 300 || 11 || | | ===========================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
チューニング案の一覧 • 今回のSQLでは下記に挙げるチューニングで性能が改善
• 案1 … DBMS_STATSによる統計情報採取
• 案2 … 拡張統計の採取
• 案3 … SQLプロファイル適用(by DBMS_SQLTUNE)
• 案4 … Cardinality Feedbackの使用
• 案5 … ヒント や SPM による実行計画操作
• 案6 … パラレル・クエリ化
• 案7 … SQL修正(WHERE句書き換え)
• 案8 … SQL修正(WITH句によるサブクエリ切り出し)
• 案9 … Dynamic Sampling適用
• 案10…新規索引付与
• 案11…リザルト・セットの適用
46
今回紹介する チューニング案
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案1. DBMS_STATSによる
統計情報採取
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案1. DBMS_STATSによる統計情報採取(1)
• まず確認するのは、統計情報が実態と合っているか?
48
SQL> SELECT TABLE_NAME, NUM_ROWS FROM USER_TABLES WHERE TABLE_NAME IN ('TEST_TABLE_A', 'TBL_B'); TABLE_NAME NUM_ROWS ------------------------------ ---------- TEST_TABLE_A 26 TBL_B 30012 SQL> SELECT COUNT(*) FROM TEST_TABLE_A; COUNT(*) ---------- 2600026 SQL> SELECT COUNT(*) FROM TBL_B; COUNT(*) ---------- 30012
統計は 26件
実態は 約2,600,000件
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案1. DBMS_STATSによる統計情報採取(2)
• DBMS_STATSパッケージで統計情報を採取
• 採取した統計を即座に使用(NO_INVALIDATE => FALSE)
• 4パラレルで採取(DEGREE => 4)
49
EXEC DBMS_STATS.GATHER_TABLE_STATS( USER , 'TEST_TABLE_A’ , NO_INVALIDATE => FALSE , DEGREE => 4);
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案1. DBMS_STATSによる統計情報採取(3)
• 統計情報採取後の実行統計
50
10:39:35 SQL> SELECT /*+ MONITOR */ 10:39:35 2 A.* 10:39:35 3 FROM TEST_TABLE_A A 10:39:35 4 , TBL_B B 10:39:35 5 WHERE A.P_NO2 = B.P_NO 10:39:35 6 AND A.P_CHAR = B.P_CHAR 10:39:35 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801'; 1102 rows selected. Elapsed: 00:00:12.44 : Statistics ---------------------------------------------------------- 8923 consistent gets 5985 physical reads
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
性能改善!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 51
DBMS_XPLAN.DISPLAY_CURSOR結果の比較 案1. DBMS_STATSによる統計情報採取(4)
--------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:12.32 | |* 1 | HASH JOIN | | 81 | 2349 | 00:00:01 | 1102 |00:00:12.32 | | 2 | TABLE ACCESS FULL| TEST_TABLE_A | 26 | 416 | 00:00:01 | 2600K|00:00:01.46 | |* 3 | TABLE ACCESS FULL| TBL_B | 300 | 3900 | 00:00:01 | 11 |00:00:00.09 | ---------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:04.65 | |* 1 | HASH JOIN | | 30012 | 967K| 00:00:32 | 1102 |00:00:04.65 | |* 2 | TABLE ACCESS FULL| TBL_B | 300 | 3900 | 00:00:01 | 11 |00:00:00.08 | | 3 | TABLE ACCESS FULL| TEST_TABLE_A | 2600K| 49M| 00:00:31 | 2600K|00:00:01.48 | ---------------------------------------------------------------------------------------------
• Before
• After
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 52
DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較 案1. DBMS_STATSによる統計情報採取(5)
============================================================================================== | Id | Operation | Name | Rows | Rows | Activity Detail | | | | | (Estim) | (Actual) | (# samples) | ============================================================================================== | 0 | SELECT STATEMENT | | | 1102 | | | 1 | HASH JOIN | | 81 | 1102 | Cpu (8) | | | | | | | direct path write temp (4) | | 2 | TABLE ACCESS FULL | TEST_TABLE_A | 26 | 3M | | | 3 | TABLE ACCESS FULL | TBL_B | 300 | 11 | | ==============================================================================================
=================================================================================== | 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 | | ===================================================================================
• Before
• After
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案1. DBMS_STATSによる統計情報採取(6)
• CBO は統計情報を元に、最適な実行計画を予測して組み立てる
• テーブルの統計情報と実態(実件数)が合致しているか
どうかを、真っ先に確認
• 0件統計(←典型的なアンチパターン!)
• 0件では無いが、実態と乖離した統計
• 統計情報最新化で HASH JOIN の結合順序が入れ替わり、
一時表領域へのI/Oが無くなって性能が改善
53
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案2. 拡張統計の採取
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案2. 拡張統計の採取(1)
• 表の列(カラム)に関数を適用しているのは、
SQLのアンチパターンの一つ
• このパターンが性能劣化し易い理由は以下の2つに集約される
1. 列に作成された索引が使用されない
2. CBO が列統計を使用できず、実行計画の予測精度が落ちる
• 今回は 2 に着目
55
SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A , TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801';
P_DATE列にTO_CHAR関数を適用
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案2. 拡張統計の採取(2)
• DBMS_STATSパッケージで拡張統計情報を採取
• METHOD_OPT に 拡張統計(※今回のSQLでは式統計)の
明示的採取を設定
• ESTIMATE_PERCENT に 100 を設定して、全サンプリング
56
DBMS_STATS.GATHER_TABLE_STATS( USER,'TBL_B', NO_INVALIDATE => FALSE, METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO ' || 'FOR COLUMNS (TO_CHAR(P_DATE, ''YYYYMMDD'')) SIZE 254', DEGREE => 4, ESTIMATE_PERCENT => 100);
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案2. 拡張統計の採取(3)
• 拡張統計(式統計)採取後の実行統計
57
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
性能改善!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 58
DBMS_XPLAN.DISPLAY_CURSOR結果の比較 案2. 拡張統計の採取(4)
• Before
• After
--------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:04.65 | |* 1 | HASH JOIN | | 30012 | 967K| 00:00:32 | 1102 |00:00:04.65 | |* 2 | TABLE ACCESS FULL| TBL_B | 300 | 3900 | 00:00:01 | 11 |00:00:00.08 | | 3 | TABLE ACCESS FULL| TEST_TABLE_A | 2600K| 49M| 00:00:31 | 2600K|00:00:01.48 | ---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:00.11 | | 1 | NESTED LOOPS | | | | | 1102 |00:00:00.11 | | 2 | NESTED LOOPS | | 1106 | 37604 | 00:00:14 | 1102 |00:00:00.09 | |* 3 | TABLE ACCESS FULL | TBL_B | 11 | 154 | 00:00:01 | 11 |00:00:00.09 | |* 4 | INDEX RANGE SCAN | TEST_TABLE_A_I1 | 100 | | 00:00:01 | 1102 |00:00:00.01 | | 5 | TABLE ACCESS BY INDEX ROWID| TEST_TABLE_A | 101 | 2020 | 00:00:02 | 1102 |00:00:00.01 | ----------------------------------------------------------------------------------------------------------
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 59
DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較 案2. 拡張統計の採取(5)
• 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 | | ================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案2. 拡張統計の採取(6)
• 今回のケースでは「式統計」を採取することで、CBO予測の誤りを補正
• CBO予測の誤りが補正されたことで、より良い実行計画が選択された
• 拡張統計
• 式統計
• 複数列統計
• サブクエリ内で DISTINCT/GROUP BY を使用するケースで、
グルーピングしている列値同士に相関関係が有る場合に有効
60
SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A , TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801';
ここの式統計を採取
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用
(by DBMS_SQLTUNE)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(1)
• SQLプロファイルは、DBMS_SQLTUNE の
チューニング・タスク実行によって作成/提案される
• リアルタイムSQL監視(REPORT_SQL_MONITOR) に並ぶ、
DBMS_SQLTUNEパッケージ の有効な機能
• Enterprise Edition の Tuning Packオプションライセンスが必要
• 個別SQLのCBO予測(実行計画作成)を精緻化する
• 使いこなせれば、強力なSQLチューニング手段の一つ
62
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(2)
• SQLプロファイルの作成/適用サンプル
63
SQL> VARIABLE STMT_TASK VARCHAR2(64); SQL> EXEC :STMT_TASK := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => 'g9gnrhjwajfnn', time_limit => 10800); Elapsed: 00:00:00.46 SQL> EXEC DBMS_SQLTUNE.EXECUTE_TUNING_TASK(:STMT_TASK); Elapsed: 00:12:12.02 SQL> SET LONGCHUNKSIZE 2000000 LONG 2000000 LINESIZE 300 PAGESIZE 1000; SQL> COLUMN REPORT FORMAT A300 SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(:STMT_TASK) AS REPORT FROM DUAL; : 1- SQL Profile Finding (see explain plans section below) -------------------------------------------------------- A potentially better execution plan was found for this statement. Recommendation (estimated benefit: 87.03%) ------------------------------------------ - Consider accepting the recommended SQL profile. execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); : SQL> execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); Elapsed: 00:00:00.44 SQL>
①チューニング・タスク作成
②チューニング・タスク実行
③チューニング・タスクのレポーティング
④SQLプロファイルの承認 (※③でSQLプロファイルが提案された場合)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(3)
• SQLプロファイルのサンプル(チューニング・タスク・レポート)
64
19:00:16 SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(:STMT_TASK) 19:00:16 2> AS REPORT FROM DUAL; : 1- SQL Profile Finding (see explain plans section below) -------------------------------------------------------- A potentially better execution plan was found for this statement. : Recommendation (estimated benefit: 87.03%) ------------------------------------------ - Consider accepting the recommended SQL profile. execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); : Validation results ------------------ The SQL profile was tested by executing both its plan and the original plan and measuring their respective execution statistics. A plan may have been only partially executed if the other could be run to completion in less time.
: Original Plan With SQL Profile % Improved ------------- ---------------- ---------- Completion Status: COMPLETE COMPLETE Elapsed Time (s): 4.673067 .098527 97.89 % CPU Time (s): 4.68 .099 97.88 % User I/O Time (s): 0 0 Buffer Gets: 8919 1207 86.46 % Physical Read Requests: 0 0 Physical Write Requests: 0 0 Physical Read Bytes: 0 0 Physical Write Bytes: 0 0 Rows Processed: 1102 1102 Fetches: 1102 1102 Executions: 1 1 Notes ----- 1. Statistics for the original plan were averaged over 1 executions. 2. Statistics for the SQL profile plan were averaged over 10 executions. :
SQLプロファイルが提案されている。 SQLプロファイル 適用前の統計
SQLプロファイル 適用後の統計
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(4)
• SQLプロファイル適用後の実行統計
65
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
19:00:18 SQL> SELECT /*+ MONITOR */ 19:00:18 2 A.* 19:00:18 3 FROM TEST_TABLE_A A 19:00:18 4 , TBL_B B 19:00:18 5 WHERE A.P_NO2 = B.P_NO 19:00:18 6 AND A.P_CHAR = B.P_CHAR 19:00:18 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801'; 1102 rows selected. Elapsed: 00:00:00.17 Note ----- - SQL profile "SYS_SQLPROF_013aeee99cec0000" used for this… Statistics ---------------------------------------------------------- 1312 consistent gets 1 physical reads
性能改善!
SQLプロファイル が使用されている
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 66
DBMS_XPLAN.DISPLAY_CURSOR結果の比較 案3. SQLプロファイル適用(by DBMS_SQLTUNE)(5)
• Before
• After
--------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:04.65 | |* 1 | HASH JOIN | | 30012 | 967K| 00:00:32 | 1102 |00:00:04.65 | |* 2 | TABLE ACCESS FULL| TBL_B | 300 | 3900 | 00:00:01 | 11 |00:00:00.08 | | 3 | TABLE ACCESS FULL| TEST_TABLE_A | 2600K| 49M| 00:00:31 | 2600K|00:00:01.48 | ---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:00.10 | | 1 | NESTED LOOPS | | | | | 1102 |00:00:00.10 | | 2 | NESTED LOOPS | | 1100 | 36300 | 00:00:14 | 1102 |00:00:00.09 | |* 3 | TABLE ACCESS FULL | TBL_B | 11 | 143 | 00:00:01 | 11 |00:00:00.08 | |* 4 | INDEX RANGE SCAN | TEST_TABLE_A_I1 | 100 | | 00:00:01 | 1102 |00:00:00.01 | | 5 | TABLE ACCESS BY INDEX ROWID| TEST_TABLE_A | 100 | 2000 | 00:00:02 | 1102 |00:00:00.01 | ----------------------------------------------------------------------------------------------------------
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 67
DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較 案3. SQLプロファイル適用(by DBMS_SQLTUNE)(6)
• 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 | Activity Detail | | | | | (Estim) | (Actual) | (%) | (# samples) | =========================================================================================================== | 0 | SELECT STATEMENT | | | 1102 | | | | 1 | NESTED LOOPS | | | 1102 | | | | 2 | NESTED LOOPS | | 1100 | 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 | 100 | 1102 | | | ===========================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(7)
• SQLプロファイルの仕組みについて、マニュアル(※)を参照 • 17.5 SQLプロファイルの管理
SQLプロファイルには、個別の実行計画に関する情報は含まれません。オプティマイザには、計画を選択する際に、次の情報ソースがあります。
• データベース構成、バインド変数値、オプティマイザ統計、データ・セットなどを含む環境
• SQLプロファイルの補足的な統計情報
• SQLプロファイルの正体は、
「個別のSQLに特化した補助的なオプティマイザ統計」
• 個別SQLに対する詳細なダイナミック・サンプリングのようなもの
• サンプリング結果を実体として保持
• そのサンプリング結果が適用されると、CBO予測が精緻化されて実行計画が改善
• SPM や アウトライン のように、実行計画そのものを保持している訳ではない
※マニュアル … Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース2(11.2)B56312-01
68
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(8)
• SQLプロファイル有効時の10053トレース抜粋例
• SQL内のカーディナリティやセレクティビティに関する補足情報
69
: atom_hint=(~txt=OPT_ESTIMATE (INDEX_FILTER "B111" "xxxx11101" ROWS=2635.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (INDEX_SCAN "B111" "xxxx11101" MIN=2635.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (TABLE "x111" ROWS=2635.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (GROUP_BY ROWS=7.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (INDEX_FILTER "A002" "yyyy00201" MIN=1105.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (INDEX_SCAN "A002" "yyyy00201" MIN=1105.000000 ) ) atom_hint=(~txt=OPT_ESTIMATE (TABLE "y002" MIN=1105.000000 ) ) :
KROWN#124903 event 10053 トレースの取得方法
event 10053 は、Cost Base Optimizer(CBO)の動作をトレースするイベント
KROWN#124903
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(9)
• SQLプロファイルを作成/適用する環境は、「本番環境、又はそれに準じた量/質のデータが保持されている」必要がある
• この点を理解していれば、複雑なSQLを機械的に
チューニングできる、強力な武器となる
• 機械的なチューニングによる、時間短縮/必要スキル低減/コスト削減
• 本番環境⇔開発環境間の相互移行も可能
• 性能改善が100%保証される訳ではないので、
適用後の検証/評価は必要
70
※ 本番環境⇔開発環境間の移行方法
• Notes#457531.1 How to Move SQL Profiles from One Database to Another
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(10)
• SQLプロファイル生成時のチューニング・タスクでは、最終ハード・パースのバインド変数で、対象SQLを実際に実行して統計を採取
• 「Completion Status」の値が双方「COMPLETE」であれば、
SQLプロファイル適用による性能改善の確度は高い
71
Original Plan With SQL Profile % Improved ------------- ---------------- ---------- Completion Status: COMPLETE COMPLETE Elapsed Time (s): 4.673067 .098527 97.89 % CPU Time (s): 4.68 .099 97.88 % User I/O Time (s): 0 0 Buffer Gets: 8919 1207 86.46 % Physical Read Requests: 0 0 Physical Write Requests: 0 0 Physical Read Bytes: 0 0 Physical Write Bytes: 0 0 Rows Processed: 1102 1102 Fetches: 1102 1102 Executions: 1 1 :
SQLプロファイル適用前後の検証が完了している。
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案3. SQLプロファイル適用(by DBMS_SQLTUNE)(11)
• Enterprise Managerからも作成/適用可能
72
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案4. Cardinality Feedbackの使用
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案4. Cardinality Feedbackの使用(1)
• Cardinality Feedback は、
CBOの実行計画予測精度を上げる機能の一つ
• 11gR2 で導入された新機能
• CBO予測と実行統計が乖離している際に、
2回目以降のSQL実行時に実行結果を Feedback して、
実行計画を作成し直す機能
• Feedback結果によりCBO予測が精緻化される
74
KROWN#147614 [11.2 新機能] オプティマイザ・フィードバック(カーディナリティ・フィードバック)
KROWN#147614
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案4. Cardinality Feedbackの使用(2)
• Cardinality Feedback はデフォルトで有効
• 隠しパラメータ“_optimizer_use_feedback”で制御可能 ※ KROWN#147614 [11.2 新機能] オプティマイザ・フィードバック(カーディナリティ・フィードバック)
75
-- Cardinality Feedback を無効化 ALTER SYSTEM SET "_optimizer_use_feedback" = FALSE SCOPE = BOTH; -- Cardinality Feedback を有効化 ALTER SYSTEM SET "_optimizer_use_feedback" = TRUE SCOPE = BOTH;
KROWN#147614
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案4. Cardinality Feedbackの使用(3)
• Cardinality Feedback有効時の実行統計(2回目)
76
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
21:12:15 SQL> SELECT /*+ MONITOR */ 21:12:15 2 A.* 21:12:15 3 FROM TEST_TABLE_A A 21:12:15 4 , TBL_B B 21:12:15 5 WHERE A.P_NO2 = B.P_NO 21:12:15 6 AND A.P_CHAR = B.P_CHAR 21:12:15 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801'; 1102 rows selected. Elapsed: 00:00:00.14 Statistics ---------------------------------------------------------- 1301 consistent gets 1 physical reads
性能改善!
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 77
DBMS_XPLAN.DISPLAY_CURSOR結果の比較 案4. Cardinality Feedbackの使用(4)
• Before
• After(2回目の実行計画)
--------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:04.65 | |* 1 | HASH JOIN | | 30012 | 967K| 00:00:32 | 1102 |00:00:04.65 | |* 2 | TABLE ACCESS FULL| TBL_B | 300 | 3900 | 00:00:01 | 11 |00:00:00.08 | | 3 | TABLE ACCESS FULL| TEST_TABLE_A | 2600K| 49M| 00:00:31 | 2600K|00:00:01.48 | ---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| E-Time | A-Rows | A-Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 1102 |00:00:00.10 | | 1 | NESTED LOOPS | | | | | 1102 |00:00:00.10 | | 2 | NESTED LOOPS | | 1100 | 36300 | 00:00:14 | 1102 |00:00:00.09 | |* 3 | TABLE ACCESS FULL | TBL_B | 11 | 143 | 00:00:01 | 11 |00:00:00.08 | |* 4 | INDEX RANGE SCAN | TEST_TABLE_A_I1 | 100 | | 00:00:01 | 1102 |00:00:00.01 | | 5 | TABLE ACCESS BY INDEX ROWID| TEST_TABLE_A | 100 | 2000 | 00:00:02 | 1102 |00:00:00.01 | ----------------------------------------------------------------------------------------------------------
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 78
DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較 案4. Cardinality Feedbackの使用(5)
• Before
• After(2回目の実行計画)
=================================================================================== | 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 | | ================================================================================================
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
案4. Cardinality Feedbackの使用(6)
• 今回のケースでは「Cardinality Feedback」により、
2回目のSQLでCBO予測の誤りが補正
• CBO予測の誤りが補正されたことで、より良い実行計画が選択
• CBOによる実行計画の予測精度を上げる働きを持つ機能
• BindPeek , Cardinality Feedback , Dynamic Sampling
※ これらの機能を「実行計画の安定化」を目的に、無効化されているシステムも多い
• これらの機能を無効化することは、CBOの機能/性能を
スポイルしている、と云う事実認識も必要
• ハズレの実行計画を引く確率が高まると云うリスクの増加
• 10gR2 までの BindPeek の欠点(※初回PARSE時のプランで固定される)は11gR1導入の「優れたカーソル共有」で改善
• 現在はBindPeek使用も有力な選択肢で、false一択ではない
※ KROWN#127064 [11g新機能] 優れたカーソル共有
79
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLチューニングのまとめ
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQL と オプティマイザ が抱える弱点
• SQL と RDBMSのオプティマイザ は、
その言語の仕組みに由来する本質的な弱点を抱えている
• SQLはアルゴリズムを記述しないと云う特徴があるため、
それ(アルゴリズム)がRDBMS(オプティマイザ)任せになる
• SQLのアルゴリズム≒実行計画は、
コストと云う基準の「予測」で導出されている
• 「予測」である以上、ハズレのケースが出てくる
81
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
SQLチューニングを上手くやるには
• SQL や オプティマイザ の弱点/アンチパターンを知っておく
• 実行計画は「予測」であり、ハズレが有り得ることの認識
• 予測がハズレる、ハズレ易いケースとは?
• 弱点/アンチパターンの対抗手段を見つけておく
• 予測精度を向上させる設計技法や機能の活用
• 「予測(Estimate)」と「実測(Actual)」を補正するというアプローチ
• アンチパターンをダイレクトに潰す手法も有効
• Oracle Database の機能を利用して、「予測」と「実測」の乖離を捉える
• DBMS_XPLAN.DISPLAY_CURSOR(※ALLSTATS書式)
• DBMS_SQLTUNE.REPORT_SQL_MONITOR(リアルタイムSQL監視)
82
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
紹介したチューニング案の方向性について
• 今回紹介したのは、全て「予測(Estimate)」と「実測(Actual)」の
乖離を補正する方向性でのチューニング
• 既に述べた通り、下記のようなチューニングも可能
• 案5 … ヒント や SPM による実行計画操作
• 案6 … パラレル・クエリ化
• 案7 … SQL修正(WHERE句書き換え)
• 案8 … SQL修正(WITH句によるサブクエリ切り出し)
• 案9 … Dynamic Sampling適用
• 案10…新規索引付与
• 案11…リザルト・セットの適用
• チューニングの正解は1つではないので併せて利用を検討
83
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
共有プールの基本的理解
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 85
• Oracle9i Database ~
• 動的なメモリサイズ変更のサポート(SGA_MAX_SIZE)
• 自動PGAメモリ管理機能の追加(PGA_AGGREGATE_TARGET)
• Shared PoolのCPU数によるヒープ分割機能の追加
• Oracle Database 10g~
• [R1] 自動共有メモリ管理機能の追加(Automatic Shared-Memory Management)
• [R2] Shared Poolの存続期間(Duration)毎の分割管理機能の追加
• Oracle Database 11g~
• [R1] 自動メモリ管理機能の追加(Automatic Memory Management)
• [R2] ASMM/AMM未使用時の各プールサイズの自動調整機能の追加
• [R2] Database Smart Flash Cache機能の追加
バージョン毎の主要な追加機能
Memory Management
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 86
• SGA_TARGET初期化パラメータを使用してSGAの合計量を指定するとMMANによって各コンポーネントのサイズが自動調整される機能
• バッファ・キャッシュを中心に調整され、グラニュル単位で移行
Oracle Database 10g Release 1~ Automatic Shared-Memory Management (ASMM)
SGA
Buffer Cache
Shared Pool
Large Pool
Java Pool
Stream Pool
Shared IO Pool
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
ASMM
87
sga_target
sga_max_size
Buffer
Cache
db_cache_size
shared_pool_size
自動共有メモリ管理時の各メモリ・コンポーネントのサイズを指定するパラメータ(例えば、db_cache_size / shared_pool_size)
は、自動調整の際の下限値となる
sga_targetの上限設定デフォルト値は
sga_targetと同値
全SGAコンポーネントの合計サイズ
明示的に「0」に設定しない限り、ASMMが有効化する
Shared
Pool
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 88
• 手動メモリ管理の場合でもORA-4031の発生を抑止する目的で、
Shared Poolの自動拡張(Buffer Cacheから奪う動作)が実行される
• 注意点
• 手動メモリ管理の場合、DB_CACHE_SIZEパラメータの値がBuffer Cache
の下限値とは認識されない為、Buffer Cacheが1Granulになるまで、
Shared Poolが自動拡張します。
→ V$MEMORY_RESIZE_OPSビューの定期的な監視
→ 隠しパラメータ「_memory_imm_mode_without_autosga=FALSE」を設定し、本機能を無効化する(動的変更可能なパラメータ)
Oracle Database 11g Release 1~
手動メモリ管理での自動調整機能 KROWN#151272
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 89
• MEMORY_TARGET初期化パラメータにより、SGA (SGA_TARGET) と
PGA (PGA_AGGREGATE_TARGET) が自動調整される機能
• SGA 内は自動共有メモリ管理(ASMM) と同じ動作
Oracle Database 11g Release 1~
Automatic Memory Management (AMM)
SGA
Buffer Cache
Shared Pool
Large Pool
Java Pool
Stream Pool
Shared IO Pool PGA
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
AMM
90
memory_target
memory_max_target
PGA
SGA
sga_target
pga_aggregate_target 自動メモリ管理時のsga_target /
pga_aggregate_target/は、自動調整の際の最小値であり、実際のSGAとPGAの 割当値と一致するとは限らない
memory_targetはmemory_max_target 以下で設定可能だが、 sga_target /
pga_aggregate_target を設定している場合、memory_targetはその合計サイズ以上
で設定する必要あり
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
メモリ割り当ての優先度
• 下位のS/Wスタック、業務影響が大きいコンポーネントを優先
• 性能重視ではなく、安定稼働重視
• 土台となるOSやASM インスタ
ンスが健全な状態でなければならない
• あくまで初期構築時に限定
• Workloadに応じて、
随時適切に配分見直しは必須
• Buffer Cacheが不足する場合は、物理メモリの追加を検討
91
Database Server
Operating System
Free Memory
ASM Instance
SGA PGA
Processes
DB Instance
SGA PGA
Processes Buffer Cache
Shared Pool
2
1
3
6 7 Others
5 2
1
3
4
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 92
• SQL、定義情報、実行計画等が格納される共有メモリ領域
• データベースで行われるほぼ全ての操作でアクセスされる領域
共有プールとは
SGA
共有プール
ディクショナリキャッシュ
【オブジェクト定義】
(オブジェクト、ユーザー等のメタデータ)
リザルトキャッシュ
【結果セット】
(リザルトキャッシュ機能利用時)
ライブラリキャッシュ
【共有カーソル】
(SQL、PL/SQL、実行計画)
【オブジェクト定義】
(表、索引等) OTHER
【GCS】
(RAC環境固有)
【GES】
(RAC環境固有)
バッファキャッシュ
ログバッファ、その他
共有プールの基本的理解(1/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 93
• SGAや各プールのメモリ割り当ての最小単位
• 共有プールやバッファキャッシュ等の各領域のサイズはグラニュルサイズの倍数(グラニュルサイズ × グラニュル数) となる
• SGAのサイズ(SGA_MAX_SIZEの値)に応じてグラニュルサイズは大きくなる
• 自動SGA管理、自動メモリ管理における自動調整(拡張/縮小)はグラニュル
単位で行われる
グラニュル(Granule)
SGA_MAX_SIZE グラニュルサイズ
~ 1GB以下 4MB 1GB超 ~ 8GB以下 16MB 8GB超 ~ 16GB以下 32MB 16GB超 ~ 32GB以下 64MB 32GB超 ~ 64GB以下 128MB 64GB超 ~ 128GB以下 256MB 128GB超 ~ 512MB
共有プールの基本的理解(2/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 94
存続期間による分割
存続期間による分割なし sga heap(1,0)
A: 使用中(短期) B: 使用中(長期) C: 使用中(短期)
sga heap(1,0)
A: 空き B: 使用中(長期) C: 空き
メモリ解放 存続期間の短いAとCがまず解放されるが、間に存続期間の長いBが残るため大きな領域を次に割り当てることができない
存続期間の異なるメモリ領域が一つの領域に混在すると、領域が解放されたときにメモリの断片化が発生しやすくなる
メモリ領域は 「チャンク」と呼ばれる可変サイズの断片で割り当てられる。上記 A~C の断片が「チャンク」にあたる
サブプール#n
存続期間による分割あり
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
C: 使用中(短期)
B: 使用中(長期)
A: 使用中(短期)
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
メモリ解放
連続した空き領域に対して大きな領域を割り当てることが可能となる
存続期間に応じて異なるヒープに割り当てる
同等の存続期間(※2)のメモリ領域を決まった領域に割り当てることで断片化が発生しにくくなる
(※2)チャンクの獲得から解放までの期間
B: 使用中(長期)
A: 空き C: 空き
サブプール#n
断片化を低減するために存続期間による分割を導入
共有プールの基本的理解(3/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 95
サブプール分割
サーバプロセスA
サーバプロセスB
サーバプロセスC
sga heap(1,0)
サブプール分割なし
競合 共有プール全体を 1つのラッチで保護
shared pool latch
sga heap(1,0)
sga heap(1,1)
sga heap(1,2)
sga heap(1,3)
サブプール#1
sga heap(2,0)
sga heap(2,1)
sga heap(2,2)
sga heap(2,3)
サブプール#2
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
サブプール#n
サーバプロセスA
サーバプロセスB
サーバプロセスC
…
サブプール分割あり
サブプール毎(※1)に 1つのラッチで保護
最大で7個のラッチで 共有プール全体を保護
(※1)存続期間毎に 分割された従属ヒープ(sga heap)単位でラッチが対応づくわけではない
ラッチ競合を低減しパフォーマンスを向上するためにサブプール分割を導入
shared pool latch
shared pool latch
shared pool latch
メモリを獲得する際は、使用するサブプールをラウンドロビン方式で選択
共有プールの基本的理解(4/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 96
• サブプール分割
• 目的:共有プールを保護するラッチ(shared pool latch)の競合分散のため
• CPU数と共有プールのサイズに応じて最大7個に分割
• 存続期間による分割
• 目的:断片化を予防するため
• メモリの存続期間に応じてサブプール毎に4個に分割
共有プールの内部構造
共有プール
sga heap(1,0)
sga heap(1,1)
sga heap(1,2)
sga heap(1,3)
サブプール#1
存続期間長い
……….
存続期間短い
sga heap(2,0)
sga heap(2,1)
sga heap(2,2)
sga heap(2,3)
サブプール#2
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
サブプール#n
Oracle DatabaseではSGAやPGA等の多くのメモリ領域
を「ヒープ」と呼ばれる共通の構造で管理している。
共有プールは複数の従属ヒープ「sga heap(x,y)」で構成される。最大で 28個に分割される。
【例】
SQL領域
親/子カーソルLibrary Cache
永続メモリ領域
共有プールの基本的理解(5/16) KROWN#147122
KROWN#147171
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 97
• サブプールの数は以下の初期化パラメータ値によって決定される • CPU_COUNT (CPU 数)/SHARED_POOL_SIZE/SGA_TARGET/MEMORY_TARGET/MEMORY_MAX_TARGET
• 構成変更する際はサブプール毎のサイズに注意
• CPUを増設する際/共有プールのサイズを変更する際
サブプールの数と構成変更時の注意事項
【共有プールの分割数(11gR2の計算式)】
KROWN#147122 CPU 数、共有プールサイズによる共有プールの分割について
共有プールの分割数 = min( min( A, max( B , C )), 7 )
A = trunc((( CPU_COUNT - 1 ) / 4) + 1 )
B = trunc( SHARED_POOL_SIZE / 512M )
C = trunc(( SGA_TARGET / 2 ) / 512M )
前提:
MEMORY_TARGET を設定していない、または、0 に設定しており、かつ、SGA_TARGET > 0 を設定している場合
構成変更により、サブプール1つあたりのサイズが変化することがあるので注意
(特に小さくなった場合に、領域枯渇のリスクが高まるため注意)
共有プールの基本的理解(6/16) KROWN#147122
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 98
共有プールへの新規メモリ割当ての流れ
1.フリーリストから空きを探す
フリーリストは各従属ヒープ sga heap(x,y) 毎に存在
4.使用済み領域を再利用(LRUリストをフラッシュ&チャンクを連結して空きを作る)
2.Reserved Granule (未割当ての領域)から確保
5.共有プールを拡張(IMMEDIATEモードでバッファキャッシュから空きを確保)
6.ORA-4031エラー(要求サイズのメモリが割り当てられない)
3.予約済みプールから確保(条件があえば)
共有プールの基本的理解(7/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 99
• Reserved Granule
• インスタンス起動直後等に存在するグラニュル全体がまだ未使用の領域
• V$SGASTAT の「free memory」は Reserved Granule を含む
空き領域:Reserved Granule
……….
サブプール#2 サブプール#1 Reserved Granule サブプール#n
インスタンス起動直後
……….
サブプール#2 サブプール#1 Reserved Granule サブプール#n
追加 追加
Reserved Granule 使用後
各サブプール内の空きが不足すると Reserved Granule から割り当てられる。
Reserved Granule からの割当ての結果、サブプール間で偏りが生じることがある
Reserved Granuleのサイズは以下で確認可能
SELECT KSMSSLEN "SIZE" FROM X$KSMSS WHERE KSMSSNAM = 'free memory' AND KSMDSIDX = 0;
Reserved Granule が全て各サブプールに割り当てられた後は、各サブプール内の空き領域が再利用される
共有プールの基本的理解(8/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 100
• 予約済みプールは共有プールの一部
• サイズ:shared_pool_reserved_size にて指定 (デフォルト:共有プールのサイズの5%)
• 要求サイズが閾値(11gR2ではSGAのグラニュル・サイズの約1/2以上)を
超えた場合にのみ使用される
• 他の領域の使用状況が逼迫していても予約済み領域は使用されていないことがある
(領域が有効活用されていない場合があるので注意)
予約済みプール
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
予約済みプール領域
予約済みプール領域
空き(予約済みプール領域)
サブプール#n
共有プール内の各サブプール、 従属ヒープ「sga heap(x,y)」から 分散して予約済みプールとしての チャンクが獲得される
共有プールの基本的理解(9/16) KROWN# 44353
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 101
• 空き領域は各従属ヒープ毎に個別に管理/使用される
• 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも
他のサブプールや従属ヒープの空きメモリは使用されない
空き領域:分割された各サブプール/従属ヒープ内の空き領域の管理
sga heap(1,0)
sga heap(1,1)
sga heap(1,2)
sga heap(1,3)
サブプール#1 サブプール#2
FREE
sga heap(2,0)
sga heap(2,1)
sga heap(2,2)
sga heap(2,3)
空き領域不足 融通不可
FREE
FREE
FREE
FREE
FREE
FREE
【フリーリスト】
各従属ヒープ毎に管理
(予約済みフリーリストも同様)
【LRUリスト】
各サブプール毎に管理
LRUリストからフラッシュ(解放)した領域(空き領域(FREEチャンク))は、それぞれの従属ヒープのフリーリストに戻される
例えば、「sga heap(1,3)」の空きを作るためにLRUフラッシュが発生した際、LRUスキャン中に「sga heap(1,2)」の解放可能なチャンクを見つけた場合は、そのチャンクは「sga heap(1,2)」のフリーリストにリンクされる
共有プールの基本的理解(10/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 102
• バッファキャッシュ
• 共有プールが不足すると、バッファキャッシュを減らして共有プールを拡張する (自動調整はグラニュル単位)
• DEFERREDモード(遅延要求) と、IMMEDIATEモード(即時要求)がある
空き領域:共有プールの空き領域予備軍
SGA_ TARGET
共有プール
バッファキャッシュ
ログバッファ、その他
最低値(shared_pool_size)
最低値(db_cache_size)
他コンポーネントが不足した場合の拡張余力
バッファキャッシュから共有プールにメモリを移動可能な領域
DEFERREDモード: (自動SGA管理、自動メモリ管理) 定期取得した統計情報に基づいて行う
IMMEDIATEモード: (手動SGA管理、自動SGA管理、自動メモリ管理) 拡張を行わないとORA-4031が発生する状況に 陥った場合に行う
共有プールの基本的理解(11/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 103
各空き領域の消費推移
共有プールの空きの量
Reserved Granule を全て使用完了
時間
予約済みプールの空きは、実際は 有効利用されていない場合がある
V$SGASTAT の「free memory」( 空き領域)のみでは、どのサブプールの 空きか判断できない
共有プールの空きのみの監視では不十分
断片化が進行すると、再利用できない空き領域(小さい空き領域)が徐々に増加し、空き領域が右肩上がりに増加する場合もある
予約済みプールは、大きなサイズの割当てがない限り利用されない
V$SGASTAT の[shared_pool].[free memory]で確認できる空き
インスタンス起動直後
空き
予約済みプールの空き
共有プールの基本的理解(12/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 104
• ORA-4031の発生ケース
• 連続した空き領域を確保できない場合に発生するエラー
• 従来からの代表的な発生例は、サイズが小さい、断片化によるもの
• 昨今のメモリ低コスト化、大規模化によって、余裕を持った共有プールのサイジングが可能となり、共有プール全体のサイズが小さいことが原因でORA-4031が発生するという事例は比較的減少傾向(総量は足りているケースが多い)
メモリ割当てエラー(ORA-4031)
sga heap(x,y)
A: 空き B: 使用中 C: 空き
D:割当て要求
要求したメモリサイズ分の連続した空き領域を確保できない場合には ORA-4031 が発生
ORA-4031
共有プールの基本的理解(13/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 105
最近のORA-4031の傾向
最近の発生パターン 実例
サブプール間の偏り 特定の機能に依存した処理の大量使用により、一部のサブプールが肥大化し、他のサブプールへの割り当てが失敗(他のサブプールのサイズ(空き領域)が小さくなったため)
従属ヒープ(存続期間による分割)間の偏り リテラルSQLを多く使用した環境において、共有SQL領域(sga heap(n,3))が肥大化した結果、存続期間が長い従属ヒープ(sga heap(n,1))への割り当てが失敗
共有プールの拡張余力がない
(共有プール拡張時の供給元の
バッファキャッシュの余力がない)
バッファキャッシュ最低サイズ(db_cache_size)の設定不備
(不必要に大きく設定されていた)により、共有プールの自動拡張ができず、割り当てが失敗
共有プールの空き領域監視のみでは検知できない
共有プールの基本的理解(14/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 106
• サイズ (shared_pool_size) の設定
• サブプールあたりのサイズを勘案して初期設計を検討するとよい
• 大きければ大きいほどよいという領域ではない (shared pool latch 待ち注意)
共有プールのサイズの考え方
サブプール#n
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
FREE
FREE
FREE
LRUリスト FREE
sga heap(n,0)
sga heap(n,1)
sga heap(n,2)
sga heap(n,3)
サブプール#n
LRUリスト
FREE
FREE
FREE
FREE
サイズが小さいケース サイズが大きいケース
共有プールのサイズが小さ過ぎると、メモリ枯渇(ORA-4031エラー)が発生しやすくなる
共有プールのサイズが大き過ぎると、空き領域を探す際のリストが長くなり shared pool latch 競合が発生しやすくなる
共有プールの基本的理解(15/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 107
• 共有プールの構造
• 最大で28個に分割される(サブプール分割/存続期間による分割)
• サブプール間での偏りが生じる場合がある
• 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも
他のサブプールや従属ヒープの空きメモリは使用されない
まとめ
テストに完全な網羅性がないリスクは、拡張余力のリアルタイム監視で担保
共有プールの空き領域監視のみでは空きの枯渇は検知できない
共有プールの基本的理解(16/16)
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
設計~テスト~運用フェーズ
での検討事項
2.一次サイジング(自動SGA前提) • 主要チャンクのサイズを意識した一次サイジング
• 共有プール自動拡張余力の確保
3.監視・チューニング(自動SGA前提) • テスト・運用フェーズの監視
• チューニング(二次サイジング)
1.管理方式選定 • 手動SGA管理、自動SGA管理、自動メモリ管理の選択
設計 テスト・運用
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 109
共有プール(SGA)管理方式比較
1.管理方式選定
比較項目 手動SGA管理 自動SGA管理(10gR1~) 自動メモリ管理(11gR1~)
概要
・SGAの各SGAコンポーネント(バッファキャッシュ、共有プール、ラージプールなど)のサイズを個別に設定する
・SGA全体のサイズを設定し、各SGAコンポーネント(バッファキャッシュ、共有プール、ラージプールなど)のサイズは、必要に応じて動的に調整される
・SGAとPGAの合計サイズを設定し、PGAと各SGAコンポーネント(バッファキャッシュ、共有プール、ラージプールなど)のサイズは、必要に応じて動的に調整される
特徴
・各コンポーネントの精緻なサイジングが必要
・手動SGA管理でも、共有プールが不足した場合は、IMMEDIATE
モードで、バッファキャッシュを縮小し、動的に共有プールが拡張される(11gR2~)
(KROWN#151272)
・一次サイジングが比較的容易
・各SGAコンポーネントの最低サイ
ズを設定可能
・11gR2では広く採用されている
・一次サイジングが比較的容易
・PGA、各SGAコンポーネントの最
低サイズを設定可能
・LinuxではHugepageとの併用ができない
・PGAのサイズ変動により、同じ処理の性能が変わる可能性あり
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 110
• 自動SGA管理 ⇒ 95%以上の採用率、推奨設定
• 11gR2では、経験則的に95%以上のシステムで、広く一般的に採用されており日本オラクルコンサルが支援する場合に、初めに検討する方式
• 手動SGA管理 ⇒ 数%程度の採用率
• 旧バージョンからの移行のお客様以外、新規に採用するケースはほとんどない
• 自動メモリ管理 ⇒ 数%程度の採用率
• 中~大規模なシステムでもOSとしてLinuxが選定されることが多くなってきておりHugepageと併用できないため、積極的に採用されるに至っていない
手動SGA管理、自動SGA管理、自動メモリ管理の採用率 ※ 日本オラクルでコンサル支援することが多い中~大規模のシステムでの経験値
1.管理方式選定
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
設計~テスト~運用フェーズ
での検討事項
2.一次サイジング(自動SGA前提) • 主要チャンクのサイズを意識した一次サイジング
• 共有プール自動拡張余力の確保
3.監視・チューニング(自動SGA前提) • テスト・運用フェーズの監視
• チューニング(二次サイジング)
1.管理方式選定 • 手動SGA管理、自動SGA管理、自動メモリ管理の選択
設計 テスト・運用
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 112
• 初期設定値計算イメージ
• 共有プールに占める主要なチャンク領域を見積もる • バッファキャッシュ依存領域
• バッファキャッシュのブロック数に応じて計算する
• 共有SQL領域
• 経験則的に十分なサイズを確保する
• 各種可変領域
• サブプール数に応じて一次サイジングする
• 3つの領域の合計に余裕率を掛けて計算する
共有プールを3つの領域に分割して一次サイジング
shared_pool_size初期設定値 =
バッファキャッシュ依存領域(固定領域)
+ 共有SQL領域(可変領域)
+ 各種可変領域(可変領域)
1.2倍 (余裕率) X
2.一次サイジング 共有プール
#1
#2
#n
・・・・・
共有SQL領域
バッファキャッシュ依存領域
(計算式により固定値算出)
各種可変領域
(サブプール数分)
サブプール
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 113
• db_block_hash_buckets
• バッファキャッシュを管理するハッシュ・バケットの領域がキャッシュされる
• バッファキャッシュのブロック数に比例して大きくなり、大規模なバッファキャッシュを確保するシステムでは、共有プールのサイジングに注意が必要
• サイズ見積もり(11gR2の場合)
• バッファキャッシュ1GBにつき15MBで計算
※ 11gR2の実績から導出した参考値。実機確認の上、調整する。
※ db_block_size=8KBの前提
バッファキャッシュ依存領域(RAC/Single共通)
KROWN#129856 バッファ・キャッシュのサイズ変更時の注意点
固定領域 2.一次サイジング
KROWN#129856
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 114
• gcs resource/gcs shadow
• RACノード間で、バッファキャッシュ上のデータブロックの整合性を
管理するためのロック可能な実体
• gcs resource/gcs shadowはバッファキャッシュのブロック数に比例して大きくなり、大規模なバッファキャッシュ環境では、共有プールを圧迫する可能性あり
• サイズ見積もり(11gR2の場合)
• db_block_size=8Kでは、バッファキャッシュ1GBにつき45MBで計算
※ 11gR2で2~3ノード環境の実績から導出した参考値
gcs shadowはノード数によって異なりますので、実機確認の上、調整する
※ 原則的には起動時のサイズで固定的に確保されるが、DRM(Dynamic Resource
Mastering)などによるリソースマスタの偏りによって、変動する可能性あり
バッファキャッシュ依存領域(RACのみ)
固定領域 2.一次サイジング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 115
• SQLA(共有SQL領域(共有カーソル領域))
• SQLテキストや実行計画などがキャッシュされる
• SQLが十分に共有化されていれば節約できる
• リテラルSQLが多い、子カーソルが多く生成されるようなシステムで
肥大し易いため、大きく見積もる
共有SQL領域
可変領域
【SQLが十分に共有された状態】
下記2点をいずれも満たす:
SQLのヒット率(AWRの「Soft Parse %」)が95%以上
2回以上実行されたSQLの共有プール占有率 (AWRの「% SQL with executions>1」)が95%以上
【高SQLヒット率でもリテラルSQLが多い例】
・数種類の共有されたSQLを100万回実行
・リテラルSQLを1万回実行
⇒ SQLのヒット率99%
2.一次サイジング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 116
• 各種可変領域の机上見積もりは不可能
• 共有SQL以外の可変領域で、そのサイズは、使用する機能、
使い方、同時実行並列度に依存するため、見積もりは困難
• サブプール数から仮見積もりする
• サブプールあたりのサイズを十分に確保する
• CPU数が多い(サブプールが多い)システムでは、
処理の多様性が高くなり、より多くの領域が必要
• プール分割に起因する障害防止
各種可変領域
共有プール(2.1GB)
可変領域
#1
30
0M
【悪い例】
総量では2.1GBと大きいが、サブプールが小さいため、更に従属ヒープに分割され、ORA-4031が発生し易い
#7 3
00M
・・・・
サブプール
2.一次サイジング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 117
• db_cache_sizeとshared_pool_sizeには最低サイズを設定する
• [sga_target > 各SGAコンポーネント設定値の和]になるよう、
共有プールの拡張余力を十分に確保する
共有プール自動拡張余力の確保
SGA_ TARGET
共有プール
バッファキャッシュ
ログバッファ、その他
最低値(shared_pool_size)
最低値(db_cache_size)
初期サイジングでは、バッファキャッシュからの共有プール拡張余力を十分に確保して、テストに臨むことが重要
共有プールと同サイズ程度の拡張余力があれば、共有プールが自動拡張した後、対処の為の時間的猶予ができる
他コンポーネントが不足した
場合の拡張余力
2.一次サイジング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 118
• RAC環境の場合は、必要に応じて縮退運転時の余裕分を考慮する
• 完全にアプリケーションパーティショニングされているRAC環境では、縮退運転時に、生存ノードでは全く異なるタイプの処理を受け付けることになる
• 縮退運転のテストにて増加分を検討する
• 見積もりは困難であるため、縮退運転のテストにおいて、特定チャンクが過剰に増加していないか確認の上、共有プールのサイズ追加を検討する
RAC縮退運転時の考慮
【例】 ・ノード間で実行されているSQLが異なるため、縮退時のSQLAが増加 ・ノード間でアクセスするオブジェクトが異なるため、ディクショナリキャッシュが増加 ・ノード間で発生するロックの種類が異なるため、GES関連領域が増加
2.一次サイジング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
設計~テスト~運用フェーズ
での検討事項
2.一次サイジング(自動SGA前提) • 主要チャンクのサイズを意識した一次サイジング
• 共有プール自動拡張余力の確保
3.監視・チューニング(自動SGA前提) • テスト・運用フェーズの監視
• チューニング(二次サイジング)
1.管理方式選定 • 手動SGA管理、自動SGA管理、自動メモリ管理の選択
設計 テスト・運用
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 120
• 共有プールの監視
• 「共有プールの空き率監視」、
「チャンク別のサイズ遷移分析」 などが一般的
• 共有プールの空き率分析の問題点
• V$SGASTATの[shared pool].[free memory]には、
予約済プールが含まれるため、空きが枯渇することはほぼない
• 空きが少なくても、使用頻度の低いチャンクを再利用できていれば問題ない
• サブプール別、従属ヒープ別の空きは確認できない
• 断片化が進行すると、再利用可能な連続領域が減少し、
逆に空き率が上昇傾向を示すことがある
空き率分析の問題点 3.監視・チューニング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 121
• 共有プールに関するリアルタイム監視は①で実施する
• ②~⑥と高負荷の⑦は必要に応じて情報収集を検討する
推奨する共有プールの監視
◎:必須 ○:推奨 △:必要に応じて検討
No. 監視/分析の内容 監視/情報採取の方法 種別 テスト
フェーズ
運用
フェーズ
① 共有プール拡張余力の監視 V$SGA_DYNAMIC_COMPONENTSによる自動拡張余力の監視
リアル監視 ○ ◎
② 共有プールのサイズ遷移の傾向分析
AWRレポートの「Memory Dynamic Components」セクション参照
情報取得 ◎ ◎
③ チャンク別サイズ遷移の傾向分析
AWRレポートの「SGA breakdown difference」セクション参照
情報取得 ◎ ○
④ サブプール別の偏り傾向分析 X$KSMSSのロギング 情報取得 ◎ ○
⑤ 予約済みプールの傾向分析 V$SHARED_POOL_RESERVEDのロギング 情報取得 ◎ ○
⑥ 巨大SQLを検知する Memory Notificationの閾値変更(50MB⇒2MB、等) 情報取得 ○ △
⑦ 従属ヒープ別の偏り傾向分析 X$KSMSPのロギング(※latchを掴むため高負荷) 情報取得 △ △
3.監視・チューニング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 122
• 自動SGA管理の設計指針として重要なのは、
「共有プールの拡張余力を十分に残す」こと
• インスタンスの再起動を頻繁にできない環境では、
早めに検知できる閾値を設定する
• 監視間隔は30分~
60分間隔程度で十分
①共有プール拡張余力の監視(リアルタイム監視)(1)
共有プールの拡張余力を監視する
運用 ◎
テスト ○
拡張余力が十分に確保されていることを監視する
3.監視・チューニング
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 123
• V$SGA_DYNAMIC_COMPONENTSによる拡張余力の監視
• バッファキャッシュの【現在値(CURRENT_SIZE)】-【初期設定値(USER_SPECIFIED_SIZE)】に十分余裕があることを確認
• バッファキャッシュの「現在値」から「初期設定値」を引いた数値が共有プールの自動拡張余力と言える
①共有プール拡張余力の監視(リアルタイム監視)(2)
【例】「2GB」のdb_cache_sizeを設定したが、現在は「4G程」(4,385,875,968byte) であり、
共有プールが不足した場合、「2G程」(2,238,392,320byte) の拡張余力がある
SELECT USER_SPECIFIED_SIZE,CURRENT_SIZE, CURRENT_SIZE - USER_SPECIFIED_SIZE SIZE_DIFFERENCE FROM V$SGA_DYNAMIC_COMPONENTS WHERE COMPONENT = 'DEFAULT buffer cache';
USER_SPECIFIED_SIZE CURRENT_SIZE SIZE_DIFFERENCE ------------------- ---------------- ---------------- 2,147,483,648 4,385,875,968 2,238,392,320
3.監視・チューニング 運用 ◎
テスト ○
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 124
• 共有プールが自動拡張機能で拡張を続けていないか確認
• IMMEDIATEモードや、DEFERREDモードによる自動拡張が頻発していない
(各コンポーネントのサイズが安定推移している)ことを確認する
• 共有プールが拡張し続けるような傾向にあれば、
①の監視閾値を越える前に、対策をする必要がある
• 処理特性が同じ時間帯に、共有プールとバッファキャッシュの間で、
短時間に頻繁に奪い合いが発生(増減を繰り返す)していたら、
SGAが不足していると考えられる
②共有プールのサイズ遷移の傾向分析(情報取得)(1)
【対処】
・③の分析で特定チャンクの過剰消費があれば原因を分析する
・sga_target/shared_pool_sizeを見直す
3.監視・チューニング 運用 ◎
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 125
• SGAコンポーネントのサイズ遷移を確認する
• AWRレポートの「Memory Dynamic Components」セクションの時系列データ
• 定期取得したV$SGA_DYNAMIC_COMPONENTS
(①のリアルタイム監視と情報ソースは同じ)
②共有プールのサイズ遷移の傾向分析(情報取得)(2)
0
10,000
20,000
30,000
40,000
50,000
60,000
20
12
/9/2
5 0
0:0
0:1
3
20
12
/9/2
5 0
1:0
0:0
0
20
12
/9/2
5 0
2:0
0:0
9
20
12
/9/2
5 0
3:0
0:1
0
20
12
/9/2
5 0
4:0
0:1
0
20
12
/9/2
5 0
5:0
0:3
4
20
12
/9/2
5 0
6:0
0:1
1
20
12
/9/2
5 0
7:0
0:3
9
20
12
/9/2
5 0
8:0
0:0
7
20
12
/9/2
5 0
9:0
0:1
4
20
12
/9/2
5 1
0:0
0:1
1
20
12
/9/2
5 1
1:0
0:2
0
20
12
/9/2
5 1
2:0
0:2
0
20
12
/9/2
5 1
3:0
0:2
6
20
12
/9/2
5 1
4:0
0:4
7
20
12
/9/2
5 1
5:0
0:0
4
20
12
/9/2
5 1
6:0
0:0
6
20
12
/9/2
5 1
7:0
0:2
8
20
12
/9/2
5 1
8:0
0:1
3
20
12
/9/2
5 1
9:0
0:2
9
20
12
/9/2
5 2
0:0
0:0
3
20
12
/9/2
5 2
1:0
0:1
4
20
12
/9/2
5 2
2:0
0:2
4
20
12
/9/2
5 2
3:0
0:1
0
MB
Memory Dynamic Components
streams pool
shared pool
Shared IO Pool
large pool
java pool
DEFAULT buffer
shared poolの拡張が続いている
0
50,000
100,000
150,000
200,000
250,000
300,000
350,000
400,000
450,000
500,000
20
12
/9/2
5 0
0:0
0:1
3
20
12
/9/2
5 0
1:0
0:0
0
20
12
/9/2
5 0
2:0
0:0
9
20
12
/9/2
5 0
3:0
0:1
0
20
12
/9/2
5 0
4:0
0:1
0
20
12
/9/2
5 0
5:0
0:3
4
20
12
/9/2
5 0
6:0
0:1
1
20
12
/9/2
5 0
7:0
0:3
9
20
12
/9/2
5 0
8:0
0:0
7
20
12
/9/2
5 0
9:0
0:1
4
20
12
/9/2
5 1
0:0
0:1
1
20
12
/9/2
5 1
1:0
0:2
0
20
12
/9/2
5 1
2:0
0:2
0
20
12
/9/2
5 1
3:0
0:2
6
20
12
/9/2
5 1
4:0
0:4
7
20
12
/9/2
5 1
5:0
0:0
4
20
12
/9/2
5 1
6:0
0:0
6
20
12
/9/2
5 1
7:0
0:2
8
20
12
/9/2
5 1
8:0
0:1
3
20
12
/9/2
5 1
9:0
0:2
9
20
12
/9/2
5 2
0:0
0:0
3
20
12
/9/2
5 2
1:0
0:1
4
20
12
/9/2
5 2
2:0
0:2
4
20
12
/9/2
5 2
3:0
0:1
0
MB
Memory Dynamic Components
streams pool
shared pool
Shared IO Pool
large pool
java pool
DEFAULT buffer
shared poolとdb cacheの 奪い合いが続いている
3.監視・チューニング 運用 ◎
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 126
• 性能テスト・本番運用開始時の注意
• テスト、運用開始時点で、共有プールの拡張余力が十分残っていることを
AWRやV$SGASTATなどで確認すること
• テストデータの作成、大量オブジェクトのコンパイル、移行データの作成などで、実運用時と異なる用途の領域により共有プールが自動拡張している場合がある
②共有プールのサイズ遷移の傾向分析(情報取得)(3)
時間経過
SGA_ TARGET
6 G B
バッファキャッシュ初期値(最低値):2GB
共有プール初期値(最低値): 2GB
テスト運用開始時点で、共有プールの拡張余力がなくなっている
×テスト・運用開始 ○テスト・運用開始
3.監視・チューニング 運用 ◎
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 127
• 共有プールのチャンクサイズの推移を確認する
• 空き領域と、先に上げた、共有SQL領域、RAC依存領域など
重要なチャンクを中心に、サイズの推移を確認する
• 各チャンクサイズが安定的に推移しているか、
特定チャンクが増加し続ける傾向がないか確認する
• 空き領域の大小をそれほど注目して見る必要はない
③チャンク別サイズ遷移の傾向分析(情報取得)(1)
3.監視・チューニング 運用 ○
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 128
• AWRレポートの「SGA breakdown difference」より時系列にグラフ化
• 定期的取得したV$SGASTATより時系列にグラフ化
③チャンク別サイズ遷移の傾向分析(情報取得)(2)
特定のチャンクが肥大し続けることなく安定推移
3.監視・チューニング 運用 ○
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 129
• サブプール間の偏りを確認する
• 共有プール全体として空きがあっても、特定のサブプールの肥大により
ORA-4031が発生することがある
• リアルタイム監視は不要だが、テストの時や、
新規アプリリリース後の本番環境などで、特定の
サブプールに偏りがないか確認し、極端な偏りは、
原因を明らかにする
④サブプール別の偏り傾向分析(情報取得)(1)
【偏りが見つかった場合の対処】
• 偏りの原因を分析する
• sga_target/shared_pool_sizeを見直し、 各サブプールが十分大きくなるように調整する (サブプール別の割り当てサイズは手動制御できないため)
共有プール(2.4GB)
#1 3
00M
【悪い例】
サブプール#2に割り当てが極端に偏っている
サブプール
#2
1500M
#3
30
0M
#4
30
0M
3.監視・チューニング 運用 ○
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 130
• X$KSMSS(V$SGASTATの元表)で、サブプール別のサイズと空きを確認
④サブプール別の偏り傾向分析(情報取得)(2)
【例】 SELECT KSMDSIDX SUBPOOL#,DECODE(KSMSSNAM,'free memory','free memory','used memory') TYPE,SUM(KSMSSLEN) BYTES FROM X$KSMSS GROUP BY KSMDSIDX,decode(KSMSSNAM,'free memory','free memory','used memory') ORDER BY KSMDSIDX,decode(KSMSSNAM,'free memory','free memory','used memory'); SUBPOOL# TYPE BYTES ---------- ----------- ------------ 0 free memory 0 0 used memory 0 1 free memory 52,393,584 1 used memory 232,819,088 2 free memory 53,940,240 2 used memory 231,272,432 3 free memory 46,664,144 3 used memory 221,771,312 4 free memory 60,816,984 4 used memory 190,841,256
Reserved Granuleの空きは
すでに枯渇
4つのサブプールに分割されており、ほぼ均等に割り当てられている
偏りがある場合は、DECODEとSUM()を外して、何のチャンクが偏っているか確認する
3.監視・チューニング 運用 ○
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 131
• 予約済みプールの空き領域確認
• V$SGASTAT.[shared_pool].[free memory]の値には、予約済みプールの
空きが含まれており、要求サイズが小さい場合は使える領域ではない
• V$SHARED_POOL_RESERVED.USED_SPACEとFREE_SPACEで、共有プール全体に占める、予約済みプールの使用サイズ、空きサイズを確認する
• 予約済みプールとして割り当てられる、デフォルトのshared_pool_size x 5%がどの程度消費されているか確認する
⑤予約済みプールの傾向分析
【対処】
•予約済みプールがほとんど使用されていない場合は、予約済みプールのサイズ(SHARED_POOL_RESERVED_SIZE)を小さくし、非予約済みプールに割り当てたほうが有効
•予約済みプールの空きが枯渇している場合は、 SGAのグラニュル・サイズの1/2以上のチャンクが 頻繁に割り当てられる原因を調査した上で、必要に応じて、共有プールの拡張を検討する
3.監視・チューニング 運用 ○
テスト ◎
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 132
• Memory Notificationで巨大SQLを検知する
• Memory Notification(_kgl_large_heap_warning_threshold)は一定サイズ以上のSQLが実行されたことを、アラート・ログにメッセージ出力する機能
• テストで閾値を小さめに設定しておくことにより、極端に大きなSQLを検知し、
事前に対処することが可能
• 10.2.0.2以降は50MB以上のSQLが実行されると、メッセージ出力
⑥巨大SQLを検知する(情報取得)
KROWN#109941
「アラート・ログにライブラリ・キャッシュ・オブジェクトの SGA への割り当てに関するメッセージが出力される」
【アラート・ログメッセージ例】
Wed Dec 26 12:38:02 2012
Memory Notification: Library Cache Object loaded into SGAHeap size 1018K exceeds notification threshold (70K) Details in trace file D:¥APP¥diag¥rdbms¥orcl¥trace¥orcl_ora_2352.trc KGL object name :SELECT /* Test SQL */ COL01 , COL02 , COL03FROM TAB01 , TAB02 , TAB03 WHERE
3.監視・チューニング 運用 △
テスト ○
KROWN#109941
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 133
• X$KSMSPで、従属ヒープ別のサイズと空きを確認
• 検索時にshared pool latchを取得し負荷が高いため、
本番環境や性能テスト中の採取は推奨しない
• 従属ヒープの肥大や、断片化状態を分析するなど、
個別の障害分析目的で取得することが多い
• 性能・負荷テスト終了後や、本番のオンライン終了後、バッチ終了後のような
処理の切れ目で情報取得しておくと、ORA-4031の分析に役立つ場合がある
⑦従属ヒープ別の偏り傾向分析(情報取得)
KROWN#19607
ライブラリ・キャッシュのメモリ使用状況確認スクリプト
KROWN#132267
X$ 表から分割された共有プールの各プールごとの使用状況を確認する方法
3.監視・チューニング 運用 △
テスト △
KROWN#19607
KROWN#132267
Copyright© 2014, Oracle and/or its affiliates. All rights reserved. 134
共有プールのサイジング、テスト、運用の重要ポイント
② 大規模バッファキャッシュ環境(特にRAC環境)では、バッファキャッシュ依存領域を上乗せしてサイジングする
④ 共有プールの自動拡張余力を残して、バッファキャッシュの最低サイズを設定する
⑤ 共有プールの自動拡張余力が残っていることをリアルタイム監視する
③ 1サブプールあたりのサイズを十分に大きくサイジングする
① 自動SGA管理の使用を推奨
ORA-4031撲滅
まとめ
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
目的とゴール
135
• SQLチューニングにおける様々な「戦術」をつかむ
• 「予測(Estimate)」と「実測(Actual)」の乖離を捉える補正する
• ORA-4031撲滅
• 共有プールの性質の理解
• メモリ設計・監視のポイント
目的
SQLチューニングで有効となるテクニックとメモリ障害の予防を知る
ゴール
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.
Copyright© 2014, Oracle and/or its affiliates. All rights reserved.