自動パフォーマンス診断

7 自動パフォーマンス診断

この章では、Oracle Databaseの自動パフォーマンス診断およびチューニング機能について説明します。

この章のトピックは、次のとおりです:

関連項目:

Oracle Enterprise Manager Cloud Control (Cloud Control)で、自動データベース診断モニターを使用してデータベースの診断およびチューニングを行う方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

自動データベース診断モニターの概要

自動ワークロード・リポジトリ(AWR)には、Oracleデータベースのパフォーマンス関連統計が格納されます。自動データベース診断モニター(ADDM)は、AWRデータの定期的な分析、パフォーマンスに関する問題の根本原因の特定、問題を修正するための推奨事項の提示、問題のないシステム領域の特定を行う診断ツールです。AWRはパフォーマンスに関する履歴データのリポジトリであるため、ADDMでは、イベントの後にパフォーマンスの問題を分析でき、時間とリソースをかけて問題を再現する必要がありません。

多くの場合、データベース管理者はパフォーマンスの問題に関して通知を受け取った時点で、まずADDM出力を調べる必要があります。ADDMには次の利点があります。

デフォルトで1時間ごとの自動パフォーマンス診断レポート
数十人のチューニング専門家に基づく問題の診断
問題の影響と推奨事項による利点の時間ベースの数量化
症状ではなく根本的な原因の特定
問題の根本的な原因の処理に関する推奨事項
システムのうち正常な領域の特定
診断処理中のシステムに対する最小限のオーバーヘッド

チューニングは反復的なプロセスであり、ある問題を修復したことが原因でシステムの他の部分がボトルネックになる場合があります。ADDM分析による利点があるとしても、システム・パフォーマンスが許容レベルに達するまでには複数のチューニング・サイクルを必要とする場合があります。ADDMによる利点は本番システムに適用されるのみでなく、開発およびテスト・システムでもパフォーマンスの問題を早期に警告できます。

この項では、次の項目について説明します。

ノート:

プラガブル・データベース(PDB)とともにADDM機能を使用している場合には、データ可視性および権限の要件が異なります。ADDM機能などの管理機能がマルチテナント・コンテナ・データベース(CDB)で機能する仕組みの詳細は、Oracle Multitenant管理者ガイドを参照してください。

ADDM分析

ADDM分析は、AWRスナップショットのペアと、同じデータベースのインスタンスのセットに対して実行できます。AWRスナップショットのペアにより分析の期間が定義され、インスタンスのセットにより分析のターゲットが定義されます。

Oracle Real Application Clusters (Oracle RAC)を使用している場合、ADDMには次の3つの分析モードがあります。

データベース

データベース・モードでは、ADDMによりデータベースのすべてのインスタンスが分析されます。
インスタンス

インスタンス・モードでは、ADDMによりデータベースの特定のインスタンスが分析されます。
部分

部分モードでは、ADDMによりすべてのデータベース・インスタンスのサブセットが分析されます。

Oracle RACを使用しない場合は、存在するデータベース・インスタンスが1つのみであるため、ADDMはインスタンス・モードでのみ動作します。

ADDM分析はAWRスナップショットが作成されるたびに実行され、結果がデータベースに保存されます。ADDMにより分析される期間は、最新の2つのスナップショットにより定義されます(デフォルトでは最後の1時間)。ADDMでは、インスタンス・モードで指定されたインスタンスが常に分析されます。Oracle RAC以外の環境または単一インスタンス環境の場合、インスタンス・モードで実行される分析は、データベース全体の分析と同じになります。Oracle RACを使用している場合、「Oracle Real Application ClustersでのADDMの使用方法」に記載されているとおり、ADDMではデータベース・モードでもデータベース全体を分析します。

ADDMで分析が完了すると、Cloud Control、DBMS_ADDMパッケージ・サブプログラム、またはDBA_ADDM_*ビューとDBA_ADVISOR_*ビューのいずれかを使用してADDM結果を表示できます。

ADDM分析は、トップダウン方式で実行され、最初に症状を識別し、次にパフォーマンスの問題の根本的な原因に到達するまで精査します。分析の目標は、DB timeと呼ばれる1つのスループット・メトリックを減少させることです。DB timeは、データベース・パフォーマンスの基本的な測定基準で、データベースがユーザー・リクエストの処理に費やした累積時間を表します。これには、アイドル状態でないすべてのユーザー・フォアグラウンド・セッションの待機時間とCPU時間が含まれます。DB timeは、V$SESS_TIME_MODELビューおよびV$SYS_TIME_MODELビューに表示されます。

