SQLチューニング＆メモリチューニングに必要な考 …...2014/03/12 · Cardinality Feedback, 等) ・適切な索引・ヒストグラム・拡張統計・ヒント

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チューニングで有効となるテクニックとメモリ障害の予防を知る

ゴール


本セミナーの内容に関する注意

• 本資料の内容

• 製品仕様に関する正式な情報ではなく、プロジェクトで調査を行い把握した内容を記載

• プロジェクトで得られた経験を基にした、具体的な一次サイジングの指針および値

• 実際には、必要領域は処理内容や処理タイミングに依存するため、

テストによりサイズを検討ください

• 前提環境

• Oracle Database 11g Release2

• 自動SGA管理

4


Program Agenda

SQLと云う言語の特徴

「予測」と「実測」の乖離を補正せよ！

• Oracle Databaseの機能を活用した最新テクニック

共有プールの基本的理解

設計～テスト～運用フェーズでの検討事項

• 管理方式選定

• 一次サイジング（自動SGA前提）

• 監視・チューニング（自動SGA前提）


SQLと云う言語の特徴について


SQLという言語の特徴（1）

• SQLと云う言語は、過去を振り返ってみても

最も成功した言語／標準規格の一つ

• 何故成功したのか？

• それはどうやって(How)データを抽出するかを書かずに、

何を（What）抽出するかという“条件”のみを記述する仕様

• 多くの言語では、繰り返し（for～）や条件分岐（if～）などの

アルゴリズムを記述する必要がある

• アルゴリズムを書かない(※書く必要が無い)のが、

SQLと云う言語の最大の特徴

7


SQLという言語の特徴（2）

• どうやって（How）データを抽出するか、即ちアルゴリズムの

決定・制御は、RDBMS のオプティマイザで行われる

• オプティマイザが決定したアルゴリズム＝実行計画

• オプティマイザはSQLテキストや統計情報などを基に、

適切な実行計画を予測して組み立てる

8

プログラム

“条件”のみを記述

Op

timiz

er SQL データ

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


アルゴリズムを書かないことによるメリット

• アルゴリズムを書かないことによる最大のメリット

言語の習得が「簡単」

• エンジニアではない現場のお客様でも、

SQLなら書くことは可能

• 習得が簡単ということは、生産性の高さ＝コスト削減にも繋がっている

• エンジニアの確保が容易

• 一般的にアプリケーション作成の工数も少なく済む

9


アルゴリズムを書かないことによるデメリット

• アルゴリズムを書かないことによる最大のデメリット

「性能」に関する問題が出やすい

• 適切ではないアルゴリズム(実行計画)による、著しい性能劣化

• アルゴリズム(実行計画)変動に伴う、性能変動(劣化)

• SQLを使うユーザ(開発者)は、性能が悪くなり易い良くない実行計画と

なるSQLも書くことができる

• 多くのユーザは必要なデータが抽出できれば良く、実行計画など気にしない

• 一部ユーザが無意識に強烈な実行計画のSQLをリリースすることもある

10


参考：某チューニング案件の超巨大SQL実行計画

• SQLテキストで6700行以上、40表以上を結合したSELECT文の実行計画

• 実行計画のステップ数換算で、実に500ステップ以上の超巨大SQL

11

…(中略)…


振り返ってもう一度このスライド






12

プログラム


Op

timiz

er SQL データ



本セクションのキーワードの一つ：「予測」






13

プログラム


Op

timiz

er SQL データ


ココ!


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

• SQL のアルゴリズム≒実行計画は、オプティマイザが

最適と考えられるものを「予測」して組み立てる

• そして「予測」である以上、必ずハズレのケースがある

• ハズレの実行計画の場合、性能問題として顕在化！

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

• 各ベンダやオープンソースのRDBMSは、このSQLの本質的な困難に

立ち向かうべく、日々凌ぎを削っている(もちろんOracleも！)

• まずこのハズレの実行計画の存在を意識／認識しておくのが、

SQLチューニングの出発点

14


「全体最適」と「個別最適」の使い分け

• SQLチューニングの手法は、全体最適にマッチする手法と、

個別最適に適した手法の２つに大別

• 全体最適にマッチする手法の例

• 適切なSQL(SQLコーディング・ガイド、コード・インスペクション、等)

• 適切な統計(常時最新化されたフレッシュな統計、最大件数想定の固定値、等)

• 適切な索引(一意キー索引、追加索引、等)

• 実行計画最適化機能(BindPeek, Dynamic Sampling, Cardinality Feedback等)

• 個別最適にマッチする手法の例

• ヒント

• SQL計画管理(SPM/11gR1以降)、アウトライン(10gR2以前)

• SQLプロファイル

15


「全体最適」と「個別最適」の適用イメージ(1)

16

SQLの重要度

処理時間短

長

低高

全体最適

個別最適



17

SQLの重要度

処理時間短

