ヘッダーをスキップ

Oracle Database 2日でパフォーマンス・チューニング・ガイド
11g リリース1(11.1)

E05744-02
目次
目次
索引
索引

戻る 次へ

7 一時的なパフォーマンスの問題の解決

一時的なパフォーマンスの問題は短期間のみ継続するため、自動データベース診断モニター(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の自己管理フレームワークに不可欠であり、パフォーマンスの問題の診断に非常に役立ちます。

AWRによって収集されたインスタンス・レベルの統計とは異なり、サンプル・データはASHによりセッション・レベルで収集されます。アクティブ・セッションのみに対する統計を取得すると、管理しやすいデータのセットが示されます。このデータのサイズは、データベース・インスタンス全体ではなく実行されている作業に直接関連するサイズです。

ASHによって取得されたサンプル・データは、取得元の様々なディメンションに基づいて集計できます。次のものが含まれます。

ASHレポートを実行して、特定の期間にのみ発生するデータベースの一時的なパフォーマンスの問題を分析できます。この手法は次のいずれかを試す場合に特に有効です。

アクティブ・セッション履歴レポートの実行

この項では、Oracle Enterprise Manager(Enterprise Manager)を使用してASHレポートを生成する方法について説明します。

ASHレポートの実行手順:
  1. 「パフォーマンス」ページの「平均アクティブ・セッション」で、「ASHレポートの実行」をクリックします。

    「ASHレポートの実行」ページが表示されます。

  2. 一時的なパフォーマンスの問題が発生した場合の期間の開始および終了の日時を入力します。

    この例では、午後1:45から午後2:00までの間にデータベース・アクティビティが増えているため、この期間のASHレポートを作成する必要があります。


    画像の説明

  3. 「レポートを生成」をクリックします。

    レポートの生成中に「処理中: レポートの表示」ページが表示されます。

    レポートが生成されると、ASHレポートが「ASHレポートの実行」ページの「レポート結果」の下に表示されます。


    画像の説明

  4. オプションで、「ファイルに保存」をクリックして、今後の分析のためにHTMLにレポートを保存します。

アクティブ・セッション履歴レポート

ASHレポートを使用して一時的なパフォーマンスの問題の原因を識別できます。このレポートは、タイトルの付いた複数のセクションに分割されています。調査を開始する際に役立つASHレポートのセクションは、次のとおりです。

上位イベント

レポートの「上位イベント」セクションにはユーザー、バックグラウンドおよび優先順位によって分類され、サンプリングされたセッション・アクティビティの上位の待機イベントが表示されます。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある待機イベントを識別します。

「上位イベント」セクションには次のサブセクションが含まれます。

上位ユーザー・イベント

レポートの「上位ユーザー・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占める、ユーザー・プロセスから上位の待機イベントをリストします。

図7-1の例は、データベース・アクティビティの84%がCPU + Wait for CPUイベントによって消費されていることを示しています。この例では、「ロード・プロファイル」セクションを確認して、この待機イベントが発生しているアクティビティのタイプを判別する必要があります。

図7-1    上位ユーザー・イベント


画像の説明

上位バックグラウンド・イベント

レポートの「上位バックグラウンド・イベント」サブセクションは、サンプリングされたセッション・アクティビティの最も高い割合を占めるバックグラウンド・イベントから上位の待機イベントをリストします。

図7-2の例は、サンプリングされたセッション・アクティビティの17.65%がCPU + Wait for CPUイベントによって消費されていることを示しています。

図7-2    上位バックグラウンド・イベント


画像の説明

ロード・プロファイル

レポートの「ロード・プロファイル」セクションでは、サンプリングされたセッション・アクティビティで分析された負荷を説明します。このセクションの情報を使用して、一時的なパフォーマンスの問題の原因となるサービス、クライアントまたはSQLコマンド・タイプを識別します。「上位サービス/モジュール」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるサービスおよびモジュールがリストされます。

図7-3の例は、データベース・アクティビティの81%がSQL*Plusモジュールを実行するSYS$USERSサービスによって消費されていることを示しています。この例では、図7-1に示されたパフォーマンスの問題の原因となっている高負荷のSQL文をユーザーが実行していることがわかります。レポートの「上位SQL」セクションで分析して、特定のタイプのSQL文に負荷がかかっているかどうかを判別する必要があります。

図7-3    上位サービス/モジュール


画像の説明

参照:

 

上位SQL

レポートの「上位SQL」セクションでは、サンプリングされたセッション・アクティビティの上位SQL文を説明します。この情報を使用して、一時的なパフォーマンスの問題の原因になっている可能性がある高負荷SQL文を識別します。便利なサブセクションの1つに、「上位イベントのある上位SQL」があります。このサブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるSQL文がリストされます。「実行のサンプリング数」列に、特定のSQL文ごとに実行のサンプリング数が表示されます。SQL文のテキストを表示するには、「SQL ID」リンクをクリックします。

図7-4の例は、データベース・アクティビティの75%が特定のSELECT文によって消費されていることを示しています。この文は、図7-3に示されたSQL*Plusモジュールで実行されています。これは、パフォーマンスの問題の原因となっている高負荷のSQL文であることがわかります。「上位セッション」セクションを分析して、このSQL文を実行するセッションを識別する必要があります。

図7-4    上位イベントのある上位SQL


画像の説明

参照:

 

上位セッション

「上位セッション」セクションには、サンプリングされたセッション・アクティビティの最も高い割合を占める待機イベントを待機していたセッションが表示されます。この情報を使用して、パフォーマンスの問題の原因になっている可能性がある、サンプリングされたセッション・アクティビティの最も高い割合を占めるセッションを識別します。

図7-5の例は、データベース・アクティビティの81%はセッションIDが147のユーザーSHによって使用されていることを示しています。これは、図7-4で識別した高負荷のSQL文を実行したユーザーであることがわかります。このセッションを調査し、適切な操作が実行されているかどうか、また可能であればSQL文がチューニングされているかどうかを判別する必要があります。SQL文のチューニングができず、システムで許容できないパフォーマンスの問題が発生した場合は、セッションの終了を検討します。

図7-5    上位セッション


画像の説明

参照:

 

上位DBオブジェクト

「上位DBオブジェクト」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるデータベース・オブジェクト(表や索引など)がリストされます。

図7-6の例は、大部分のセッション・アクティビティを占めるオブジェクトがSYSTEMおよびSYSAUXの表領域にあることを示しています。表の各行のイベントは、db file sequential readです。これは、ユーザー・プロセスによってバッファがシステム・グローバル領域(SGA)のバッファ・キャッシュに読み込まれ、戻される物理I/Oコールが待機されていることを示します。

図7-6    上位DBオブジェクト


画像の説明

上位DBファイル

「上位DBファイル」サブセクションには、サンプリングされたセッション・アクティビティの最も高い割合を占めるデータベース・ファイルがリストされます。

図7-7の例は、セッション・アクティビティの大部分がSYSTEM表領域のデータファイルに関連していることを示しています。この情報は、大部分のセッション・アクティビティを占めるオブジェクトがSYSTEMおよびSYSAUXの表領域にあることを示す図7-6と一致します。

図7-7    上位DBファイル


画像の説明

一定時間のアクティビティ

ASHレポートの「一定時間のアクティビティ」セクションでは、分析期間中のアクティビティおよびワークロード・プロファイルの徹底した詳細が参照できるため、長い期間に特に役立ちます。「一定時間のアクティビティ」セクションは複数のタイム・スロットに分割されています。

図7-8    一定時間のアクティビティ


画像の説明

各時間帯には、表7-1に示すように、特定の時間帯に関する情報が含まれます。

表7-1    一定時間のアクティビティ 
  説明 

スロット時間(継続時間) 

スロットの期間 

スロット数 

スロット内のサンプリングされたセッションの数 

イベント 

スロット内の上位3つの待機イベント 

イベント数 

待機イベントを待機中のASHサンプルの数 

%イベント 

分析期間全体での待機イベントを待機していたASHサンプルの割合 

すべての内部スロットは2分で、それぞれを比較できます。最初と最後のスロットは、外部スロットとも呼ばれます。これらのスロットは、固定スロット時間を持たないスロットであるため、サイズが異なります。

内部スロットを比較する場合、「イベント数」列および「スロット数」列内のスパイクを識別して偏りの分析を実行します。「イベント数」列のスパイクは、特定のイベントを待機中のサンプリングされたセッションの数の増加を示し、「スロット数」列のスパイクは、アクティブ・セッションの増加を示します。ASHデータは、アクティブ・セッションのみからサンプリングされたデータベース・ワークロード内の相対的な増分です。通常、アクティブ・セッションのサンプルの数および待機イベントに関連付けられたセッションの数が増えた場合、スロットは一時的なパフォーマンスの問題の原因となる可能性があります。

図7-8の例は、サンプリングされたセッション数が最初の内部スロットで急激に増加し、最後の内部スロットで急激に減少したことを示しています。スロット数とイベント数のピークは、午後13:54のタイム・スロットです。


戻る 次へ
Oracle
Copyright © 2007, 2008 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引