DB timeの短縮により、データベースで同じリソースを使用してサポートできるユーザー・リクエストの数が増加し、スループットが改善されます。ADDMによりレポートされる問題は、それに関係するDB timeの量でソートされます。DB timeの大部分に関係しないシステム領域は、正常領域としてレポートされます。

ADDMでは、次のようなタイプの問題が考慮されます。

CPUのボトルネック - システムCPUがOracle Databaseまたは他のアプリケーションによりバインドされているかどうか。
過小なメモリー構造 - SGA、PGA、バッファ・キャッシュなど、Oracle Databaseメモリー構造が十分なサイズに設定されているかどうか。
I/O能力の問題 - I/Oサブシステムが予想どおりに動作しているかどうか。
高負荷のSQL文: システム・リソースを過剰に使用しているSQL文があるかどうか。
高負荷のPL/SQL実行およびコンパイルと、高負荷のJavaの使用
Oracle RAC固有の問題 - グローバル・キャッシュのホット・ブロックおよびオブジェクトの問題、相互接続遅延の問題があるかどうか。
アプリケーションによるOracle Databaseの不適切な使用 - 不適切な接続管理、過剰な解析またはアプリケーション・レベルのロック競合による問題があるかどうか。
データベース構成の問題 - 不適切なログ・ファイル・サイズの設定、アーカイブの問題、過剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。
同時実行性の問題 - バッファ・ビジーの問題があるかどうか。
様々な問題領域のホット・オブジェクトおよび上位SQL。

ノート:

これは、ADDMの分析で考慮されるすべての問題タイプの包括的なリストではありません。

ADDMでは、システムの正常領域もドキュメント化されます。たとえば、システムのパフォーマンスにほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から削除されます。これにより、システム全体のパフォーマンスに影響しない項目に費やされる時間および労力が節約されます。

関連項目:

V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
時間モデル統計およびDB timeの詳細は、「時間モデル統計」を参照してください
サーバー・プロセスの詳細は、『Oracle Database概要』を参照してください。

Oracle Real Application ClustersでのADDMの使用方法

Oracle RACを使用する場合は、データベース分析モードでADDMを実行して、すべてのデータベース・インスタンスのスループット・パフォーマンスを分析します。データベース・モードでは、ADDMは、DB時間をすべてのデータベース・インスタンスのデータベース時間の合計とみなします。データベース分析モードを使用すると、データベース全体にとって重要なすべての検出結果が単一のレポートに表示されます(各インスタンスの個別レポートは表示されません)。

データベース・モードのレポートには、データベース・リソース(I/Oやインターコネクトなど)に関する検出結果が含まれます。レポートには、データベース全体にとって重要な場合は、様々なインスタンスからの検出結果も集計されます。たとえば、単一のインスタンスに対するCPU負荷が高く、データベース全体に影響する場合、データベース・モード分析に、問題の原因である特定のインスタンスを示す検出結果が表示されます。

関連項目:

Oracle RACでのADDMの使用の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください

マルチテナント環境でのADDMの使用

Oracle Database 12c以降、ADDMはマルチテナント・コンテナ・データベース(CDB)のルート・コンテナでデフォルトで有効になっています。Oracle Database 19c以降では、プラガブル・データベース(PDB)でもADDMを使用できます。

CDBでは、ADDMは非CDBでの動作と同様に機能します。つまり、ADDM分析はAWRスナップショットがCDBルートまたはPDBで取得されるたびに実行され、ADDM結果はスナップショットが取得されたのと同じデータベース・システムに格納されます。ADDMにより分析される期間は、最新の2つのスナップショットにより定義されます(デフォルトでは最後の1時間)。

ADDMで分析が完了したら、次のいずれかの方法を使用してADDM結果を表示できます。

Enterprise Manager Cloud Control (Cloud Control)の使用
DBA_ADDM_*ビューおよびDBA_ADVISOR_*ビューの使用

ノート:

CDBルートではADDMはデフォルトで有効化されています。
PDBでは自動AWRスナップショットがデフォルトで無効になっているため、デフォルトではADDMはPDBで機能しません。PDBでADDMを使用するには、PDBで自動AWRスナップショットを有効にする必要があります。
現在のコンテナがCDBルートであるユーザーは、CDB全体のADDM結果を表示できます。ADDM結果には、複数のPDBに関する情報が含まれる場合があります。PDBが切断されていると、PDBに関連するADDM結果は含まれません。現在のコンテナがPDBである場合、CDBルートに格納されているADDM結果を表示することはできません。
PDBに対するADDM結果では、PDB固有の結果および推奨事項のみが提供されます。現在のコンテナがPDBであるユーザーは、現在のPDBのみのADDM結果を表示できます。ADDM結果には、CDB全体に該当する診断結果(バッファ・キャッシュ・サイズに関連するI/Oの問題など)は含まれません。
PDBでAWRスナップショットを有効にしても、CDBルートのADDMレポートは変更されません
PDBのAWRデータはCDBルートからアクセスできません

PDBレベルのADDMの制限事項

非CDBとは異なり、ADDMはPDBの次の問題を報告しません。これらの問題はCDB全体に適用され、個々のPDBに適用されないためです。

次の原因によるI/Oの問題:
- バッファ・キャッシュのサイズが小さい
- ストリーム・プールのサイズが小さい
- 一時的な書込みが多すぎる
- チェックポイントの書込みが多すぎる
- UNDOの書込みが多すぎる
- PQチェックポイントの書込みが多すぎる
- 切捨ての書込みが多すぎる
- 表領域DDLのチェックポイントが多すぎる
- I/O容量の制限
次の原因によるSQLハード解析の問題:
- カーソルのエージング
- メモリー不足により失敗した解析
SGAサイズの設定の問題

ADDMではPDBの次の問題もレポートされません。これらの問題はPDBレベルで解決できないためです。

ネットワークの待機時間、輻輳、競合、損失ブロックなどのクラスタのメッセージ機能関連の問題
ログ・ファイル・スイッチがアーカイブおよびチェックポイント未完了を待機している
空きバッファの待機が多すぎる
ログ・バッファの待機の競合
CPUボトルネックによる待機
オペレーティング・システムのVMページング
セッション・スロット待機イベント
CPU Quantum待機イベント
RMAN関連の待機イベント(PQキュー待機イベント、PGA制限待機イベント、I/Oキュー待機イベントなど)

関連項目:

PDBでADDMを有効にする方法の詳細は、プラガブル・データベースでのADDMの有効化を参照してください
ADDMビューのDBA_ADDM_*およびDBA_ADVISOR_*の詳細は、ADDMビューを参照してください
DBMS_ADDMパッケージのサブプログラムを使用してOracle DatabaseでADDMを実行する方法の詳細は、「ADDMを使用したデータベース・パフォーマンスの問題の診断」を参照してください。
Cloud Controlを使用してOracle DatabaseでADDMを実行する方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

プラガブル・データベースでのADDMの有効化

PDBでは自動AWRスナップショットがデフォルトで無効になっているため、デフォルトではADDMはプラガブル・データベース(PDB)で機能しません。PDBでADDMを使用するには、AWR_PDB_AUTOFLUSH_ENABLED初期化パラメータをTRUEに設定し、AWRスナップショット間隔を0より大きく設定して、PDBの自動AWRスナップショットを有効にする必要があります。

PDBでADDMを有効にするには:

次のコマンドを使用して、PDBでAWR_PDB_AUTOFLUSH_ENABLED初期化パラメータをTRUEに設定します。
```
SQL> ALTER SYSTEM SET AWR_PDB_AUTOFLUSH_ENABLED=TRUE;
```
次の例に示すようなコマンドを使用して、PDBでAWRスナップショット間隔を0より大きい値に設定します。
```
SQL> EXEC dbms_workload_repository.modify_snapshot_settings(interval=>60);
```

関連項目:

AWR_PDB_AUTOFLUSH_ENABLED初期化パラメータの詳細は、Oracle Databaseリファレンスを参照してください
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

リアルタイムADDM分析

Oracle Enterprise Manager Cloud Control (Cloud Control) 12cで導入されたリアルタイムADDMを使用すると、これまではデータベースの再起動が必要であった、応答しないデータベースやハングしているデータベースの問題を分析および解決できます。リアルタイムADDMは、事前定義された一連の基準を調査し、データベースの現在の問題を分析します。問題の分析後は、リアルタイムADDMにより、デッドロック、ハング、共有プールの競合やその他の例外的な状況などの特定された問題を、データベースを再起動することなく解決できます。