長

低高

全体最適

個別最適・適切な統計

・適切なSQL

・実行計画最適化機能 (Bind Peek,

Dynamic Sampling,

Cardinality Feedback, 等)

・適切な索引・ヒストグラム

・拡張統計

・ヒント

・SPM(or アウトライン)

・SQLプロファイル



18

SQLの重要度

処理時間短

長

低高

全体最適

個別最適・適切な統計

・適切なSQL

・実行計画最適化機能 (Bind Peek,

Dynamic Sampling,

Cardinality Feedback, 等)

・適切な索引・ヒストグラム

・拡張統計

・ヒント

・SPM(or アウトライン)

・SQLプロファイル

序

終

まず初めは全体最適な手法で、実行計画全体の予測精度を上げる！



19

SQLの重要度

処理時間短

長

低高

全体最適

個別最適

予測精度向上でハズレの実行計画を引くリスクを低減し、個別最適の範囲を

極小化する！と云う設計思想


「全体最適」のち「個別最適」の考え方

• まずは「全体最適」の設計思想で、実行計画全体の

予測精度を向上させることが必要

• 「個別最適」の必要性は無くなるわけではない

• 何故か？

• ハズレの実行計画の存在が理由

• SQLの仕組み上、ハズレの実行計画は不可避であると云う認識が必要

• ハズレの実行計画は有るものとして、「個別最適」でチューニングする

• これ以降「個別最適」のチューニングで有効なテクニックを紹介

20


「予測」と「実測」の乖離を補正せよ！ Oracle Databaseの機能を活用した

最新テクニック


SQLチューニングの流れ(1)

22

遅いSQLの特定(sql_id特定)

実行計画のボトルネック特定

目標達成!!

Tuning案① Tuning案② Tuning案③ Tuning案④

KROWN#141864



23



目標達成!!


Oracle Database の機能を利用した、ボトルネック特定方法を紹介

• DBMS_XPLAN.DISPLAY_CURSOR で実行統計を出力する方法（参考KROWN#141531)

• DBMS_SQLTUNE.REPORT_SQL_MONITOR によるリアルタイム監視SQLのレポーティング

KROWN#141531



24



目標達成!!


複数のチューニング案を疑似ワークショップ形式

で紹介

• 複数のチューニング案を覚えて、引き出しを増やす

• チューニングの引き出しを増やすことが、上級者への近道！


DBMS_XPLAN と

DBMS_SQLTUNE による



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


DBMS_XPLAN.DISPLAY_CURSOR の制限事項

• 10gR1以降の機能

• ALLSTATS書式を有効化する場合

• 下記の「どちらか」を満たして、実行統計が採取される状態で SQL を実行する

• 初期化パラメータ「STATISTICS_LEVEL = ALL」を設定

※セッション単位(ALTER SESSION～)でも設定可能

• SQL に /*+ gather_plan_statistics */ヒントを付与

• 対象SQLが終了すると、実行統計が共有プールのカーソルに反映

• SQLが完全に終了するか、Ctrl+C等で強制終了

• 強制終了させた場合は、強制終了時点までの実行統計が反映

• SQL終了前に実行計画を出力しても、実行統計は出ない

27


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 |…| ---------------------------------------------------------------------------------------------------------------------- ：


