この章では、Oracle Databaseの自動パフォーマンス診断およびチューニング機能について説明します。
この章には次の項があります。
関連項目: Oracle Enterprise Managerを使用して自動データベース診断モニターでデータベースを診断およびチューニングする方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。 |
システムに問題が発生した場合、システムに変更を加える前に問題を正確かつ適時に診断することが重要です。通常、データベース管理者(DBA)は単に症状を調べ、問題を修復するために即時にシステムの変更を開始します。ただし、実際の問題を初期段階で正確に診断すると、その解決に成功する可能性が大幅に向上します。
Oracle Databaseの場合、問題の正確な診断に必要な統計データは自動ワークロード・リポジトリ(AWR)に保存されます。自動データベース診断モニター(ADDM)の機能は、次のとおりです。
AWRデータの定期的な分析
パフォーマンス問題の根本的な原因の診断
問題を修正するための推奨事項の提供
システムの正常領域の特定
AWRはパフォーマンスに関する履歴データのリポジトリであるため、ADDMでは、イベントの後にパフォーマンスの問題を分析でき、時間とリソースをかけて問題を再現する必要がありません。AWRの詳細は、「自動ワークロード・リポジトリの概要」を参照してください。
多くの場合、データベース管理者はパフォーマンスの問題に関して通知を受け取った時点で、まずADDM出力を調べる必要があります。ADDMには次の利点があります。
デフォルトで1時間ごとの自動パフォーマンス診断レポート
数十人のチューニング専門家に基づく問題の診断
問題の影響と推奨事項による利点の時間ベースの数量化
症状ではなく根本的な原因の特定
問題の根本的な原因の処理に関する推奨事項
システムのうち正常な領域の特定
診断処理中のシステムに対する最小限のオーバーヘッド
チューニングは反復的なプロセスであり、ある問題を修復したことが原因でシステムの他の部分へのシフトにボトルネックが発生する可能性があることを認識することが重要です。ADDM分析による利点があるとしても、システム・パフォーマンスが許容レベルに達するまでには複数のチューニング・サイクルを必要とする場合があります。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による分析の完了後、Oracle Enterprise Managerを使用するか、SQL*Plusセッションでレポートを表示することで結果を確認できます。
ADDM分析は、トップダウン方式で実行され、最初に症状を識別し、次にパフォーマンスの問題の根本的な原因に到達するまで精査します。分析の目標は、DB
time
と呼ばれる1つのスループット・メトリックを減少させることです。DB
time
は、データベースでユーザー・リクエストの処理に費やされた累積時間です。これには、アイドル状態でないすべてのユーザー・セッションの待機時間とCPU時間が含まれます。DB
time
は、V$SESS_TIME_MODEL
ビューおよびV$SYS_TIME_MODEL
ビューに表示されます。
関連項目:
|
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ガイド』を参照してください。 |
ADDMでは、問題の診断に加えて可能な解決策も推奨されます。ADDMの分析結果は、一連の検出結果として表示されます。ADDMの分析結果の例は、例6-1を参照してください。ADDMの検出結果は、それぞれ次のタイプのいずれかに属します。
問題の検出結果では、データベース・パフォーマンスの問題の根本的な原因が記述されます。
症状の検出結果には、1つ以上の問題の検出につながる情報が含まれます。
情報の検出結果は、データベースのパフォーマンスの理解に役立つが、パフォーマンスの問題には関連しない情報(データベースの正常領域や、自動データベース・メンテナンスのアクティビティなど)をレポートする際に使用されます。
警告の検出結果には、ADDM分析の完全性や正確性に影響する可能性のある問題に関する情報(AWRの欠落データなど)が含まれます。
問題の検出結果はそれぞれ、影響によって数量化されます。この影響は、その検出結果のパフォーマンスの問題に起因するDB
time
の割合を見積ったものです。問題の検出結果を推奨事項のリストに関連付けて、パフォーマンスの問題による影響を軽減できます。推奨事項のタイプは、次のとおりです。
ハードウェア変更: CPUの追加またはI/Oサブシステム構成の変更
データベース構成: 初期化パラメータ設定の変更
スキーマ変更: 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域管理(ASSM)の使用
アプリケーション変更: 順序のキャッシュ・オプションの使用またはバインド変数の使用
その他のアドバイザの使用: 高負荷SQLに対するSQLチューニング・アドバイザの実行、またはホット・オブジェクトに対するセグメント・アドバイザの実行
推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。推奨事項にはそれぞれメリットがあります。このメリットは、その推奨事項を実装した場合に節約できるDB
time
の割合を見積ったものです。推奨は、アクションおよび論理で構成されます。見積られたメリットを得るためには、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアクションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使用されます。
例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.
例6-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
パラメータの適切な設定を判断する手順は、次のとおりです。
データベース・パフォーマンスの問題を診断するには、AWRスナップショットが取得されるたびに自動的に作成されるADDMの分析結果を最初に確認する必要があります。異なる分析が必要な場合(分析期間の延長、異なるDBIO_EXPECTED
設定の使用、分析モードの変更など)、この項の手順に従って手動でADDMを実行できます。
ADDMでは、2つのAWRスナップショットが消去されずにAWRに保存されているかぎり、その(同じデータベース上の)2つのスナップショットを分析できます。ADDMで分析できるのは、開始スナップショットの前に開始され、終了スナップショットまで実行が継続していたインスタンスのみです。また、ADDMでは、AWRスナップショットの生成時に重大なエラーが発生したインスタンスは分析できません。このような場合、ADDMでは、重大な問題の発生していないインスタンスの最大のサブセットが分析されます。
診断モニターの主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、ADDMは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで実行する必要があります。Oracle Enterprise Managerが使用できない場合、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;
レポートの戻り型は、行サイズ80に合うよう書式設定されたCLOB
です。ADDMレポートでADDMの分析結果を確認する方法の詳細は、「ADDMの分析結果」を参照してください。
通常、ADDMの出力結果や情報は、Oracle Enterprise Managerまたは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リファレンス』を参照してください。 |