この項では、リアルタイムADDMについて説明しており、内容は次のとおりです。

関連項目:

Cloud ControlでリアルタイムADDMを使用する方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

リアルタイムADDMの接続モード

Cloud Controlを使用してデータベースに接続する際、リアルタイムADDMではデータベースの状態に応じて、2つの異なるタイプの接続モードが使用されます。

通常接続

このモードでは、リアルタイムADDMにより、データベースへの通常のJDBC接続が実行されます。このモードは、一部の接続が利用できる場合に、広範囲にわたるパフォーマンス分析を行うことを目的としています。
診断接続

このモードでは、リアルタイムADDMにより、データベースへのラッチレス接続が実行されます。このモードは、通常のJDBC接続を実行できない極端なハング状況で使用します。

リアルタイムADDMのトリガー

Oracle Database 12c以降、リアルタイムADDMにより、データベースの一時的なパフォーマンス問題の検出が可能になりました。これを実行するために、リアルタイムADDMが3秒ごとに自動的に実行され、インメモリー・データを使用して、データベース内のパフォーマンス・スパイクが診断されます。

次のステップで説明するように、パフォーマンスの問題が検出されると、リアルタイムADDMにより分析が自動的にトリガーされます。

管理性モニター・プロセス(MMON)により、ロックやラッチを発生させることなく、パフォーマンス統計を取得するためのアクションが3秒ごとに実行されます。
MMONプロセスは統計を確認し、表7-1にリストされている問題が検出された場合には、リアルタイムADDM分析をトリガーします。
MMONスレーブ・プロセスによりレポートが作成され、AWRに格納されます。

レポートのメタデータを表示するには、DBA_HIST_REPORTSビューを使用します。

表7-1に、リアルタイムADDM分析がトリガーされる問題と条件をリストします。

表7-1 リアルタイムADDMがトリガーされる問題および条件

問題	条件
高負荷	平均のアクティブ・セッション数が、CPUコア数の3倍を超えている場合
I/Oバウンド	アクティブ・セッションに対するI/Oの影響が単一ブロック読取りのパフォーマンスに基づいている場合
CPUバウンド	アクティブ・セッションが合計負荷の10%を超えていて、CPU使用率が50%を超えている場合
メモリーの過剰割当て	メモリー割当てが物理メモリーの95%を超えている場合
インターコネクト・バウンド	単一ブロックのインターコネクト転送時間に基づく場合
セッション制限	セッション制限が100%に近い場合
プロセス制限	プロセス制限が100%に近い場合
ハング・セッション	ハング・セッションが合計セッションの10%を超える場合
デッドロックの検出	デッドロックが検出された場合

関連項目:

DBA_HIST_REPORTSビューの詳細は、『Oracle Databaseリファレンス』を参照してください

リアルタイムADDMのトリガー・コントロール

自動トリガーが大量のシステム・リソースを消費したり、システムに負荷をかけたりしないように、リアルタイムADDMには、次のコントロールが用意されています。

レポート間の期間

自動トリガーによって、過去5分の間にリアルタイムADDMレポートが作成されている場合、新しいレポートは生成されません。
Oracle RACコントロール

自動トリガーはデータベース・インスタンスに対してローカルです。ロックが必要であり、実際にレポートが生成される前にMMONスレーブ・プロセスによって問合せが実行されるため、Oracle RACの場合、任意の時点でリアルタイムADDMレポートを作成できるのは1つのデータベース・インスタンスのみです。
繰返しトリガー

任意の問題に対する自動トリガーは、過去45分以内に起きた同じ問題のトリガーに関する前回のレポートと比較して、100%以上大きい影響があることが必要です。たとえば、8セッションの影響があるアクティブ・セッションに対してレポートがトリガーされた場合、その後45分以内に別のレポートをトリガーするには、少なくとも16のアクティブ・セッションが存在する必要があります。この場合、データベースでレポートされる問題は、時間の経過とともにより重大になっています。一方、同じレポートが45分ごとに1回生成されている場合、データベースには一定の影響がある問題が継続的に起きていることになります。
新しく識別された問題

(過去45分間には検出されていなかった)新しい問題が検出された場合は、新しいレポートが生成されます。たとえば、レポートが8つのアクティブ・セッションに対してトリガーされ、新しいデッドロックの問題が検出された場合、新しいアクティブ・セッションの負荷に関係なく、新しいレポートが生成されます。