DBMS_XPLAN.DISPLAY_CURSOR による解析(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 |…| ---------------------------------------------------------------------------------------------------------------------- ：

実行統計

ここが遅そう…



• 注目ポイント2

• 実行統計(Actual)と CBO予測(Estimate)の乖離に注目

30


CBOは2件アクセスと予測しているが、実際は54338件にアクセス

実行統計 CBO予測



• 前２ページの解析より、実行計画の Id 7 がボトルネックに

なっていると判断

31


・処理時間の実行統計(A-time)が多い。・処理件数のCBO予測(E-Rows)と実行統計(A-Rows)が乖離している。


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;


DBMS_SQLTUNE.REPORT_SQL_MONITORの制限事項

• 11gR1以降の機能

• DBMS_SQLTUNEパッケージを使用するためには

Enterprise Edition の Tuning Packオプションライセンスが必要

• リアルタイムSQL監視の対象となる(※V$SQL_MONITORビューに載る)ため下記の「どれか」が満たされる必要

• SQL の処理時間が５秒以上

• SQL に MONITORヒントを付与

• パラレル・クエリー

33


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 |…| | | ======================================================================================================================


DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(1) • 注目ポイント1…実行統計(SQLの「実際」の処理時間／処理件数)に注目

35



DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(2) • 注目ポイント2…実行統計(Actual)と CBO予測(Estimate)の乖離に注目

36


実行統計(待機イベント付き)

実行統計(トータル)

CBO予測

CBOは2M件アクセスと予測しているが、実際は980M件にアクセス


DBMS_SQLTUNE.REPORT_SQL_MONITORの解析(3) • 前２ページの解析より、実行計画の Id 8,9 がボトルネックと判断

37


・処理時間の実行統計(Activity Detail)が多い。・処理件数のCBO予測(Rows Estim)と実行統計(Rows Actual)が乖離している。


リアルタイムSQL監視による確認 • テキスト形式と同等の情報を、GUIのオペレーションで参照可能

38


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 でしか採取できない情報もある


疑似ワークショップによる

SQLチューニング案の紹介


疑似ワークショップの目的

• ワークショップの目的は SQLチューニングの

ネタ／引き出し(選択肢)を増やすこと

• 上級者への入り口

• チューニングのネタ／引き出しが増えれば、

目標到達への可能性が広がる

• 複数あるチューニング案の一部を紹介

• SQLチューニングを疑似体験して、引き出しを増やしましょう！

41


疑似ワークショップの課題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';


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


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 || ------------------------------------------------------------------------------------------------


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 || | | ===========================================================================================================


チューニング案の一覧 • 今回の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

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


案1. DBMS_STATSによる

統計情報採取


案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件



• DBMS_STATSパッケージで統計情報を採取

• 採取した統計を即座に使用(NO_INVALIDATE => FALSE)

• 4パラレルで採取(DEGREE => 4)

49

EXEC DBMS_STATS.GATHER_TABLE_STATS( USER , 'TEST_TABLE_A’ , NO_INVALIDATE => FALSE , DEGREE => 4);



• 統計情報採取後の実行統計

50



性能改善!


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


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



• CBO は統計情報を元に、最適な実行計画を予測して組み立てる

• テーブルの統計情報と実態(実件数)が合致しているか

どうかを、真っ先に確認

• 0件統計（←典型的なアンチパターン！)

• 0件では無いが、実態と乖離した統計

• 統計情報最新化で HASH JOIN の結合順序が入れ替わり、

一時表領域へのI/Oが無くなって性能が改善

53


案2. 拡張統計の採取


案2. 拡張統計の採取(1)

• 表の列(カラム)に関数を適用しているのは、

SQLのアンチパターンの一つ

• このパターンが性能劣化し易い理由は以下の２つに集約される

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関数を適用



• 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);



• 拡張統計(式統計)採取後の実行統計

57


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

性能改善!


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: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 | ----------------------------------------------------------------------------------------------------------


DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較案2. 拡張統計の採取(5)

• Before

• After


================================================================================================ | 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 | | ================================================================================================



• 今回のケースでは「式統計」を採取することで、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';

ここの式統計を採取


案3. SQLプロファイル適用

(by DBMS_SQLTUNE)


案3. SQLプロファイル適用(by DBMS_SQLTUNE)(1)

• SQLプロファイルは、DBMS_SQLTUNE の

チューニング・タスク実行によって作成／提案される

• リアルタイムSQL監視(REPORT_SQL_MONITOR) に並ぶ、

DBMS_SQLTUNEパッケージの有効な機能

• Enterprise Edition の Tuning Packオプションライセンスが必要

• 個別SQLのCBO予測(実行計画作成)を精緻化する

• 使いこなせれば、強力なSQLチューニング手段の一つ

62



• 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プロファイルが提案された場合)



• 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プロファイル適用後の統計



• SQLプロファイル適用後の実行統計

65


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プロファイルが使用されている


DBMS_XPLAN.DISPLAY_CURSOR結果の比較案3. SQLプロファイル適用(by DBMS_SQLTUNE)(5)

• Before

• After




DBMS_SQLTUNE.REPORT_SQL_MONITOR結果の比較案3. SQLプロファイル適用(by DBMS_SQLTUNE)(6)

• Before

• After


=========================================================================================================== | 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 | | | ===========================================================================================================



• SQLプロファイルの仕組みについて、マニュアル(※)を参照 • 17.5 SQLプロファイルの管理

SQLプロファイルには、個別の実行計画に関する情報は含まれません。オプティマイザには、計画を選択する際に、次の情報ソースがあります。

• データベース構成、バインド変数値、オプティマイザ統計、データ・セットなどを含む環境

• SQLプロファイルの補足的な統計情報

• SQLプロファイルの正体は、

「個別のSQLに特化した補助的なオプティマイザ統計」

• 個別SQLに対する詳細なダイナミック・サンプリングのようなもの

• サンプリング結果を実体として保持

• そのサンプリング結果が適用されると、CBO予測が精緻化されて実行計画が改善

• SPM やアウトラインのように、実行計画そのものを保持している訳ではない

※マニュアル … Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース2（11.2）B56312-01

68



• 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



• SQLプロファイルを作成／適用する環境は、「本番環境、又はそれに準じた量／質のデータが保持されている」必要がある

• この点を理解していれば、複雑なSQLを機械的に

チューニングできる、強力な武器となる

• 機械的なチューニングによる、時間短縮／必要スキル低減／コスト削減

