Automatic Database Diagnostic Monitor（ADDM）は、全体的なチューニング・ソリューショ
ンを提供します。ADDM分析は、特定のインスタンス上で作成された1対のAWRスナップ ショットで定義される期間に対して実行できます。分析はトップ・ダウン方式で実行され、最 初に症状が識別されてから、パフォーマンスの問題の根本的な原因に到達するまで詳細化され ます。
分析の目標は、DBtimeと呼ばれる1つのスループット測定値を減少させることです。DB timeは、データベース・サーバーでユーザー要求の処理にかかった累積時間です。これには、
アイドル状態でないユーザー・セッションすべての待機時間とCPUタイムが含まれます。DB timeは、V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューに表示されます。
個々のユーザー応答時間のチューニングはADDMの対象でないことに注意してください。
個々のユーザー応答時間のチューニングには、トレース・テクニックを使用します。 20-2ペー ジの「End to End Application Tracing」を参照してください。
DBtimeの短縮により、データベース・サーバーで同じリソースを使用してサポートできる ユーザー要求の数が増加し、スループットが改善されます。ADDMによりレポートされる問題 は、それに関係するDBtimeの量でソートされます。DBtimeの大部分に関係しないシステム 領域は、正常領域としてレポートされます。
ADDMでは、次のようなタイプの問題が考慮されます。
■ CPUのボトルネック: システムCPUがOracleまたは他のアプリケーションによりバインド されているかどうか。
■ 過小なメモリー構造: SGA、PGA、バッファ・キャッシュなど、Oracleメモリー構造が十 分なサイズに設定されているかどうか。
■ I/O能力の問題: I/Oサブシステムが予想どおりに動作しているかどうか。
■ 高負荷のSQL文: システム・リソースを過剰に使用しているSQL文があるかどうか。
■ 高負荷のPL/SQL実行およびコンパイルと、高負荷のJava使用率。
■ RAC固有の問題: グローバル・キャッシュのホット・ブロックとオブジェクトはどうなっ ているか。相互接続遅延の問題があるかどうか。
■ アプリケーションによるOracleの不適切な使用: 不適切な接続管理、過剰な解析またはア プリケーション・レベルのロック競合による問題があるかどうか。
■ データベース構成の問題: 不適切なログ・ファイル・サイズの設定、アーカイブの問題、過 剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。
■ 同時実行性の問題: バッファ・ビジーの問題があるかどうか。
■ 様々な問題領域のホット・オブジェクトおよび上位SQL。
ADDMでは、システムの正常領域も文書化されます。たとえば、システムのパフォーマンスに ほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から 削除されます。これにより、システム全体のパフォーマンスに影響しない項目に対する時間お よび労力の節約になります。
関連項目 関連項目 関連項目 関連項目:
■ V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューの詳細は、
『Oracle Databaseリファレンス』を参照してください。
■ 時間モデル統計およびDBtimeについては、5-3ページの「時間モデ ル統計」を参照してください。
■ サーバー・プロセスについては、『Oracle Database概要』を参照して ください。
ADDMでは、問題の診断に加えて可能な解決策も推奨されます。該当する場合は複数の解決策 が推奨され、データベース管理者はその中から選択できます。ADDMでは、推奨事項の生成中 にシステムに対する様々な変更が考慮されます。次のような推奨事項があります。
■ ハードウェア変更: CPUの追加またはI/Oサブシステム構成の変更
■ データベース構成: 初期化パラメータ設定の変更
■ スキーマ変更: 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域 管理（ASSM）の使用
■ アプリケーション変更: 順序付けのためのキャッシュ・オプションの使用またはバインド変 数の使用
■ その他のアドバイザの使用: 高負荷SQLに対するSQLチューニング・アドバイザの実行、
またはホット・オブジェクトに対するセグメント・アドバイザの実行
ADDM の分析結果 の分析結果 の分析結果 の分析結果
ADDMの分析結果は、一連の検出結果として表示されます。ADDMの分析結果の例は、6-4 ページの例6-1を参照してください。ADDMの検出結果は、それぞれ次の3つのタイプのいず れかに属します。
■ 問題: データベース・パフォーマンスの問題の根本的な原因を記述する検出結果
■ 症状: 1つ以上の問題を検出するための情報を含む検出結果
■ 情報: システムの正常領域のレポートに使用される検出結果
問題の検出結果はそれぞれ、その検出結果のパフォーマンスの問題に起因する影響をDB time に占める割合の見積りとして数量化したものです。問題の検出結果を推奨事項のリストに関連 付けて、パフォーマンスの問題による影響を軽減できます。各推奨事項にはそれぞれメリット があります。このメリットは、その推奨事項を実装した場合に節約できるDBtimeの割合を見 積ったものです。推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合 があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。
推奨事項は、アクションおよび理論的根拠で構成されます。見積もられたメリットを得るため には、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアク ションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使 用されます。
ADDM の例 の例 の例 の例
例6-1に示すADDMレポートの次のセクションを検討します。
例 例 例
例 6-1 ADDMレポートの例レポートの例レポートの例レポートの例
FINDING 1: 31% impact (7798 seconds) ---
SQL statements were not shared due to the usage of literals. This resulted in additional hard parses which were consuming significant database time.
RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)
ACTION: Investigate application logic for possible use of bind variables instead of literals. Alternatively, you may set the parameter
"cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be using literals. Look in V$SQL for examples of such SQL statements.
この例で、検出結果は特定の根本的な原因を示しています。SQL文のリテラルの使用は、分析 期間中のDB time合計の約31%に影響があると見積もられています。
この検出結果には、アクション1つおよび理論的根拠1つで構成される推奨事項が関連付けら れています。アクションでは検出された問題の解決策が指定され、その最大メリットは分析期 間中のDBtimeの31%以内と見積もられます。メリットは、検出結果の影響に占める割合で
リテラルを使用していてこのパフォーマンスの問題を引き起こした可能性のあるSQL文を追跡 するための追加情報を提供します。データベース管理者は、問題の原因と思われるSQL文につ いて指定の計画ハッシュ値を使用すると、少数のサンプル文をすばやく検査できます。
特定の問題に複数の原因がある場合は、ADDMにより複数の問題と症状の検出結果がレポート されることがあります。この場合、複数の検出結果による影響には、DBtimeが同じ割合で含 まれる可能性があります。検出結果のパフォーマンスの問題はオーバーラップしている場合が あるため、レポートされた検出結果の影響を合算すると、DBtimeの100%を超える場合があ ります。たとえば、システムで多数の読取りI/Oが実行される場合、ADDMでは、I/Oアク ティビティによるDBtimeの50%に関係するSQL文が1つの検出結果としてレポートされ、
DB timeの75%に関係する小さいサイズのバッファ・キャッシュが別の検出結果としてレポー トされる場合があります。
問題の検出結果に複数の推奨事項が関連付けられている場合は、それぞれに問題の代替解決策 が含まれていることがあります。この場合、推奨事項によるメリットの合計は検出結果の影響 よりも大きいことがあります。
該当する場合は、ADDMアクションで複数の解決策が推奨され、データベース管理者はその中 から選択できます。この例では、最も有効な解決策はバインド変数を使用することです。ただ し、通常、アプリケーションを変更することは困難です。CURSOR_SHARING初期化パラメータ の値を変更する方が実装が容易で、大幅な改善が可能です。
ADDM の設定 の設定 の設定 の設定
Automatic Database Diagnostic Monitorはデフォルトで使用可能になり、
STATISTICS_LEVEL初期化パラメータにより制御されます。Automatic Database Diagnostic
Monitorを使用可能にするには、STATISTICS_LEVELパラメータをTYPICALまたはALLに
設定する必要があります。デフォルト設定はTYPICALです。STATISTICS_LEVELをBASIC に設定すると、ADDMを含めて多数のOracle機能が無効になります。この設定はお薦めしま せん。
ADDMによるI/Oパフォーマンス分析は、1つの引数DBIO_EXPECTEDに部分的に依存しま す。この引数では、I/Oサブシステムのパフォーマンス予測を記述します。DBIO_EXPECTED の値は、1つのデータベース・ブロックを読み取るための平均所要時間（マイクロ秒単位）で
す。Oracleではデフォルト値の10ミリ秒が使用されます。この値は、最新のほとんどのハー
ド・ドライブに適しています。極端に古いハードウェアや超高速のRAMディスクなど、ハー ドウェアが大きく異なっている場合は、異なる値を使用することを考慮してください。
DBIO_EXPECTEDパラメータの適切な設定を判断する手順は、次のとおりです。
1. ハードウェアについて、1データベース・ブロックを読み取るための平均所要時間を測定 します。この測定の対象はランダムI/Oであり、標準ハード・ドライブを使用している場 合はシーク時間が含まれることに注意してください。ハード・ドライブの標準値は5000～
20000マイクロ秒です。
2. 後続のすべてのADDM実行について値を1度設定します。たとえば、測定値が8000マイ クロ秒の場合は、次のコマンドをSYSユーザーとして実行する必要があります。
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
関連項目 関連項目 関連項目
関連項目: STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle
Databaseリファレンス』を参照してください。