ADDM分析の結果

ADDMでは、問題の診断に加えて可能な解決策も推奨されます。ADDMの分析結果は、一連の検出結果として表示されます。ADDMの分析結果の例は、例7-1を参照してください。ADDMの検出結果は、それぞれ次のタイプのいずれかに属します。

問題の検出結果では、データベース・パフォーマンスの問題の根本的な原因が記述されます。
症状の検出結果には、1つ以上の問題の検出につながる情報が含まれます。
情報の検出結果は、データベースのパフォーマンスの理解に役立つが、パフォーマンスの問題には関連しない情報(データベースの正常領域や、自動データベース・メンテナンスのアクティビティなど)をレポートする際に使用されます。
警告の検出結果には、ADDM分析の完全性や正確性に影響する可能性のある問題に関する情報(AWRの欠落データなど)が含まれます。

問題の検出結果はそれぞれ、影響によって数量化されます。この影響は、その検出結果のパフォーマンスの問題に起因するDB timeの割合を見積ったものです。問題の検出結果を推奨事項のリストに関連付けて、パフォーマンスの問題による影響を軽減できます。推奨事項のタイプは、次のとおりです。

ハードウェア変更: CPUの追加またはI/Oサブシステム構成の変更
データベース構成: 初期化パラメータ設定の変更
スキーマ変更: 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域管理(ASSM)の使用
アプリケーション変更: 順序のキャッシュ・オプションの使用またはバインド変数の使用
その他のアドバイザの使用: 高負荷SQLに対するSQLチューニング・アドバイザの実行、またはホット・オブジェクトに対するセグメント・アドバイザの実行

推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。推奨事項にはそれぞれメリットがあります。このメリットは、その推奨事項を実装した場合に節約できるDB timeの割合を見積ったものです。推奨は、アクションおよび論理で構成されます。見積られたメリットを得るためには、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアクションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使用されます。

ADDMの分析結果の確認: 例

例7-1に示すADDMレポートの次のセクションを検討します。

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

例7-1では、検出結果は特定の根本的な原因を示しています。SQL文のリテラルの使用は、分析期間中のDB time合計の約31%に影響があると見積られています。

この検出結果には、アクション1つおよび理論的根拠1つで構成される推奨事項が関連付けられています。アクションでは検出された問題の解決策が指定され、その最大メリットは分析期間中のDB timeの31%以内と見積られます。メリットは、検出結果の影響の割合ではなく、DB time合計の割合として表示されることに注意してください。理論的根拠は、リテラルを使用していてこのパフォーマンスの問題を引き起こした可能性のあるSQL文を追跡するための追加情報を提供します。データベース管理者は、問題の原因と思われるSQL文について指定の計画ハッシュ値を使用すると、少数のサンプル文をすばやく検査できます。

特定の問題に複数の原因がある場合は、ADDMにより複数の問題と症状の検出結果がレポートされることがあります。この場合、複数の検出結果による影響には、DB timeが同じ割合で含まれる可能性があります。検出結果のパフォーマンスの問題はオーバーラップしている場合があるため、検出結果の影響を合算すると、DB timeの100%を超える場合があります。たとえば、システムで多数の読取りが実行される場合、ADDMでは、I/OアクティビティによるDB timeの50%に関係するSQL文が1つの検出結果としてレポートされ、DB timeの75%に関係するサイズ不足のバッファ・キャッシュが別の検出結果としてレポートされる場合があります。

問題の検出結果に複数の推奨事項が関連付けられている場合は、それぞれに問題の代替解決策が含まれていることがあります。この場合、推奨事項によるメリットの合計は検出結果の影響よりも大きいことがあります。

該当する場合は、ADDMアクションで複数の解決策が推奨され、管理者はその中から選択できます。この例では、最も有効な解決策はバインド変数を使用することです。ただし、通常、アプリケーションを変更することは困難です。CURSOR_SHARING初期化パラメータの値を変更する方が実装が容易で、大幅な改善が可能です。

ADDMの設定

自動データベース診断モニターはデフォルトで有効になり、CONTROL_MANAGEMENT_PACK_ACCESSおよびSTATISTICS_LEVEL初期化パラメータにより制御されます。

自動データベース診断モニターを有効にするには、CONTROL_MANAGEMENT_PACK_ACCESSパラメータをDIAGNOSTICまたはDIAGNOSTIC+TUNINGに設定する必要があります。デフォルト設定はDIAGNOSTIC+TUNINGです。CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定すると、ADDMが無効になります。