• 本番環境⇔開発環境間の相互移行も可能

• 性能改善が100%保証される訳ではないので、

適用後の検証／評価は必要

70

※ 本番環境⇔開発環境間の移行方法

• Notes#457531.1 How to Move SQL Profiles from One Database to Another



• 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プロファイル適用前後の検証が完了している。



• Enterprise Managerからも作成／適用可能

72


案4. Cardinality Feedbackの使用


案4. Cardinality Feedbackの使用(1)

• Cardinality Feedback は、

CBOの実行計画予測精度を上げる機能の一つ

• 11gR2 で導入された新機能

• CBO予測と実行統計が乖離している際に、

２回目以降のSQL実行時に実行結果を Feedback して、

実行計画を作成し直す機能

• Feedback結果によりCBO予測が精緻化される

74

KROWN#147614 [11.2 新機能] オプティマイザ・フィードバック(カーディナリティ・フィードバック)

KROWN#147614



• 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



• Cardinality Feedback有効時の実行統計(2回目)

76


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

性能改善!


DBMS_XPLAN.DISPLAY_CURSOR結果の比較案4. Cardinality Feedbackの使用(4)

• Before

• After(2回目の実行計画)




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 | 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 | | ================================================================================================



• 今回のケースでは「Cardinality Feedback」により、

２回目のSQLでCBO予測の誤りが補正

• CBO予測の誤りが補正されたことで、より良い実行計画が選択

• CBOによる実行計画の予測精度を上げる働きを持つ機能

• BindPeek , Cardinality Feedback , Dynamic Sampling

※ これらの機能を「実行計画の安定化」を目的に、無効化されているシステムも多い

• これらの機能を無効化することは、CBOの機能／性能を

スポイルしている、と云う事実認識も必要

• ハズレの実行計画を引く確率が高まると云うリスクの増加

• 10gR2 までの BindPeek の欠点(※初回PARSE時のプランで固定される)は11gR1導入の「優れたカーソル共有」で改善

• 現在はBindPeek使用も有力な選択肢で、false一択ではない

※ KROWN#127064 [11g新機能] 優れたカーソル共有

79


SQLチューニングのまとめ


SQL とオプティマイザが抱える弱点

• SQL と RDBMSのオプティマイザは、

その言語の仕組みに由来する本質的な弱点を抱えている

• SQLはアルゴリズムを記述しないと云う特徴があるため、

それ(アルゴリズム)がRDBMS(オプティマイザ)任せになる

• SQLのアルゴリズム≒実行計画は、

コストと云う基準の「予測」で導出されている

• 「予測」である以上、ハズレのケースが出てくる

81


SQLチューニングを上手くやるには

• SQL やオプティマイザの弱点／アンチパターンを知っておく

• 実行計画は「予測」であり、ハズレが有り得ることの認識

• 予測がハズレる、ハズレ易いケースとは？

• 弱点／アンチパターンの対抗手段を見つけておく

• 予測精度を向上させる設計技法や機能の活用

• 「予測(Estimate)」と「実測(Actual)」を補正するというアプローチ

• アンチパターンをダイレクトに潰す手法も有効

• Oracle Database の機能を利用して、「予測」と「実測」の乖離を捉える

• DBMS_XPLAN.DISPLAY_CURSOR(※ALLSTATS書式)

• DBMS_SQLTUNE.REPORT_SQL_MONITOR(リアルタイムSQL監視)

82


紹介したチューニング案の方向性について

• 今回紹介したのは、全て「予測(Estimate)」と「実測(Actual)」の

乖離を補正する方向性でのチューニング

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

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

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

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

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

• 案9 … Dynamic Sampling適用

• 案10…新規索引付与

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

• チューニングの正解は1つではないので併せて利用を検討

83


共有プールの基本的理解


• 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


• 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


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


• 手動メモリ管理の場合でも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


• 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


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はその合計サイズ以上

で設定する必要あり


メモリ割り当ての優先度

• 下位の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


• SQL、定義情報、実行計画等が格納される共有メモリ領域

• データベースで行われるほぼ全ての操作でアクセスされる領域

共有プールとは

SGA

共有プール

ディクショナリキャッシュ

【オブジェクト定義】

（オブジェクト、ユーザー等のメタデータ）

リザルトキャッシュ

【結果セット】

（リザルトキャッシュ機能利用時）

ライブラリキャッシュ

【共有カーソル】

（SQL、PL/SQL、実行計画）

【オブジェクト定義】

（表、索引等） OTHER

【GCS】

（RAC環境固有）

【GES】

（RAC環境固有）

バッファキャッシュ

ログバッファ、その他

共有プールの基本的理解（１／１６）


• 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

共有プールの基本的理解（２／１６）


存続期間による分割

存続期間による分割なし 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

断片化を低減するために存続期間による分割を導入

共有プールの基本的理解（３／１６）


サブプール分割

