| Oracle® Database 2日でパフォーマンス・チューニング・ガイド 11gリリース2(11.2) B56313-03 |
|
 前 |
 次 |
一時的なパフォーマンスの問題は短期間のみ継続するため、通常、自動データベース診断モニター(ADDM)の分析には表示されません。分析期間中は、DB時間に対する影響が最も重大なパフォーマンスの問題がADDMによってレポートされます。問題が非常に短い期間のみ続いた場合、その問題の重大度は分析期間全体の他のパフォーマンスの問題によって、平均以下になるかまたは最小限に抑えられます。このため、その問題はADDMの検出結果に表示されません。パフォーマンスの問題がADDMによって取得されるかどうかは、自動ワークロード・リポジトリ(AWR)のスナップショット間の間隔とパフォーマンスの問題が発生した期間の比によって決定します。
スナップショット間で相当な時間続くパフォーマンスの問題の場合、ADDMにより取得されます。たとえば、スナップショット間隔が1時間の場合、30分間続くパフォーマンスの問題は、この期間がスナップショット間隔で相当な時間を占め、ADDMにより取得される可能性が高いため、一時的なパフォーマンスの問題と考えるのは不適切です。
一方、2分間続くパフォーマンスの問題は、発生期間がスナップショット間隔に占める割合が小さいためADDMの検出結果に現れにくく、一時的なパフォーマンスの問題と言えます。たとえば、午後10時ちょうどから午後10時10分の間システムが遅くなったが、午後10時から午後11時の期間のADDM分析にはパフォーマンスの問題がなかった場合、10分間隔のレポートのうちわずか数分のみ一時的なパフォーマンスの問題が発生した可能性があります。
この章の内容は次のとおりです。
データベース・アクティビティの詳細な履歴を取得するには、Oracle Databaseでは、アクティブ・セッション履歴(ASH)の検査員によってアクティブ・セッションが毎秒サンプリングされます。AWRのスナップショットの処理によってサンプリングされたデータがメモリーに収集され、永続記憶域に書き込まれます。ASHはOracle Databaseの自己管理フレームワークに不可欠であり、パフォーマンスの問題の診断に非常に役立ちます。
ASHでは、インスタンス・レベルではなくセッション・レベルでサンプル・データが収集されます。アクティブ・セッションのみに対する統計を取得すると、ASHでは管理しやすいデータのセットが収集されます。このデータのサイズは、データベース・インスタンス全体のサイズではなく実行されている作業に直接関連するサイズです。
ASHによって取得されたサンプル・データは、データのディメンションに基づいて集計できます。次のものが含まれます。
SQL文のSQL識別子
オブジェクト番号、ファイル番号およびブロック番号
待機イベント識別子およびパラメータ
セッション識別子およびセッション・シリアル番号
モジュールおよびアクション名
セッションのクライアント識別子
サービス・ハッシュ識別子
ASHレポートを実行して、特定の期間にのみ発生するデータベースの一時的なパフォーマンスの問題を分析できます。この手法は次のいずれかを試す場合に特に有効です。
特定のジョブまたはセッションが応答しないがインスタンスの他の部分は通常どおりに動作している場合など、発生期間が短い一時的なパフォーマンスの問題を解決する
時間、セッション、モジュール、アクション、SQL識別子など、様々なディメンションおよびその組合せで指定範囲または特定のターゲットのパフォーマンス分析を実行する
この項では、Oracle Enterprise Manager(Enterprise Manager)を使用してASHレポートを生成する方法について説明します。
「パフォーマンス」ページの「平均アクティブ・セッション」で、「ASHレポートの実行」をクリックします。
「ASHレポートの実行」ページが表示されます。
一時的なパフォーマンスの問題が発生した場合の期間の開始および終了の日時を入力します。
この例では、午後2時30分から午後2時35分までの間にデータベース・アクティビティが増えているため、この期間のASHレポートを作成する必要があります。
「レポートを生成」をクリックします。
レポートの生成中に「処理中: レポートの表示」ページが表示されます。
レポートが生成されると、ASHレポートが「ASHレポートの実行」ページの「レポート結果」の下に表示されます。
オプションで、「ファイルに保存」をクリックして、今後の分析のためにHTML形式でレポートを保存します。
ASHレポートを使用して一時的なパフォーマンスの問題の原因を識別できます。このレポートは、タイトルの付いた複数のセクションに分割されています。調査を開始する際に役立つASHレポートのセクションは、次のとおりです。
|
参照:
|
レポートの「上位イベント」セクションにはユーザー、バックグラウンドおよび優先順位によって分類され、サンプリングされたセッション・アクティビティの上位の待機イベントが表示されます。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある待機イベントを識別します。
「上位イベント」セクションには次のサブセクションが含まれます。
レポートの「上位ユーザー・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占める、クライアント・プロセスから上位の待機イベントをリストします。
図7-1は、ほとんどのデータベース・アクティビティがCPU + Wait for CPUイベントによって消費されていることを示しています。Wait for CPUは、オペレーティング・システムの実行キューでのプロセスによる経過時間です。%Event列には、このイベントで消費されるDB時間の割合が表示されます。この例では、30%を超えるDB時間が、CPUでまたは待機のために消費されています。「ロード・プロファイル」セクションを確認して、このCPU消費が発生しているアクティビティのタイプを判別する必要があります。
「上位バックグラウンド・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占めるバックグラウンド・イベントから上位の待機イベントをリストします。
図7-2の例は、サンプリングされたセッション・アクティビティの22.81%がCPU + Wait for CPUイベントによって消費されていることを示しています。
レポートの「ロード・プロファイル」セクションでは、サンプリングされたセッション・アクティビティで分析された負荷を説明します。このセクションの情報を使用して、一時的なパフォーマンスの問題の原因となるサービス、クライアントまたはSQLコマンド・タイプを識別します。
「上位サービス/モジュール」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるサービスおよびモジュールがリストされます。サービスは、共通の機能、品質要求、優先順位を共有する、関連するデータベース・タスクのグループです。サービスは、複数のアプリケーションを監視する場合に役立ちます。SYS$USERSおよびSYS$BACKGROUNDサービスは常に定義されています。
図7-3は、半数を超えるデータベース・アクティビティが、SQL*Plusモジュールを実行するSYS$USERSサービスによって消費されていることを示しています。この例では、図7-1に示されたパフォーマンスの問題の原因となっている高負荷のSQLをユーザーが実行していることがわかります。レポートの「上位SQL」セクションで分析して、特定のタイプのSQL文に負荷がかかっているかどうかを判別する必要があります。
レポートの「上位SQL」セクションでは、サンプリングされたセッション・アクティビティの上位SQL文を説明します。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある高負荷SQL文を識別します。「上位イベントのある上位SQL」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるSQL文がリストされます。「実行のサンプリング数」列に、特定のSQL文ごとに実行のサンプリング数が表示されます。SQL文のテキストを表示するには、「SQL ID」リンクをクリックします。
図7-4は、半分を超えるDB時間が、3つのDML文によって消費されていることを示しています。これらの文は、図7-3に示されたSQL*Plusモジュールで実行されています。「上位セッション」セクションを分析して、これらの文を実行するセッションを識別する必要があります。
「上位セッション」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占める待機イベントを待機していたセッションが表示されます。この情報を使用して、パフォーマンスの問題の原因になっている可能性があるセッションを識別します。
「アクティブなサンプル数」列は、特定のイベントに対してセッションが待機しているASHサンプルの数を示します。この割合は、実時間に基づいて計算されます。
図7-5で、「アクティブなサンプル数」列は、ASHがデータベース・アクティビティをサンプリングした300回のうち、HRセッション(SID 123)によって、順次読取りが243回、フラッシュバック操作が36回実行されたことを示しています。したがって、HRは少なくとも93%の時間、アクティブであったことになります。SHセッションを含む他のセッションもアクティブであったため、このセッションは全アクティビティの27%(93%より大幅に少ないアクティビティ)を消費しました。
図7-4では、HRおよびSHセッションが高負荷SQL文を実行していることがわかります。このセッションを調査し、適切な操作が実行されているかどうか、また可能であればSQL文がチューニングされているかどうかを判別する必要があります。SQL文のチューニングができず、システムで許容できないパフォーマンスの問題が発生した場合は、セッションの終了を検討します。
「上位DBオブジェクト」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるデータベース・オブジェクト(表や索引など)がリストされます。
図7-6の例は、hr.departmentsおよびhr.employees表がアクティビティの高い割合を占めていることを示しています。エンキュー待機は、ロックに対する待機です。この例では、TM(表)ロックに対する待機です。これらの待機は索引付けされていない外部キー制約を示す場合があります。バッファ・ビジー待機イベント・レコードは、バッファが利用可能になるまで待機します。これらの待機は、バッファ・キャッシュ内の同じバッファに対して、複数のプロセスが同時にアクセスを試みていることを示しています。
「上位DBファイル」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるデータベース・ファイルがリストされます。ここでは、クラスタ・イベントとI/Oイベントのみが対象になります。「%イベント」列では、イベント単位でアクティビティが分類されるため、表内に複数の行がある場合は、サンプリングされたアクティビティが複数のイベントに分割されます。
図7-7は、約11%のDB時間がUNDOTBS表領域の待機に関連していることを示しています。この情報は、複数のセッションによる多数のDMLアクティビティがあることを示す図7-4と一致しています。
ASHレポートの「一定時間のアクティビティ」セクションでは、分析期間中のアクティビティおよびワークロード・プロファイルの徹底した詳細が参照できるため、長い期間に特に役立ちます。「一定時間のアクティビティ」セクションはタイム・スロットに分割されています。期間が短いかデータがわずかである場合を除き、ASHのレポート期間は10のタイム・スロットに分割されます。
図7-8は、午後2時10分から午後2時40分までの期間のアクティビティ・レポートを示しています。このレポートは、サンプリングされたセッションの数が5番目の内部スロット(午後2時24分)で急激に増加し、高いまま保持されたことを示しています。この期間に、CPUアクティビティとロックのエンキュー待機が大幅に増大しています。
表7-1に示すように、各タイム・スロットにはセッションと待機イベント・アクティビティが含まれています。
表7-1 一定時間のアクティビティ
| 列 | 説明 |
|---|---|
|
スロット時間(継続時間) |
スロットの期間 |
|
スロット数 |
スロット内のサンプリングされたセッションの数 |
|
イベント |
スロット内の上位3つの待機イベント |
|
イベント数 |
待機イベントを待機中のASHサンプルの数 |
|
%イベント |
分析期間全体での待機イベントを待機していたASHサンプルの割合 |
すべての内部スロットは、比較しやすいようにそれぞれ同じ分数になっています。最初と最後のスロットである外部スロットは、固定スロット時間を持たないため、サイズが異なります。
図7-8では、最初の外部スロットの継続時間は1.2分で、最後の外部スロットの継続時間は1.8分になっています。各内部スロットの継続時間は3.0分です。
内部スロットを比較する場合は、スパイクを識別して偏りの分析を実行します。「スロット数」列のスパイクは、アクティブ・セッションの増加と、データベース・ワークロードの相対的な増加を示します。「イベント数」列のスパイクは、イベントを待機するサンプリングされたセッション数の増加を示します。通常、アクティブ・セッションのサンプルの数および待機イベントに関連付けられたセッションの数が増えた場合、スロットは一時的なパフォーマンスの問題の原因となる可能性があります。
次の手順は、発生した時点の重大なパフォーマンスの問題を診断する際に役立ちます。これにより、システムの再起動以外の問題の解決処置を見つけやすくなります。
パフォーマンス・ホームページから「パフォーマンス」メニューを選択し、緊急監視を選択します。
緊急パフォーマンス・ページが表示され、収集されたASHデータが表示されます。また、このページの「ハング分析」表には、ブロックしている上位セッションが示されています。
このページに表示された情報が問題解決に役立たない場合は、次のステップに進みます。
「パフォーマンス」メニューを選択し、リアルタイムADDMを選択します。
リアルタイムADDMページから「開始」をクリックします。
すべてのターゲット・データベース・インスタンスからパフォーマンス・データが収集され、問題の診断および解決のためにデータが分析され、分析の結果が表示されます。
分析によって検出されたすべての結果に関する明確なインタラクティブ・サマリーが表示される「結果」タブをクリックして、実行可能な推奨事項を表示します。
オプション: 「保存」をクリックし、オフライン参照用のHTMLファイルとして現在のページ・ビューを保存します。「保存」をクリックすると、ポップアップ・ウィンドウが表示され、レポートの保存場所を指定できます。このアクションにより、分析の一部として現在収集されているすべてのデータを網羅するEnterprise Managerアクティブ・レポートが作成されます。後でこれを使用して、たとえば、より綿密な事後分析を実行できます。Enterprise Managerまたはデータベース接続を使用しないでレポートを表示できます。
「メール」をクリックして、添付ファイルとしてレポートを送信する電子メール・アドレスも指定できます。
例
現在データベースに重大なパフォーマンスの問題が発生しているので、緊急パフォーマンス・ページのリンクをクリックします。
ASHやハング分析でも根本原因が示されずクイック・ソリューションも提示されないため、「緊急ADDM」をクリックします。
緊急ADDMによって生成されたアクティブ・レポートが表示され、おそらくはリークが原因で、セッションS1による過度のPGA消費のためにページングが行われていることが示されます。レポートでは、S1を即時終了することが推奨されます。
セッションS1を終了してから、緊急パフォーマンス・ページに戻り、通常のシステム動作がリストアされたかどうかを確認します。
ページ上のアクティビティ・グラフからシステムの状態が良好に進展していることがわかります。
通常のパフォーマンス・ホームページに戻り、データベースのパフォーマンスが向上したことを確認します。