自動データベース診断モニターを使用可能にするには、STATISTICS_LEVELパラメータをTYPICALまたはALLに設定する必要があります。デフォルトの設定はTYPICALです。STATISTICS_LEVELをBASICに設定すると、ADDMを含む多くのOracle Databaseの機能が無効化されるため、この方法はお薦めしません。

関連項目:

CONTROL_MANAGEMENT_PACK_ACCESSおよびSTATISTICS_LEVELの各初期化パラメータの詳細は、Oracle Databaseリファレンスを参照してください

I/OパフォーマンスのADDM分析は、単一の引数DBIO_EXPECTEDによって異なり、I/Oサブシステムの予測されるパフォーマンスを示しています。DBIO_EXPECTEDの値は、1つのデータベース・ブロックの読取りにかかる平均時間(マイクロ秒単位)です。Oracle Databaseではデフォルト値の10ミリ秒が使用されます。この値は、ほとんどの最新のハード・ドライブに適しています。非常に古いハードウェアや超高速のRAMディスクなど、ハードウェアが大きく異なっている場合は、他の値を使用することを検討してください。

DBIO_EXPECTEDパラメータの適切な設定を決定するには:

ハードウェアについて、1データベース・ブロックを読み取るための平均所要時間を測定します。

この測定の対象はランダムI/Oであり、標準ハード・ドライブを使用している場合はシーク時間が含まれることに注意してください。ハード・ドライブの標準の値は5000マイクロ秒から20000マイクロ秒です。
後続のすべてのADDM実行の値を一度設定します。

たとえば、測定値が8000マイクロ秒の場合は、次のコマンドをSYSユーザーとして実行する必要があります。
```
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
                     'ADDM', 'DBIO_EXPECTED', 8000);
```

ADDMを使用したデータベース・パフォーマンスの問題の診断

データベース・パフォーマンスの問題を診断するには、AWRスナップショットが取得されるたびに自動的に作成されるADDMの分析結果を最初に確認する必要があります。異なる分析が必要な場合(分析期間の延長、異なるDBIO_EXPECTED設定の使用、分析モードの変更など)、この項の手順に従って手動でADDMを実行できます。

ADDMでは、2つのAWRスナップショットが消去されずにAWRに保存されているかぎり、その(同じデータベース上の)2つのスナップショットを分析できます。ADDMで分析できるのは、開始スナップショットの前に開始され、終了スナップショットまで実行が継続していたインスタンスのみです。また、ADDMでは、AWRスナップショットの生成時に重大なエラーが発生したインスタンスは分析できません。このような場合、ADDMでは、重大な問題の発生していないインスタンスの最大のサブセットが分析されます。

診断モニターのプライマリ・インタフェースは、Cloud Controlです。可能なかぎり、ADDMは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の説明に従ってCloud Controlで実行する必要があります。Cloud Controlを使用できない場合は、DBMS_ADDMパッケージを使用してADDMを実行します。DBMS_ADDM APIを実行するには、ユーザーにADVISOR権限が付与されている必要があります。

この項では、次の項目について説明します。

関連項目:

DBMS_ADDMパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

データベース・モードでのADDMの実行

Oracle RAC構成の場合、データベース・モードでADDMを実行して、データベースのすべてのインスタンスを分析できます。単一インスタンス構成の場合も、データベース・モードでADDMを実行できますが、この場合、ADDMはインスタンス・モードと同じように動作します。

データベース・モードでADDMを実行するには、DBMS_ADDM.ANALYZE_DBプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_DB (
   task_name           IN OUT VARCHAR2,
   begin_snapshot      IN     NUMBER,
   end_snapshot        IN     NUMBER,
   db_id               IN     NUMBER := NULL);
END;
/

次の例では、データベース分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のデータベース全体のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
  :tname := 'ADDM for 7PM to 9PM';
  DBMS_ADDM.ANALYZE_DB(:tname, 137, 145);
END;
/

インスタンス・モードでのADDMの実行

データベースの特定のインスタンスを分析するには、インスタンス・モードでADDMを実行します。インスタンス・モードでADDMを実行するには、DBMS_ADDM.ANALYZE_INSTプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_INST (
   task_name           IN OUT VARCHAR2,
   begin_snapshot      IN     NUMBER,
   end_snapshot        IN     NUMBER,
   instance_number     IN     NUMBER := NULL,
   db_id               IN     NUMBER := NULL);