サーバプロセス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

メモリを獲得する際は、使用するサブプールをラウンドロビン方式で選択

共有プールの基本的理解（４／１６）


• サブプール分割

• 目的：共有プールを保護するラッチ（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

永続メモリ領域

共有プールの基本的理解（５／１６） KROWN#147122

KROWN#147171


• サブプールの数は以下の初期化パラメータ値によって決定される • 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 を設定している場合

構成変更により、サブプール１つあたりのサイズが変化することがあるので注意

（特に小さくなった場合に、領域枯渇のリスクが高まるため注意）

共有プールの基本的理解（６／１６） KROWN#147122


共有プールへの新規メモリ割当ての流れ

１．フリーリストから空きを探す

フリーリストは各従属ヒープ sga heap(x,y) 毎に存在

４．使用済み領域を再利用（LRUリストをフラッシュ＆チャンクを連結して空きを作る）

２．Reserved Granule (未割当ての領域）から確保

５．共有プールを拡張（IMMEDIATEモードでバッファキャッシュから空きを確保）

６．ORA-4031エラー（要求サイズのメモリが割り当てられない）

３．予約済みプールから確保(条件があえば)

共有プールの基本的理解（７／１６）


• 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 が全て各サブプールに割り当てられた後は、各サブプール内の空き領域が再利用される

共有プールの基本的理解（８／１６）


• 予約済みプールは共有プールの一部

• サイズ：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)」から分散して予約済みプールとしてのチャンクが獲得される

共有プールの基本的理解（９／１６） KROWN# 44353


• 空き領域は各従属ヒープ毎に個別に管理／使用される

• 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも

他のサブプールや従属ヒープの空きメモリは使用されない

空き領域：分割された各サブプール／従属ヒープ内の空き領域の管理

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)」のフリーリストにリンクされる

共有プールの基本的理解（１０／１６）


• バッファキャッシュ

• 共有プールが不足すると、バッファキャッシュを減らして共有プールを拡張する（自動調整はグラニュル単位）

• DEFERREDモード(遅延要求) と、IMMEDIATEモード(即時要求)がある

空き領域：共有プールの空き領域予備軍

SGA_ TARGET

共有プール



最低値(shared_pool_size)

最低値(db_cache_size)

他コンポーネントが不足した場合の拡張余力

バッファキャッシュから共有プールにメモリを移動可能な領域

DEFERREDモード：（自動SGA管理、自動メモリ管理）定期取得した統計情報に基づいて行う

IMMEDIATEモード：（手動SGA管理、自動SGA管理、自動メモリ管理）拡張を行わないとORA-4031が発生する状況に陥った場合に行う

共有プールの基本的理解（１１／１６）


各空き領域の消費推移

共有プールの空きの量

Reserved Granule を全て使用完了

時間

予約済みプールの空きは、実際は有効利用されていない場合がある

V$SGASTAT の「free memory」（空き領域）のみでは、どのサブプールの空きか判断できない

共有プールの空きのみの監視では不十分

断片化が進行すると、再利用できない空き領域（小さい空き領域）が徐々に増加し、空き領域が右肩上がりに増加する場合もある

予約済みプールは、大きなサイズの割当てがない限り利用されない

V$SGASTAT の[shared_pool].[free memory]で確認できる空き

インスタンス起動直後

空き

予約済みプールの空き

共有プールの基本的理解（１２／１６）


• ORA-4031の発生ケース

• 連続した空き領域を確保できない場合に発生するエラー

• 従来からの代表的な発生例は、サイズが小さい、断片化によるもの

• 昨今のメモリ低コスト化、大規模化によって、余裕を持った共有プールのサイジングが可能となり、共有プール全体のサイズが小さいことが原因でORA-4031が発生するという事例は比較的減少傾向（総量は足りているケースが多い）

メモリ割当てエラー（ORA-4031）

sga heap(x,y)

A: 空き B: 使用中 C: 空き

D:割当て要求

要求したメモリサイズ分の連続した空き領域を確保できない場合には ORA-4031 が発生

ORA-4031

共有プールの基本的理解（１３／１６）


最近のORA-4031の傾向

最近の発生パターン実例

サブプール間の偏り特定の機能に依存した処理の大量使用により、一部のサブプールが肥大化し、他のサブプールへの割り当てが失敗（他のサブプールのサイズ（空き領域）が小さくなったため）

従属ヒープ（存続期間による分割）間の偏りリテラルSQLを多く使用した環境において、共有SQL領域（sga heap（n,3））が肥大化した結果、存続期間が長い従属ヒープ（sga heap（n,1））への割り当てが失敗

共有プールの拡張余力がない

（共有プール拡張時の供給元の

バッファキャッシュの余力がない）

バッファキャッシュ最低サイズ（db_cache_size）の設定不備

（不必要に大きく設定されていた）により、共有プールの自動拡張ができず、割り当てが失敗

