10gリリース2（10.2）
B19207-02
 目次 |
 索引 |
| Oracle Database パフォーマンス・チューニング・ガイド 10gリリース2（10.2） B19207-02 |
|
ハードウェアやソフトウェアのアップグレードなどのシステム変更を行う前に、通常は変更内容を検証するためにテスト環境で広範囲なテストが実行されます。 ただし、テストを実行しても、テストには実際のワークロードを使用していないため、新規システムの本番運用が開始されると、しばしば予期しない動作が発生します。 テスト中に実際のワークロードをシミュレートできないことは、システム変更を検証する際の最大の問題点の1つです。
データベース・リプレイにより、本番のワークロード環境をテスト・システム上で本質的に再作成して、システム変更を現実的にテストできます。 データベース・リプレイを使用すると、本番システム上でワークロードを取得し、テスト・システムでオリジナルのワークロードの正確なタイミング、同時実行性およびトランザクション特性を使用して、取得されたワークロードをリプレイできます。 これにより、望ましくない結果、新しい競合ポイントまたは計画の回帰など、変更による影響を完全に評価できます。 広範囲な分析およびレポート機能が用意されており、新たに発生したエラーやパフォーマンスの相違など、潜在的な問題を識別する上で役立ちます。
本番のワークロードを取得することで、シミュレーション・ワークロードまたはスクリプトを開発する必要がなくなるため、大幅なコストの削減と時間の節約になります。 データベース・リプレイを使用すると、従来はロード・シミュレーション・ツールを使用して数か月かかっていた複雑なアプリケーションの現実的なテストを数日で完了できます。 これにより、迅速に変更をテストして、従来よりも信頼性が高く低リスクの新規テクノロジを採用できます。
データベース・リプレイでは、外部クライアントのワークロードの取得がデータベース・レベルで実行され、パフォーマンス・オーバーヘッドはわずかです。 データベース・リプレイを使用すると、次のようにすべての重要なシステム変更をテストできます。
この章では、Oracle Databaseのデータベース・リプレイ機能の使用方法について説明します。この章には、次の項があります。
データベース・リプレイにより、本番システム上でワークロードを取得し、それをテスト・システム上でリプレイすることで、テスト・システム上に本番のワークロード環境を本質的に再作成して、システム変更を現実的にテストできます。
データベース・リプレイを使用するには、図21-1に示すように4つの主要ステップが必要です。
データベース・リプレイを使用する最初のステップは、本番のワークロードを取得することです。 ワークロードを取得するには、外部クライアントからOracle Databaseに対して発行された要求をすべて記録する必要があります。 ワークロードの取得が有効化されている場合、Oracle Databaseに送られた外部クライアントの要求がすべて追跡され、ファイル・システム上で取得ファイルと呼ばれるバイナリ・ファイルに格納されます。 これらの取得ファイルはプラットフォームに依存せず、別のシステムに転送できます。 ワークロード取得の開始時刻と期間、および取得ファイルの格納場所を指定できます。 ワークロードの取得が始まると、すべての外部データベース・コールが取得ファイルに書き込まれます。 取得ファイルには、SQLテキスト、バインド値およびトランザクション情報など、クライアント要求に関する関連情報がすべて含まれます。 バックグラウンド・アクティビティとデータベース・スケジューラ・ジョブは取得されません。
本番システム上でワークロードを取得する方法は、「データベース・ワークロードの取得」を参照してください。
ワークロードの取得が完了した後、取得ファイル内の情報を前処理する必要があります。 前処理により、ワークロードのリプレイに必要なメタデータがすべて作成されます。 この前処理は、取得された各ワークロードをリプレイする前に1度実行する必要があります。 前処理後、同じバージョンのOracle Databaseを実行中のリプレイ・システム上で、取得されたワークロードを繰り返しリプレイできます。 通常は、取得ファイルは前処理のために別のシステムにコピーする必要があります。 ワークロードの前処理は時間のかかるリソース集中型の処理であるため、このステップはワークロードのリプレイに使用するテスト・システム上で実行することをお薦めします。
前処理が完了した後、取得されたワークロードをテスト・システム上でリプレイできます。 ワークロードのリプレイ・フェーズでは、ワークロードの取得フェーズで記録されたアクションが、Oracle Databaseによりテスト・システム上で実行されます。そのために、取得されたすべての外部クライアント要求が、本番システムと同じタイミング、同時実行性およびトランザクション依存性を使用して再作成されます。
データベース・リプレイでは、リプレイ・クライアントと呼ばれるクライアント・プログラムを使用して、ワークロードの取得中に記録された外部クライアント要求がすべて再作成されます。 取得されたワークロードによっては、正常にリプレイするために1つ以上のリプレイ・クライアントが必要になる場合があります。 特定のワークロードに必要なリプレイ・クライアントの数を判別できるように、測定ツールが用意されています。 DMLおよびSQL問合せを含めてワークロード全体がリプレイされるため、リプレイ・システム内のデータは取得システム上のデータと論理的に類似している必要があります。これにより、データの相違が最小限になり、信頼性の高いリプレイ分析が可能になります。
ワークロードがリプレイされた後、ワークロードの取得とリプレイの両方について詳細な分析を実行できるように、詳細レポートが提供されます。
レポート・サマリーは、リプレイ中に発生したエラーや、DMLまたはSQL問合せで戻された行のデータの相違など、ワークロードの取得とリプレイに関する基本情報を提供します。 ワークロードの取得とワークロードのリプレイとの複数の統計（DB時間、平均アクティブ・セッションおよびユーザー・コールなど）の比較も提供されます。 拡張分析の場合、自動ワークロード・リポジトリ（AWR）レポートを使用して、ワークロードの取得とワークロードのリプレイの間でパフォーマンス統計詳細を比較できます。 これらのレポートで使用可能な情報は非常に詳細であり、ワークロードの取得とリプレイの間にはある程度の相違を予想できます。
アプリケーション・レベルの検証では、リプレイ全体の成功を評価するためのスクリプトの開発を検討する必要があります。 たとえば、ワークロードの取得中に10,000件のオーダーが処理される場合、リプレイ中にもそれとほぼ同数のオーダーが処理されることを検証する必要があります。
ワークロードの取得レポートを生成して分析する方法は、「ワークロードの取得の分析」を参照してください。
この項では、本番システム上でデータベース・ワークロードを取得する方法について説明します。 データベース・ワークロード取得用の主ツールは、Oracle Enterprise Managerです。 なんらかの理由でOracle Enterprise Managerを使用できない場合は、APIを使用してデータベース・ワークロードを取得できます。
この項では、次の項目について説明します。
ワークロードを取得する前に、取得を計画しているシステム上でワークロードの取得を有効化する必要があります。 Oracle Database 10g リリース2（10.2）では、デフォルトでワークロードの取得は有効化されません。 PRE_11G_ENABLE_CAPTURE初期化パラメータを指定すると、ワークロードの取得を有効化または無効化できます。
ワークロードの取得を有効化するには、SQLプロンプトからwrrenbl.sqlスクリプトを実行します。
@$ORACLE_HOME/rdbms/admin/wrrenbl.sql
wrrenbl.sqlスクリプトによりALTER SYSTEM SQL文がコールされ、PRE_11G_ENABLE_CAPTURE初期化パラメータがTRUEに設定されます。 サーバー・パラメータ・ファイル（SPFILE）を使用する場合、PRE_11G_ENABLE_CAPTURE初期化パラメータは現在実行中のインスタンスにあわせて変更されてSPFILEに記録されるため、新しい設定はデータベースを再起動するまで存続します。 SPFILEを使用しない場合、PRE_11G_ENABLE_CAPTURE初期化パラメータは現在実行中のインスタンスについてのみ変更され、新しい設定はデータベースを再起動すると存続しなくなります。 SPFILEを使用せずに設定を永続的にするには、パラメータを初期化パラメータ・ファイル（init.ora）に手動で指定する必要があります。
ワークロードの取得を無効化するには、SQLプロンプトからwrrdsbl.sqlスクリプトを実行します。
@$ORACLE_HOME/rdbms/admin/wrrdsbl.sql
wrrdsbl.sqlスクリプトによりALTER SYSTEM SQL文がコールされ、PRE_11G_ENABLE_CAPTURE初期化パラメータがFALSEに設定されます。 サーバー・パラメータ・ファイル（SPFILE）を使用する場合、PRE_11G_ENABLE_CAPTURE初期化パラメータは現在実行中のインスタンスにあわせて変更されてSPFILEに記録されるため、新しい設定はデータベースを再起動するまで存続します。 SPFILEを使用しない場合、PRE_11G_ENABLE_CAPTURE初期化パラメータは現在実行中のインスタンスについてのみ変更され、新しい設定はデータベースを再起動すると存続しなくなります。 SPFILEを使用せずに設定を永続的にするには、パラメータを初期化パラメータ・ファイル（init.ora）に手動で指定する必要があります。
ワークロードの取得を開始する前に、テスト・システム上でデータベースをリストアするための計画を作成する必要があります。 ワークロードをリプレイする前に、リプレイ・システム上のアプリケーション・データを、リプレイ開始時の取得システムと同じ状態にする必要があります。 そのためには、次の方法のいずれかを使用することを検討してください。
これにより、リプレイ・システム上のデータベースを、ワークロードの取得開始時点でのアプリケーションの状態にリストアできます。
取得が正確で、別の環境でリプレイしたときに役立つように、ワークロードの取得前に適切に計画しておく必要があります。
データベース・ワークロードを取得する前に、次のオプションを慎重に検討してください。
このステップはオプションですが、実行中のトランザクションや依存トランザクションを取得開始前に確実に完了またはロールバックできるように、ワークロードの取得前にデータベースを再起動することをお薦めします。 取得開始前にデータベースを再起動しないと、実行中だったトランザクションや、まだコミットされていなかったトランザクションがワークロードに完全に取得されません。 したがって、実行中のトランザクションは正しくリプレイされません。これは、トランザクションのうちコールが取得された部分のみがリプレイされるためです。 その結果、ワークロードをリプレイすると、データに望ましくない相違が発生する可能性があります。 未完了トランザクションに依存する以降のトランザクションでも、リプレイ中にエラーが生成される可能性があります。
データベースを再起動する前に、最小限の中断でワークロード取得期間前に本番データベースを停止する適切な時期を判断します。 たとえば、午前8時から始まるワークロードを取得する必要があるとします。ただし、通常の業務時間中のサービス中断を回避するために、この時刻にはデータベースを再起動しないようにします。 この場合は、中断期間が短くなる時刻にデータベースを再起動できるように、ワークロードの取得開始時刻を早めることを検討する必要があります。
データベースの再起動後は、ユーザー・セッションが再接続されてワークロードの発行が開始される前に、ワークロードの取得を開始することが重要です。 このようにしないと、これらのユーザー・セッションにより実行されるトランザクションは、以降のデータベース・リプレイで正常にリプレイされません。これは、トランザクションのうち、ワークロードの取得開始後にコールが実行された部分のみがリプレイされるためです。 この問題を回避するために、STARTUP_RESTRICTEDを使用してデータベースをRESTRICTEDモードで再起動することを検討してください。これにより、SYSユーザーのみがログインとワークロードの取得開始を許可されます。 デフォルトでは、ワークロードの取得が始まると、RESTRICTEDモードのデータベース・インスタンスが自動的にUNRESTRICTEDモードに切り替わり、ワークロードの取得中に通常の操作を継続できるようになります。
1回に実行できるワークロードの取得は、1つのみです。 Oracle Real Application Clusters（RAC）の場合、ワークロードの取得はデータベース全体に対して実行されます。 ワークロードの取得開始前にクリーンな状態を有効化するには、すべてのインスタンスを再起動する必要があります。 そのためには、次の手順を実行できます。
デフォルトでは、ワークロードの取得中にすべてのユーザー・セッションが記録されます。 ワークロード・フィルタを使用すると、ワークロードに含めるか除外するユーザー・セッションを指定できます。 包含フィルタを使用すると、ワークロードで取得するユーザー・セッションを指定できます。 これは、データベース・ワークロードのサブセットのみを取得する場合に役立ちます。 除外フィルタを使用すると、ワークロードで取得しないユーザー・セッションを指定できます。 これは、ワークロードで取得する必要のないセッション・タイプを除外する場合に役立ちます。 たとえば、ワークロードのリプレイに使用するシステムでOracle Enterprise Manager（EM）を実行中の場合、取得したEMセッションをこのシステム上でリプレイすると、ワークロードが重複する結果となります。 この場合は、除外フィルタを使用してEMセッションを除外できます。 ワークロードの取得には、包含フィルタまたは除外フィルタを使用できますが、両方を使用することはできません。
取得されたワークロードを格納する場所を決定し、ディレクトリを設定します。 ワークロードの取得を開始する前に、ディレクトリが空で、ワークロードを格納できる十分なディスク領域があることを確認します。 ワークロードの取得中にディレクトリがディスク領域不足になると、取得が停止します。
Oracle RACの場合は、共有ファイル・システムの使用を検討してください。 または、各インスタンス上の個別の物理ディレクトリに解決される取得ディレクトリ・パスを設定することもできますが、ワークロードの取得を前処理する前に、これらの各ディレクトリに作成された取得ファイルを1つのディレクトリに収集する必要があります。
現行リリースでは、次のタイプのクライアント要求はワークロードで取得されません。
DESCRIBEおよびCOMMIT操作
この項では、Enterprise Managerを使用してデータベース・ワークロードを取得する方法について説明します。
Enterprise Managerを使用してデータベース・ワークロードを取得する手順は、次のとおりです。
「データベース・リプレイ」ページが表示されます。
「ワークロードの取得: 環境の計画」ページが表示されます。
前提条件については、「データベース・ワークロードの取得の前提条件」を参照してください。 確認した前提条件ごとに、「確認」列のボックスを選択します。 すべての前提条件を確認した後、「次」をクリックします。
「ワークロードの取得: オプション」ページが表示されます。
ワークロードの取得にクリーンな状態を使用できるように、ワークロードの取得前にデータベースを再起動することをお薦めします。 再起動しないと、ワークロードのリプレイ時に潜在的な問題が発生する可能性があります。詳細は、「データベースの再起動」を参照してください。
フィルタを追加するには、「行の追加」をクリックし、フィルタ名、セッション属性タイプおよび属性値を対応するフィールドに入力します。詳細は、「ワークロード・フィルタの定義」を参照してください。
必要なワークロード取得オプションの選択後、「次」をクリックします。 「ワークロードの取得: パラメータ」ページが表示されます。
新規ディレクトリ・オブジェクトを作成するには、「ディレクトリ・オブジェクトの作成」をクリックします。 「ディレクトリ・オブジェクトの作成」ページが表示されます。 「名前」フィールドに、ディレクトリ・オブジェクト名を入力します。 「パス」フィールドに、ディレクトリ・オブジェクトへのパスを入力します。 指定したディレクトリがファイル・システムに存在するかどうかをテストするには、「テスト・ファイルシステム」をクリックします。 そのディレクトリが存在しない場合は、最初に作成する必要があります。
ワークロードの取得パラメータを定義した後、「次」をクリックします。 「ワークロードの取得: スケジュール」ページが表示されます。
DBA権限が必要です。
「次」をクリックします。 「ワークロードの取得: 確認」ページが表示されます。
ワークロードの取得が開始された後は、「アクティブなワークロードの取得の監視」で説明するように、「ワークロードの取得の表示」ページを使用して取得プロセスを監視できます。
この項では、Enterprise Managerを使用してワークロードの取得を監視する方法について説明します。 ワークロードの取得監視用の主ツールは、Oracle Enterprise Managerです。 Enterprise Managerを使用して次の操作を実行できます。
なんらかの理由でOracle Enterprise Managerを使用できない場合は、「ビューを使用したワークロードの取得の監視」で説明するように、ビューを使用してワークロードの取得を監視できます。
この項では、次の項目について説明します。
この項では、Enterprise Managerを使用してアクティブなワークロードの取得を監視する方法について説明します。
アクティブなワークロードの取得を監視する手順は、次のとおりです。
「データベース・リプレイ」ページが表示されます。
「ワークロードの取得の表示」ページが表示されます。
「平均アクティブ・セッション」の下の「アクティブ・セッション」グラフに、取得されたセッション・アクティビティと取得されていないセッション・アクティビティ（バックグラウンド・アクティビティやフィルタされたセッションなど）の比較がグラフ表示されます。
「比較」の下に、データベース時間、平均アクティブ・セッション、ユーザー・コール、トランザクション、接続およびアプリケーション・エラーなど、ワークロードの取得の各種統計が表示されます。 「合計」列には合計セッション・アクティビティの統計が表示され、「取得」列には取得されたセッション・アクティビティの統計が表示されます。 「合計の割合」列には、ワークロードで取得中の合計セッション・アクティビティの割合が表示されます。
ワークロードの取得レポートを表示するには、「ワークロードの取得レポートの表示」をクリックします。
ワークロードの取得に使用されたワークロード・フィルタの詳細（ワークロード・フィルタ名、タイプ、セッション属性および値など）が表示されます。
この項では、Enterprise Managerを使用してアクティブなワークロードの取得を停止する方法について説明します。
アクティブなワークロードの取得を停止する手順は、次のとおりです。
「データベース・リプレイ」ページが表示されます。
「確認」ページが表示されます。
「AWRデータのエクスポート」ページが表示されます。
AWRデータをエクスポートすると、ワークロードの詳細分析を実行できます。 このデータは、ワークロードの取得またはリプレイのペアに対して「AWRの期間比較レポート」を実行するように計画している場合も必須です。 AWRデータをエクスポートしないことを選択する場合は、「いいえ」をクリックします。 完了したワークロードの取得からのAWRデータを、「ワークロードの取得履歴の表示」ページから後でエクスポートすることもできます。 AWRについては、「自動ワークロード・リポジトリの概要」を参照してください。
この項では、Enterprise Managerを使用して、完了したワークロードの取得を管理する方法について説明します。
完了したワークロードの取得を管理する手順は、次のとおりです。
「データベース・リプレイ」ページが表示されます。
「ワークロードの取得履歴の表示」ページが表示されます。
AWRデータをエクスポートすると、ワークロードの詳細分析を実行できます。 このデータは、ワークロードの取得またはリプレイのペアに対して「AWRの期間比較レポート」を実行するように計画している場合も必須です。
「ワークロードの取得の表示」ページが表示されます。
「平均アクティブ・セッション」の下の「アクティブ・セッション」グラフに、取得されたセッション・アクティビティと取得されていないセッション・アクティビティ（バックグラウンド・アクティビティやフィルタされたセッションなど）の比較がグラフ表示されます。 このグラフが表示されるのは、取得期間中に使用可能なActive Session History（ASH）データが存在する場合のみです。 ASHについては、「Active Session History（ASH）」を参照してください。
「比較」の下に、データベース時間、平均アクティブ・セッション、ユーザー・コール、トランザクション、接続およびアプリケーション・エラーなど、ワークロードの取得の各種統計が表示されます。 「合計」列には合計セッション・アクティビティの統計が表示され、「取得」列には取得されたセッション・アクティビティの統計が表示されます。 「合計の割合」列には、ワークロードで取得中の合計セッション・アクティビティの割合が表示されます。
ワークロードの取得レポートを表示するには、「ワークロードの取得レポートの表示」をクリックします。
ワークロードの取得に使用されたワークロード・フィルタの詳細（ワークロード・フィルタ名、タイプ、セッション属性および値など）が表示されます。
この項では、APIを使用してデータベース・ワークロードを取得する方法について説明します。 DBMS_WORKLOAD_CAPTUREパッケージを使用してデータベース・ワークロードを取得するには、次のステップを実行する必要があります。
この項では、ワークロード・フィルタを追加および削除する方法について説明します。 ワークロード・フィルタの使用方法は、「ワークロード・フィルタの定義」を参照してください。
ワークロードの取得にフィルタを追加するには、ADD_FILTERプロシージャを使用します。
BEGIN DBMS_WORKLOAD_CAPTURE.ADD_FILTER ( fname => 'user_ichan', fattribute => 'USER', fvalue => 'ICHAN'); END; /
この例では、ADD_FILTERプロシージャによりuser_ichanというフィルタが追加されます。このフィルタを使用すると、ユーザー名ICHANに属しているセッションをすべて除外できます。
この例のADD_FILTERプロシージャでは、次のパラメータを使用しています。
fnameでは、追加するフィルタの名前を指定します。
fattributeでは、フィルタを適用する属性を指定します。 有効な値は、PROGRAM、MODULE、ACTION、SERVICE、INSTANCE_NUMBERおよびUSERです。
fvalueでは、フィルタを適用する、対応する属性の値を指定します。 モジュールやアクションなど、一部の属性には%などのワイルドカードを使用できます。
ワークロードの取得からフィルタを削除するには、DELETE_FILTERプロシージャを使用します。
BEGIN DBMS_WORKLOAD_CAPTURE.DELETE_FILTER (fname => 'user_ichan'); END; /
この例のDELETE_FILTERプロシージャでは、ワークロードの取得からuser_ichanというフィルタが削除されます。 DELETE_FILTERプロシージャでは、削除対象のフィルタの名前を指定する必須パラメータfnameを使用しています。
ワークロードの取得を開始する前に、まず「データベース・ワークロードの取得の前提条件」の説明に従って、データベース・ワークロードを取得するための前提条件を完了する必要があります。 また、「ワークロードの取得オプション」の説明に従って、ワークロードの取得オプションも確認する必要があります。
取得されたワークロードのリプレイを開始する前に、ワークロードの始点を適切に定義しておくことが重要です。これにより、リプレイ・システムをその時点にリストアできるようになります。 ワークロードの取得の始点を適切に定義するには、ワークロードの取得の開始時にアクティブなユーザー・セッションを残さないことをお薦めします。 アクティブなセッションで実行中のトランザクションがあると、これらのトランザクションは、以降のデータベース・リプレイで正常にリプレイされません。これは、トランザクションのうち、ワークロードの取得開始後にコールが実行された部分のみがリプレイされるためです。 この問題を回避するために、ワークロードの取得を開始する前に、STARTUP_RESTRICTEDを使用してデータベースをRESTRICTEDモードで再起動することを検討してください。 ワークロードの取得が開始されると、データベースが自動的にUNRESTRICTEDモードに切り替わり、ワークロードの取得中に通常の操作を継続できます。 ワークロードの取得を開始する前のデータベースの再起動の詳細は、「データベースの再起動」を参照してください。
ワークロードの取得を開始するには、START_CAPTUREプロシージャを使用します。
BEGIN DBMS_WORKLOAD_CAPTURE.START_CAPTURE (name => 'dec06_peak', dir => 'dec06', duration => 600); END; /
この例では、dec06_peakというワークロードが600秒間取得され、dec06というデータベース・ディレクトリ・オブジェクトで定義されたオペレーティング・システムに格納されます。
この例のSTART_CAPTUREプロシージャでは、次のパラメータを使用しています。
nameでは、取得するワークロードの名前を指定します。
dirでは、取得されたワークロードを格納するディレクトリを指すディレクトリ・オブジェクトを指定します。
durationでは、ワークロードの取得が終了するまでの秒数を指定します。 値を指定しなければ、ワークロードの取得はFINISH_CAPTUREプロシージャがコールされるまで継続されます。
ワークロードの取得を停止するには、FINISH_CAPTUREプロシージャを使用します。
BEGIN DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE (); END; /
この例のFINISH_CAPTUREプロシージャでは、ワークロードの取得がファイナライズされ、データベースが通常の状態に戻されます。
AWRデータをエクスポートすると、ワークロードの詳細分析を実行できます。 このデータは、ワークロードの取得またはリプレイのペアに対して「AWRの期間比較レポート」を実行するように計画している場合も必須です。
AWRデータをエクスポートするには、EXPORT_AWRプロシージャを使用します。
BEGIN DBMS_WORKLOAD_CAPTURE.EXPORT_AWR (capture_id => 2); END; /
この例では、取得IDが2のワークロードの取得に対応するAWRスナップショットがエクスポートされます。 EXPORT_AWRプロシージャでは、必須パラメータcapture_idを使用して、AWRスナップショットのエクスポート対象となる取得のIDを指定しています。 このプロシージャが動作するのは、対応するワークロードの取得が現行のデータベース内で実行され、元の取得期間に対応するAWRスナップショットが引き続き使用可能な場合のみです。
この項では、ワークロードの取得を監視するために表示できるビューについて説明します。これらのビューにアクセスするには、DBA権限が必要です。
DBA_WORKLOAD_CAPTURESビューには、現行のデータベース内で取得されたワークロードの取得がすべてリストされます。
DBA_WORKLOAD_FILTERSビューには、現行のデータベース内で定義済のワークロードの取得に使用されたワークロード・フィルタがすべてリストされます。この項では、ワークロードの取得レポートを生成して分析する方法について説明します。 ワークロードの取得レポート生成用の主ツールは、Oracle Enterprise Managerです。 なんらかの理由でOracle Enterprise Managerを使用できない場合は、APIを使用してワークロードの取得レポートを生成できます。
この項では、次の項目について説明します。
ワークロードの取得レポートには、取得されたワークロードの統計、取得された上位セッション・アクティビティに関する情報、および取得プロセス中に使用されたワークロード・フィルタが含まれています。
Enterprise Managerを使用してワークロードの取得レポートを生成する手順は、次のとおりです。
「データベース・リプレイ」ページが表示されます。
「ワークロードの取得履歴の表示」ページが表示されます。
「ワークロードの取得の表示」ページが表示されます。
レポートの生成中に「レポート」ウィンドウがオープンします。
ワークロードの取得レポートの使用方法は、「ワークロードの取得レポートの使用」を参照してください。
ワークロードの取得レポートには、取得されたワークロードの統計、取得された上位セッション・アクティビティに関する情報、および取得プロセス中に使用されたワークロード・フィルタが含まれています。
最新のワークロードの取得に関するレポートを生成するには、DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFOプロシージャとDBMS_WORKLOAD_CAPTURE.REPORTファンクションを使用します。
DECLARE cap_id NUMBER; cap_rpt CLOB; BEGIN cap_id := DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO(dir => 'dec06'); cap_rpt := DBMS_WORKLOAD_CAPTURE.REPORT(capture_id => cap_id, format => DBMS_WORKLOAD_CAPTURE.TYPE_TEXT); END; /
この例のGET_CAPTURE_INFOプロシージャでは、dec06ディレクトリに格納されたワークロードの取得に関する情報がすべて取得され、そのワークロードの取得に該当するcap_idが戻されます。 REPORTファンクションでは、GET_CAPTURE_INFOプロシージャから戻されたcap_idを使用してテキスト・レポートが生成されます。
GET_CAPTURE_INFOプロシージャでは、必須パラメータdirを使用して、ワークロードの取得のディレクトリ・オブジェクトの名前を指定しています。
REPORTファンクションでは、次のパラメータが使用されています。
capture_idは、レポートの生成対象となるワークロードの取得を含んだディレクトリに関連しています。 このディレクトリには、ワークロードの取得を含んだホスト・システム上の有効なディレクトリを指定する必要があります。 このパラメータの値は、GET_CAPTURE_INFOプロシージャから戻されたcap_idと一致する必要があります。
formatでは、レポート形式を指定します。 有効な値は、DBMS_WORKLOAD_CAPTURE.TYPE_TEXTおよびDBMS_WORKLOAD_REPLAY.TYPE_HTMLなどです。
ワークロードの取得レポートの使用方法は、「ワークロードの取得レポートの使用」を参照してください。
ワークロードの取得レポートには、ワークロードの取得の妥当性評価に使用できる各種の情報が含まれています。 このレポートに表示される情報を使用して、取得されたワークロードについて次のことを判断できます。
ワークロードの取得レポートに含まれている情報は、次のカテゴリにわかれています。
|
 Copyright © 2000, 2008, Oracle Corporation. All Rights Reserved. |
|