| Oracle® Databaseパフォーマンス・チューニング・ガイド 12cリリース1 (12.1) B71276-05 |
|
 前 |
 次 |
この章では、Oracle Databaseの自動パフォーマンス診断およびチューニング機能について説明します。
この章の内容は次のとおりです。
関連項目:
Oracle Enterprise Manager Cloud Control (Cloud Control)で、自動データベース診断モニターを使用してデータベースの診断およびチューニングを行う方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください
データベースに問題が発生した場合、変更を加える前に問題を正確かつ適時に診断することが重要です。通常、データベース管理者(DBA)は単に症状を調べ、問題を修復するために即時にシステムの変更を開始します。ただし、実際の問題を初期段階で正確に診断すると、その解決に成功する可能性が大幅に向上します。
Oracle Databaseの場合、問題の正確な診断に必要な統計データは自動ワークロード・リポジトリ(AWR)に保存されます。自動データベース診断モニター(ADDM)では、次のことを実行できます。
AWRデータの定期的な分析
パフォーマンス問題の根本的な原因の診断
問題を修正するための推奨事項の提供
システムの正常領域の特定
AWRはパフォーマンスに関する履歴データのリポジトリであるため、ADDMでは、イベントの後にパフォーマンスの問題を分析でき、時間とリソースをかけて問題を再現する必要がありません。
多くの場合、データベース管理者はパフォーマンスの問題に関して通知を受け取った時点で、まずADDM出力を調べる必要があります。ADDMには次の利点があります。
デフォルトで1時間ごとの自動パフォーマンス診断レポート
数十人のチューニング専門家に基づく問題の診断
問題の影響と推奨事項による利点の時間ベースの数量化
症状ではなく根本的な原因の特定
問題の根本的な原因の処理に関する推奨事項
システムのうち正常な領域の特定
診断処理中のシステムに対する最小限のオーバーヘッド
チューニングは反復的なプロセスであり、ある問題を修復したことが原因でシステムの他の部分がボトルネックになる場合があります。ADDM分析による利点があるとしても、システム・パフォーマンスが許容レベルに達するまでには複数のチューニング・サイクルを必要とする場合があります。ADDMによる利点は本番システムに適用されるのみでなく、開発およびテスト・システムでもパフォーマンスの問題を早期に警告できます。
この項の内容は次のとおりです。
注意:
プラガブル・データベース(PDB)とともにADDM機能を使用している場合には、データ可視性および権限の要件が異なります。ADDM機能を含む管理性の機能がマルチテナント・コンテナ・データベース(CDB)で機能する仕組みの詳細は、『Oracle Database管理者ガイド』を参照してください。
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を使用するか、SQL*Plusセッションでレポートを表示することで結果を確認できます。
ADDM分析は、トップダウン方式で実行され、最初に症状を識別し、次にパフォーマンスの問題の根本的な原因に到達するまで精査します。分析の目標は、DB timeと呼ばれる1つのスループット・メトリックを減少させることです。DB timeは、データベース・パフォーマンスの基本的な測定基準で、データベースがユーザー・リクエストの処理に費やした累積時間を表します。これには、アイドル状態でないすべてのユーザー・セッションの待機時間とCPU時間が含まれます。DB timeは、V$SESS_TIME_MODELビューおよびV$SYS_TIME_MODELビューに表示されます。
関連項目:
V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
時間モデル統計およびDB timeの詳細は、「時間モデル統計」を参照してください
サーバー・プロセスの詳細は、『Oracle Database概要』を参照してください。
DB timeの短縮により、データベースで同じリソースを使用してサポートできるユーザー・リクエストの数が増加し、スループットが改善されます。ADDMによりレポートされる問題は、それに関係するDB timeの量でソートされます。DB timeの大部分に関係しないシステム領域は、正常領域としてレポートされます。
CPUのボトルネック: システムCPUがOracle Databaseまたは他のアプリケーションによりバインドされているかどうか。
過小なメモリー構造: SGA、PGA、バッファ・キャッシュなど、Oracle Databaseメモリー構造が十分なサイズに設定されているかどうか。
I/O能力の問題: I/Oサブシステムが予想どおりに動作しているかどうか。
高負荷のSQL文: システム・リソースを過剰に使用しているSQL文があるかどうか。
高負荷のPL/SQL実行およびコンパイルと、高負荷のJavaの使用
Oracle RAC固有の問題: グローバル・キャッシュのホット・ブロックおよびオブジェクトの問題、相互接続遅延の問題があるかどうか。
アプリケーションによるOracle Databaseの不適切な使用: 不適切な接続管理、過剰な解析またはアプリケーション・レベルのロック競合による問題があるかどうか。
データベース構成の問題: 不適切なログ・ファイル・サイズの設定、アーカイブの問題、過剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。
同時実行性の問題: バッファ・ビジーの問題があるかどうか。
様々な問題領域のホット・オブジェクトおよび上位SQL。
注意:
これは、ADDMの分析で考慮されるすべての問題タイプの包括的なリストではありません。
ADDMでは、システムの正常領域もドキュメント化されます。たとえば、システムのパフォーマンスにほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から削除されます。これにより、システム全体のパフォーマンスに影響しない項目に費やされる時間および労力が節約されます。
Oracle RACを使用する場合は、データベース分析モードでADDMを実行して、すべてのデータベース・インスタンスのスループット・パフォーマンスを分析します。データベース・モードでは、ADDMによりDB時間はすべてのデータベース・インスタンスのデータベース時間の合計とみなされます。データベース分析モードを使用すると、データベース全体にとって重要なすべての検出結果が単一のレポートに表示されます(各インスタンスの個別レポートは表示されません)。
データベース・モードのレポートには、データベース・リソース(I/Oやインターコネクトなど)に関する検出結果が含まれます。レポートには、データベース全体にとって重要な場合は、様々なインスタンスからの検出結果も集計されます。たとえば、単一のインスタンスに対するCPU負荷が高く、データベース全体に影響する場合、データベース・モード分析に、問題の原因である特定のインスタンスを示す検出結果が表示されます。
関連項目:
Oracle RACでADDMを使用する方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。
Oracle Enterprise Manager Cloud Control 12cで導入されたリアルタイムADDMを使用すると、これまではデータベースの再起動が必要であった、応答しないデータベースやハングしているデータベースの問題を分析および解決できます。リアルタイムADDMは、事前定義された一連の基準を調査し、データベースの現在の問題を分析します。問題の分析後は、リアルタイムADDMにより、デッドロック、ハング、共有プールの競合やその他の例外的な状況などの特定された問題を、データベースを再起動することなく解決できます。
この項では、リアルタイムADDMについて説明しており、内容は次のとおりです。
関連項目:
Cloud ControlでリアルタイムADDMを使用する方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください
Enterprise Managerを使用してデータベースに接続する際、リアルタイムADDMではデータベースの状態に応じて、2つの異なるタイプの接続モードが使用されます。
通常接続
このモードでは、リアルタイムADDMにより、データベースへの通常のJDBC接続が実行されます。このモードは、一部の接続が利用できる場合に、広範囲にわたるパフォーマンス分析を行うことを目的としています。
診断接続
このモードでは、リアルタイムADDMにより、データベースへのラッチレス接続が実行されます。このモードは、通常のJDBC接続を実行できない極端なハング状況で使用します。
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には、次のコントロールが用意されています。
レポート間の期間
自動トリガーによって、過去5分の間にリアルタイムADDMレポートが作成されている場合、新しいレポートは生成されません。
Oracle RACコントロール
自動トリガーはデータベース・インスタンスに対してローカルです。ロックが必要であり、実際にレポートが生成される前にMMONスレーブ・プロセスによって問合せが実行されるため、Oracle RACの場合、任意の時点でリアルタイムADDMレポートを作成できるのは1つのデータベース・インスタンスのみです。
繰返しトリガー
任意の問題に対する自動トリガーは、過去45分以内に起きた同じ問題のトリガーに関する前回のレポートと比較して、100%以上大きい影響があることが必要です。たとえば、8セッションの影響があるアクティブ・セッションに対してレポートがトリガーされた場合、その後45分以内に別のレポートをトリガーするには、少なくとも16のアクティブ・セッションが存在する必要があります。この場合、データベースでレポートされる問題は、時間の経過とともにより重大になっています。一方、同じレポートが45分ごとに1回生成されている場合、データベースには一定の影響がある問題が継続的に起きていることになります。
新しく識別された問題
(過去45分間には検出されていなかった)新しい問題が検出された場合は、新しいレポートが生成されます。たとえば、レポートが8つのアクティブ・セッションに対してトリガーされ、新しいデッドロックの問題が検出された場合、新しいアクティブ・セッションの負荷に関係なく、新しいレポートが生成されます。
ADDMでは、問題の診断に加えて可能な解決策も推奨されます。ADDMの分析結果は、一連の検出結果として表示されます。ADDMの分析結果の例は、例7-1を参照してください。ADDMの検出結果は、それぞれ次のタイプのいずれかに属します。
問題の検出結果では、データベース・パフォーマンスの問題の根本的な原因が記述されます。
症状の検出結果には、1つ以上の問題の検出につながる情報が含まれます。
情報の検出結果は、データベースのパフォーマンスの理解に役立つが、パフォーマンスの問題には関連しない情報(データベースの正常領域や、自動データベース・メンテナンスのアクティビティなど)をレポートする際に使用されます。
警告の検出結果には、ADDM分析の完全性や正確性に影響する可能性のある問題に関する情報(AWRの欠落データなど)が含まれます。
問題の検出結果はそれぞれ、影響によって数量化されます。この影響は、その検出結果のパフォーマンスの問題に起因するDB timeの割合を見積ったものです。問題の検出結果を推奨事項のリストに関連付けて、パフォーマンスの問題による影響を軽減できます。推奨事項のタイプは、次のとおりです。
ハードウェア変更: CPUの追加またはI/Oサブシステム構成の変更
データベース構成: 初期化パラメータ設定の変更
スキーマ変更: 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域管理(ASSM)の使用
アプリケーション変更: 順序のキャッシュ・オプションの使用またはバインド変数の使用
その他のアドバイザの使用: 高負荷SQLに対するSQLチューニング・アドバイザの実行、またはホット・オブジェクトに対するセグメント・アドバイザの実行
推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。推奨事項にはそれぞれメリットがあります。このメリットは、その推奨事項を実装した場合に節約できるDB timeの割合を見積ったものです。推奨は、アクションおよび論理で構成されます。見積られたメリットを得るためには、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアクションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使用されます。
例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初期化パラメータの値を変更する方が実装が容易で、大幅な改善が可能です。
自動データベース診断モニターはデフォルトで有効になり、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マイクロ秒です。
たとえば、測定値が8000マイクロ秒の場合は、次のコマンドをSYSユーザーとして実行する必要があります。
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
データベース・パフォーマンスの問題を診断するには、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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
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; /
task_nameパラメータでは、作成する分析タスクの名前を指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。
次の例では、データベース分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のデータベース全体のパフォーマンスを診断します。
VAR tname VARCHAR2(30); BEGIN :tname := 'ADDM for 7PM to 9PM'; DBMS_ADDM.ANALYZE_DB(:tname, 137, 145); END; /
データベースの特定のインスタンスを分析するには、インスタンス・モードで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を実行するには、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タスクのテキスト・レポートを表示するには、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またはADDMレポートを使用して参照する必要があります。
ただし、ADDM情報はDBA_ADVISORビューを使用して表示できます。このグループのビューには次のようなものがあります。
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、タスク名およびタスク作成日時など、既存のタスクに関する基本情報が示されます。複数の実行に関連するタスクの場合、それぞれのアドバイザ・タスクに関連する最後または現在の実行の名前とタイプもリストされます。
関連項目:
静的データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