END;
/

task_nameパラメータでは、作成する分析タスクの名前を指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。instance_numberパラメータでは、分析するインスタンスのインスタンス番号を指定します。指定しない場合、このパラメータは、現在接続しているインスタンスのインスタンス番号にデフォルト設定されます。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。

次の例では、インスタンス分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のインスタンス番号1のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
  :tname := 'my ADDM for 7PM to 9PM';
  DBMS_ADDM.ANALYZE_INST(:tname, 137, 145, 1);
END;
/

部分モードでのADDMの実行

すべてのデータベース・インスタンスのサブセットを分析するには、部分モードでADDMを実行します。部分モードでADDMを実行するには、DBMS_ADDM.ANALYZE_PARTIALプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_PARTIAL (
   task_name           IN OUT VARCHAR2,
   instance_numbers    IN     VARCHAR2,
   begin_snapshot      IN     NUMBER,
   end_snapshot        IN     NUMBER,
   db_id               IN     NUMBER := NULL);
END;
/

task_nameパラメータでは、作成する分析タスクの名前を指定します。instance_numbersパラメータでは、分析するインスタンスのインスタンス番号のカンマ区切りリストを指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。

次の例では、部分分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のインスタンス番号1、2、4のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
  :tname := 'my ADDM for 7PM to 9PM';
  DBMS_ADDM.ANALYZE_PARTIAL(:tname, '1,2,4', 137, 145);
END;
/

ADDMレポートの表示

実行したADDMタスクのテキスト・レポートを表示するには、DBMS_ADDM.GET_REPORTファンクションを次のように使用します。

DBMS_ADDM.GET_REPORT (
   task_name           IN VARCHAR2
  RETURN CLOB);

次の例では、tname変数によるタスク名で指定されたADDMタスクのテキスト・レポートを表示します。

SET LONG 1000000 PAGESIZE 0;
SELECT DBMS_ADDM.GET_REPORT(:tname) FROM DUAL;

レポートの戻り値のタイプはCLOBであり、行サイズ(80)に合うように書式化されます。ADDMレポートでADDMの分析結果を確認する方法の詳細は、「ADDMの分析結果」を参照してください。

ADDMのビュー

通常、Cloud ControlまたはDBMS_ADDMパッケージのサブプログラムを使用してADDM分析を表示する必要があります。

ただし、DBA_ADDM_*ビューおよびDBA_ADVISOR_*ビューを使用してADDM情報を取得することもできます。このグループのビューには次のようなものがあります。

DBA_ADVISOR_FINDINGS

このビューには、すべてのアドバイザで取得されたすべての検出結果が表示されます。各検出結果は、関連する結果ID、名前およびタイプとともに表示されます。複数の実行に関連するタスクの場合、それぞれの検出結果に関連する各タスク実行の名前もリストされます。
DBA_ADDM_FINDINGS

このビューには、関連するDBA_ADVISOR_FINDINGSビューに表示される検出結果のサブセットが含まれます。このビューには、すべてのアドバイザで取得されたADDMの検出結果のみが表示されます。ADDMの各検出結果は、関連する結果ID、名前およびタイプとともに表示されます。
DBA_ADVISOR_FINDING_NAMES

このビューには、アドバイザ・フレームワークに登録されているすべての検出結果名がリストされます。
DBA_ADVISOR_RECOMMENDATIONS

このビューには、完了した診断タスクの結果と、実行ごとに識別された問題に対する推奨事項が表示されます。推奨事項は、RANK列の順序どおりに参照する必要があります。この順序が推奨事項における問題の重要性を伝えているためです。BENEFIT列には、推奨事項を実行した場合に予想される、システムに対するメリットが示されます。複数の実行に関連するタスクの場合、それぞれのアドバイザ・タスクに関連する各タスク実行の名前もリストされます。
DBA_ADVISOR_TASKS

このビューでは、タスクID、タスク名およびタスク作成日時など、既存のタスクに関する基本情報が示されます。複数の実行に関連するタスクの場合、それぞれのアドバイザ・タスクに関連する最後または現在の実行の名前とタイプもリストされます。

関連項目:

DBA_ADDM_*ビューおよびDBA_ADVISOR_*ビューの詳細は、Oracle Databaseリファレンスを参照してください
ADDMレポートの表示