共有プールの空き領域監視のみでは検知できない

共有プールの基本的理解（１４／１６）


• サイズ（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 競合が発生しやすくなる

共有プールの基本的理解（１５／１６）


• 共有プールの構造

• 最大で28個に分割される（サブプール分割／存続期間による分割）

• サブプール間での偏りが生じる場合がある

• 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも

他のサブプールや従属ヒープの空きメモリは使用されない

まとめ

テストに完全な網羅性がないリスクは、拡張余力のリアルタイム監視で担保

共有プールの空き領域監視のみでは空きの枯渇は検知できない

共有プールの基本的理解（１６／１６）


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

での検討事項

２．一次サイジング（自動SGA前提） • 主要チャンクのサイズを意識した一次サイジング

• 共有プール自動拡張余力の確保

３．監視・チューニング（自動SGA前提） • テスト・運用フェーズの監視

• チューニング（二次サイジング）

１．管理方式選定 • 手動SGA管理、自動SGA管理、自動メモリ管理の選択

設計テスト・運用


共有プール(SGA)管理方式比較

１．管理方式選定

比較項目手動SGA管理自動SGA管理（10gR1～）自動メモリ管理（11gR1～）

概要

・SGAの各SGAコンポーネント（バッファキャッシュ、共有プール、ラージプールなど）のサイズを個別に設定する

・SGA全体のサイズを設定し、各SGAコンポーネント（バッファキャッシュ、共有プール、ラージプールなど）のサイズは、必要に応じて動的に調整される

・SGAとPGAの合計サイズを設定し、PGAと各SGAコンポーネント（バッファキャッシュ、共有プール、ラージプールなど）のサイズは、必要に応じて動的に調整される

特徴

・各コンポーネントの精緻なサイジングが必要

・手動SGA管理でも、共有プールが不足した場合は、IMMEDIATE

モードで、バッファキャッシュを縮小し、動的に共有プールが拡張される（11gR2～）

（KROWN#151272）

・一次サイジングが比較的容易

・各SGAコンポーネントの最低サイ

ズを設定可能

・11gR2では広く採用されている

・一次サイジングが比較的容易

・PGA、各SGAコンポーネントの最

低サイズを設定可能

・LinuxではHugepageとの併用ができない

・PGAのサイズ変動により、同じ処理の性能が変わる可能性あり


• 自動SGA管理 ⇒ 95%以上の採用率、推奨設定

• 11gR2では、経験則的に95%以上のシステムで、広く一般的に採用されており日本オラクルコンサルが支援する場合に、初めに検討する方式

• 手動SGA管理 ⇒ 数％程度の採用率

• 旧バージョンからの移行のお客様以外、新規に採用するケースはほとんどない

• 自動メモリ管理 ⇒ 数％程度の採用率

• 中～大規模なシステムでもOSとしてLinuxが選定されることが多くなってきておりHugepageと併用できないため、積極的に採用されるに至っていない

手動SGA管理、自動SGA管理、自動メモリ管理の採用率 ※ 日本オラクルでコンサル支援することが多い中～大規模のシステムでの経験値

１．管理方式選定



での検討事項








• 初期設定値計算イメージ

• 共有プールに占める主要なチャンク領域を見積もる • バッファキャッシュ依存領域

• バッファキャッシュのブロック数に応じて計算する

• 共有SQL領域

• 経験則的に十分なサイズを確保する

• 各種可変領域

• サブプール数に応じて一次サイジングする

• ３つの領域の合計に余裕率を掛けて計算する

共有プールを３つの領域に分割して一次サイジング

shared_pool_size初期設定値＝

バッファキャッシュ依存領域（固定領域）

+ 共有SQL領域（可変領域）

+ 各種可変領域（可変領域）

1.2倍（余裕率） X

２．一次サイジング共有プール

#1

#2

#n

・・・・・

共有SQL領域

バッファキャッシュ依存領域

（計算式により固定値算出）

各種可変領域

（サブプール数分）

サブプール


• db_block_hash_buckets

• バッファキャッシュを管理するハッシュ・バケットの領域がキャッシュされる

• バッファキャッシュのブロック数に比例して大きくなり、大規模なバッファキャッシュを確保するシステムでは、共有プールのサイジングに注意が必要

• サイズ見積もり（11gR2の場合）

• バッファキャッシュ1GBにつき15MBで計算

※ 11gR2の実績から導出した参考値。実機確認の上、調整する。

※ db_block_size=8KBの前提

バッファキャッシュ依存領域（RAC/Single共通）

KROWN#129856 バッファ・キャッシュのサイズ変更時の注意点

固定領域２．一次サイジング

KROWN#129856


• 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のみ）

固定領域２．一次サイジング


• 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%

２．一次サイジング


• 各種可変領域の机上見積もりは不可能

• 共有SQL以外の可変領域で、そのサイズは、使用する機能、

