8 一時的なパフォーマンスの問題の解決
一時的なパフォーマンスの問題は短期間のみ継続するため、通常、自動データベース診断モニター(ADDM)の分析には表示されません。ADDMによって分析期間中は、データベース時間(DB時間)に対する影響が最も重大なパフォーマンスの問題がレポートされます。問題が非常に短い期間のみ続いた場合、その問題の重大度は分析期間全体の他のパフォーマンスの問題によって、平均以下になるかまたは最小限に抑えられます。このため、その問題は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識別子など、様々なディメンションおよびその組合せで指定範囲または特定のターゲットのパフォーマンス分析を実行する
参照:
-
ASHレポートの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
アクティブ・セッション履歴レポートの実行
この項では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してASHレポートを生成する方法について説明します。
ASHレポートを実行するには:
-
データベース・ホームページにアクセスします。
詳細は、「データベースのホームページのアクセス」を参照してください。
-
「パフォーマンス」メニューから、「パフォーマンス・ホーム」を選択します。
「データベース・ログイン」ページが表示されたら、管理者権限のあるユーザーとしてログインします。「パフォーマンス」ページが表示されます。
-
「平均アクティブ・セッション」で、「ASHレポートの実行」をクリックします。
「ASHレポートの実行」ページが表示されます。
-
一時的なパフォーマンスの問題が発生した場合の期間の開始および終了の日時を入力します。
この例では、午後9時15分から午後9時20分までの間にデータベース・アクティビティが増えているため、この期間のASHレポートを作成する必要があります。
-
「レポートを生成」をクリックします。
レポートの生成中に「処理中: レポートの表示」ページが表示されます。
レポートが生成されると、ASHレポートが「ASHレポートの実行」ページの「レポート結果」の下に表示されます。
参照:
一部のレポートの説明は、「アクティブ・セッション履歴レポート」を参照してください。
-
オプションで、「ファイルに保存」をクリックして、今後の分析のためにHTML形式でレポートを保存します。
アクティブ・セッション履歴レポート
ASHレポートを使用して一時的なパフォーマンスの問題の原因を識別できます。このレポートは、タイトルの付いた複数のセクションに分割されています。調査を開始する際に役立つASHレポートのセクションは、次のとおりです。
参照:
-
ASHレポートの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
上位イベント
レポートの「上位イベント」セクションにはユーザー、バックグラウンドおよび優先順位によって分類され、サンプリングされたセッション・アクティビティの上位の待機イベントが表示されます。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある待機イベントを識別します。
「上位イベント」セクションには次のサブセクションが含まれます。
上位ユーザー・イベント
レポートの「上位ユーザー・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占める、クライアント・プロセスから上位の待機イベントをリストします。
図8-1は、ほとんどのデータベース・アクティビティがCPU + Wait for CPU
イベントによって消費されていることを示しています。Wait for CPUは、オペレーティング・システムの実行キューでのプロセスによる経過時間です。%Event
列には、このイベントで消費されるDB時間の割合が表示されます。この例では、30%を超えるDB時間が、CPUでまたは待機のために消費されています。「ロード・プロファイル」セクションを確認して、このCPU消費が発生しているアクティビティのタイプを判別する必要があります。
上位バックグラウンド・イベント
「上位バックグラウンド・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占めるバックグラウンド・イベントから上位の待機イベントをリストします。
図8-2の例は、サンプリングされたセッション・アクティビティの22.81%がCPU + Wait for CPU
イベントによって消費されていることを示しています。
ロード・プロファイル
レポートの「ロード・プロファイル」セクションでは、サンプリングされたセッション・アクティビティで分析された負荷を説明します。このセクションの情報を使用して、一時的なパフォーマンスの問題の原因となるサービス、クライアントまたはSQLコマンド・タイプを識別します。
「上位サービス/モジュール」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるサービスおよびモジュールがリストされます。サービスは、共通の機能、品質要求、優先順位を共有する、関連するデータベース・タスクのグループです。サービスは、複数のアプリケーションを監視する場合に役立ちます。SYS$USERS
およびSYS$BACKGROUND
サービスは常に定義されています。
図8-3は、半数を超えるデータベース・アクティビティが、SQL*Plusモジュールを実行するSYS$USERS
サービスによって消費されていることを示しています。この例では、図8-1に示されたパフォーマンスの問題の原因となっている高負荷のSQLをユーザーが実行していることがわかります。レポートの「上位SQL」セクションで分析して、特定のタイプのSQL文に負荷がかかっているかどうかを判別する必要があります。
参照:
上位SQL
レポートの「上位SQL」セクションでは、サンプリングされたセッション・アクティビティの上位SQL文を説明します。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある高負荷SQL文を識別します。「上位イベントのある上位SQL」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるSQL文がリストされます。「実行のサンプリング数」列に、特定のSQL文ごとに実行のサンプリング数が表示されます。SQL文のテキストを表示するには、「SQL ID」リンクをクリックします。
図8-4は、半分を超えるDB時間が、3つのDML文によって消費されていることを示しています。これらの文は、図8-3に示されたSQL*Plusモジュールで実行されています。「上位セッション」セクションを分析して、これらの文を実行するセッションを識別する必要があります。
参照:
-
「上位SQLの監視」
上位セッション
「上位セッション」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占める待機イベントを待機していたセッションが表示されます。この情報を使用して、パフォーマンスの問題の原因になっている可能性があるセッションを識別します。
「アクティブなサンプル数」
列は、特定のイベントに対してセッションが待機しているASHサンプルの数を示します。この割合は、実時間に基づいて計算されます。
図8-5で、「アクティブなサンプル数」
列は、ASHがデータベース・アクティビティをサンプリングした300回のうち、HR
セッション(SID 123)によって、順次読取りが243回、フラッシュバック操作が36回実行されたことを示しています。したがって、HR
は少なくとも93%の時間、アクティブであったことになります。SH
セッションを含む他のセッションもアクティブであったため、このセッションは全アクティビティの27%(93%より大幅に少ないアクティビティ)を消費しました。
図8-4では、HR
およびSH
セッションが高負荷SQL文を実行していることがわかります。このセッションを調査し、適切な操作が実行されているかどうか、また可能であればSQL文がチューニングされているかどうかを判別する必要があります。SQL文のチューニングができず、システムで許容できないパフォーマンスの問題が発生した場合は、セッションの終了を検討します。
参照:
上位DBオブジェクト/ファイル/ラッチ
「Top Objects/Files/Latches」セクションでは最も使用されるデータベース・リソースに関する詳細が提供されます。また、次のサブセクションが含まれます。
上位DBオブジェクト
「上位DBオブジェクト(Top DB Objects)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるデータベース・オブジェクト(表や索引など)を示します。
図8-6の例は、hr.departments
およびhr.employees
表がアクティビティの高い割合を占めていることを示しています。エンキュー待機は、ロックに対する待機です。この例では、TM(表)ロックに対する待機です。これらの待機は索引付けされていない外部キー制約を示す場合があります。バッファ・ビジー待機
イベント・レコードは、バッファが利用可能になるまで待機します。これらの待機は、バッファ・キャッシュ内の同じバッファに対して、複数のプロセスが同時にアクセスを試みていることを示しています。
上位DBファイル
一定時間のアクティビティ
ASHレポートの「一定時間のアクティビティ」セクションでは、分析期間中のアクティビティおよびワークロード・プロファイルの徹底した詳細が参照できるため、長い期間に特に役立ちます。「一定時間のアクティビティ」セクションはタイム・スロットに分割されています。期間が短いかデータがわずかである場合を除き、ASHのレポート期間は10のタイム・スロットに分割されます。
図8-8は、午後2時10分から午後2時40分までの期間のアクティビティ・レポートを示しています。このレポートは、サンプリングされたセッションの数が6番目の内部スロット(午後2時24分)で急激に増加し、高いまま保持されたことを示しています。この期間に、CPUアクティビティとロックのエンキュー待機が大幅に増大しています。
表8-1に示すように、各タイム・スロットにはセッションと待機イベント・アクティビティが含まれています。
表8-1 一定時間のアクティビティ
列 | 説明 |
---|---|
時間帯(継続時間) |
時間帯の継続時間 |
時間帯数 |
時間帯のサンプル・セッションの数 |
イベント |
時間帯の上位3つの待機イベント |
イベント数 |
待機イベントを待機しているASHサンプルの数 |
%イベント |
分析期間全体で待機イベントを待機しているASHサンプルの割合 |
すべての内部スロットは、比較しやすいようにそれぞれ同じ分数になっています。最初と最後のスロットである外部スロットは、固定スロット時間を持たないため、サイズが異なります。
内部スロットを比較する場合は、スパイクを識別して偏りの分析を実行します。「スロット数」列のスパイクは、アクティブ・セッションの増加と、データベース・ワークロードの相対的な増加を示します。「イベント数」列のスパイクは、イベントを待機するサンプリングされたセッション数の増加を示します。通常、アクティブ・セッションのサンプルの数および待機イベントに関連付けられたセッションの数が増えた場合、スロットは一時的なパフォーマンスの問題の原因となる可能性があります。