使い方、同時実行並列度に依存するため、見積もりは困難

• サブプール数から仮見積もりする

• サブプールあたりのサイズを十分に確保する

• CPU数が多い（サブプールが多い）システムでは、

処理の多様性が高くなり、より多くの領域が必要

• プール分割に起因する障害防止

各種可変領域

共有プール(2.1GB)

可変領域

#1

30

0M

【悪い例】

総量では2.1GBと大きいが、サブプールが小さいため、更に従属ヒープに分割され、ORA-4031が発生し易い

#7 3

00M

・・・・

サブプール



• db_cache_sizeとshared_pool_sizeには最低サイズを設定する

• [sga_target > 各SGAコンポーネント設定値の和]になるよう、

共有プールの拡張余力を十分に確保する

共有プール自動拡張余力の確保

SGA_ TARGET

共有プール



最低値(shared_pool_size)

最低値(db_cache_size)

初期サイジングでは、バッファキャッシュからの共有プール拡張余力を十分に確保して、テストに臨むことが重要

共有プールと同サイズ程度の拡張余力があれば、共有プールが自動拡張した後、対処の為の時間的猶予ができる

他コンポーネントが不足した

場合の拡張余力



• RAC環境の場合は、必要に応じて縮退運転時の余裕分を考慮する

• 完全にアプリケーションパーティショニングされているRAC環境では、縮退運転時に、生存ノードでは全く異なるタイプの処理を受け付けることになる

• 縮退運転のテストにて増加分を検討する

• 見積もりは困難であるため、縮退運転のテストにおいて、特定チャンクが過剰に増加していないか確認の上、共有プールのサイズ追加を検討する

RAC縮退運転時の考慮

【例】・ノード間で実行されているSQLが異なるため、縮退時のSQLAが増加・ノード間でアクセスするオブジェクトが異なるため、ディクショナリキャッシュが増加・ノード間で発生するロックの種類が異なるため、GES関連領域が増加




での検討事項








• 共有プールの監視

• 「共有プールの空き率監視」、

「チャンク別のサイズ遷移分析」などが一般的

• 共有プールの空き率分析の問題点

• V$SGASTATの[shared pool].[free memory]には、

予約済プールが含まれるため、空きが枯渇することはほぼない

• 空きが少なくても、使用頻度の低いチャンクを再利用できていれば問題ない

• サブプール別、従属ヒープ別の空きは確認できない

• 断片化が進行すると、再利用可能な連続領域が減少し、

逆に空き率が上昇傾向を示すことがある

空き率分析の問題点３．監視・チューニング


• 共有プールに関するリアルタイム監視は①で実施する

• ②～⑥と高負荷の⑦は必要に応じて情報収集を検討する

推奨する共有プールの監視

◎：必須 ○：推奨 △：必要に応じて検討

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を掴むため高負荷) 情報取得 △ △

３．監視・チューニング


• 自動SGA管理の設計指針として重要なのは、

「共有プールの拡張余力を十分に残す」こと

• インスタンスの再起動を頻繁にできない環境では、

早めに検知できる閾値を設定する

• 監視間隔は30分～

60分間隔程度で十分

①共有プール拡張余力の監視（リアルタイム監視）（１）

共有プールの拡張余力を監視する

運用 ◎

テスト ○

拡張余力が十分に確保されていることを監視する

３．監視・チューニング


• V$SGA_DYNAMIC_COMPONENTSによる拡張余力の監視

• バッファキャッシュの【現在値(CURRENT_SIZE)】－【初期設定値(USER_SPECIFIED_SIZE)】に十分余裕があることを確認

• バッファキャッシュの「現在値」から「初期設定値」を引いた数値が共有プールの自動拡張余力と言える

①共有プール拡張余力の監視（リアルタイム監視）（２）

【例】「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

３．監視・チューニング運用 ◎

テスト ○


• 共有プールが自動拡張機能で拡張を続けていないか確認

• IMMEDIATEモードや、DEFERREDモードによる自動拡張が頻発していない

（各コンポーネントのサイズが安定推移している）ことを確認する

• 共有プールが拡張し続けるような傾向にあれば、

①の監視閾値を越える前に、対策をする必要がある

• 処理特性が同じ時間帯に、共有プールとバッファキャッシュの間で、

短時間に頻繁に奪い合いが発生（増減を繰り返す）していたら、

SGAが不足していると考えられる

②共有プールのサイズ遷移の傾向分析（情報取得）（１）

【対処】

・③の分析で特定チャンクの過剰消費があれば原因を分析する

・sga_target/shared_pool_sizeを見直す


テスト ◎


• SGAコンポーネントのサイズ遷移を確認する

• AWRレポートの「Memory Dynamic Components」セクションの時系列データ

• 定期取得したV$SGA_DYNAMIC_COMPONENTS

（①のリアルタイム監視と情報ソースは同じ）

②共有プールのサイズ遷移の傾向分析（情報取得）（２）

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の奪い合いが続いている


テスト ◎


• 性能テスト・本番運用開始時の注意

• テスト、運用開始時点で、共有プールの拡張余力が十分残っていることを

AWRやV$SGASTATなどで確認すること

• テストデータの作成、大量オブジェクトのコンパイル、移行データの作成などで、実運用時と異なる用途の領域により共有プールが自動拡張している場合がある

②共有プールのサイズ遷移の傾向分析（情報取得）（３）

時間経過

SGA_ TARGET

6 G B

バッファキャッシュ初期値(最低値)：2GB

共有プール初期値(最低値)： 2GB

テスト運用開始時点で、共有プールの拡張余力がなくなっている

×テスト・運用開始 ○テスト・運用開始


テスト ◎


• 共有プールのチャンクサイズの推移を確認する

• 空き領域と、先に上げた、共有SQL領域、RAC依存領域など

重要なチャンクを中心に、サイズの推移を確認する

• 各チャンクサイズが安定的に推移しているか、

特定チャンクが増加し続ける傾向がないか確認する

• 空き領域の大小をそれほど注目して見る必要はない

③チャンク別サイズ遷移の傾向分析（情報取得）（１）

３．監視・チューニング運用 ○

テスト ◎


• AWRレポートの「SGA breakdown difference」より時系列にグラフ化

• 定期的取得したV$SGASTATより時系列にグラフ化

③チャンク別サイズ遷移の傾向分析（情報取得）（２）

特定のチャンクが肥大し続けることなく安定推移


テスト ◎


• サブプール間の偏りを確認する

• 共有プール全体として空きがあっても、特定のサブプールの肥大により

ORA-4031が発生することがある

• リアルタイム監視は不要だが、テストの時や、

新規アプリリリース後の本番環境などで、特定の

サブプールに偏りがないか確認し、極端な偏りは、

原因を明らかにする

④サブプール別の偏り傾向分析（情報取得）（１）

【偏りが見つかった場合の対処】

• 偏りの原因を分析する

• sga_target/shared_pool_sizeを見直し、各サブプールが十分大きくなるように調整する（サブプール別の割り当てサイズは手動制御できないため）

共有プール(2.4GB)

#1 3

00M

【悪い例】

サブプール#2に割り当てが極端に偏っている

サブプール

#2

1500M

#3

30

0M

#4

30

0M


テスト ◎


• 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()を外して、何のチャンクが偏っているか確認する


テスト ◎


• 予約済みプールの空き領域確認

• 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以上のチャンクが頻繁に割り当てられる原因を調査した上で、必要に応じて、共有プールの拡張を検討する


テスト ◎


• 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

３．監視・チューニング運用 △

テスト ○

KROWN#109941


• X$KSMSPで、従属ヒープ別のサイズと空きを確認

• 検索時にshared pool latchを取得し負荷が高いため、

本番環境や性能テスト中の採取は推奨しない

• 従属ヒープの肥大や、断片化状態を分析するなど、

個別の障害分析目的で取得することが多い

• 性能・負荷テスト終了後や、本番のオンライン終了後、バッチ終了後のような

処理の切れ目で情報取得しておくと、ORA-4031の分析に役立つ場合がある

⑦従属ヒープ別の偏り傾向分析（情報取得）

KROWN#19607

ライブラリ・キャッシュのメモリ使用状況確認スクリプト

KROWN#132267

X$ 表から分割された共有プールの各プールごとの使用状況を確認する方法

３．監視・チューニング運用 △

テスト △

KROWN#19607

KROWN#132267


共有プールのサイジング、テスト、運用の重要ポイント

② 大規模バッファキャッシュ環境（特にRAC環境）では、バッファキャッシュ依存領域を上乗せしてサイジングする

④ 共有プールの自動拡張余力を残して、バッファキャッシュの最低サイズを設定する

⑤ 共有プールの自動拡張余力が残っていることをリアルタイム監視する

③ １サブプールあたりのサイズを十分に大きくサイジングする

① 自動SGA管理の使用を推奨

ORA-4031撲滅

まとめ


目的とゴール

135

• SQLチューニングにおける様々な「戦術」をつかむ

• 「予測(Estimate)」と「実測(Actual)」の乖離を捉える補正する

• ORA-4031撲滅

• 共有プールの性質の理解

• メモリ設計・監視のポイント

目的

SQLチューニングで有効となるテクニックとメモリ障害の予防を知る

ゴール



Documents

SQLチューニング＆メモリチューニングに 必要な考 …...2014/03/12 · Cardinality Feedback, 等) ・適切な索引 ・ヒストグラム ・拡張統計 ・ヒント

SQLチューニング＆メモリチューニングに必要な考 …...2014/03/12 · Cardinality Feedback, 等) ・適切な索引・ヒストグラム・拡張統計・ヒント