11 リカバリ・アプライアンス・レポートへのアクセス

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)で事前に作成されたOracle Business Intelligence (BI) Publisherレポートにアクセスする方法について説明します。Cloud Controで保護されたデータベースのバックアップ・レポート・ページにアクセスする方法については、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

この章の内容は次のとおりです。

リカバリ・アプライアンス・レポートについて

この項には次のトピックが含まれます:

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

リカバリ・アプライアンス・レポートの目的

リカバリ・アプライアンス管理者の主なタスクは、記憶域容量計画です。リカバリ・アプライアンスは、次の目標を達成するために事前作成されたBI PublisherレポートをBI Publisherを介して提供します。

  • リカバリ・アプライアンスに、ニーズを満たすための十分な記憶域領域を確保します

    容量レポートを使用することで、追加の記憶域を計画し、リカバリ・アプライアンスに追加する新しい保護されたデータベースの数を削減したり、保護ポリシーを調整してリカバリ・ウィンドウ領域の合計を減らすことができます。

  • ネットワークが過負荷でないことを保証します

    容量レポートは、リカバリ・アプライアンスがネットワーク容量を最大限に活用しているかどうかも示します。場合によっては、1日を通してネットワーク・トラフィックをより均等に再分散することで、ネットワーク負荷を減らすことができます。ネットワーク・トラフィックが分散されておらず、ネットワーク・ピークがネットワーク帯域幅をほぼ最大限に活用している場合、一部の保護されたデータベースのバックアップ・ウィンドウ時間の調整が必要になる可能性があります。

  • システム・パフォーマンスおよびサービス・リクエストに対するアクティビティの適切なビューを提供します

  • 任意の保護されたデータベースの簡潔なまたは非常に詳細なステータス・レポートを取得します。これらは、リカバリ・ウィンドウ目標を達成したいないデータベースのトラブルシューティングに役立つことがあります

リカバリ・アプライアンス・レポートの概要

BI Publisherは、レポートおよびその他のドキュメントを作成、管理および配布するためのエンタープライズ・レポート・ソリューションです。

事前作成されたBI Publisherレポート

リカバリ・アプライアンスには、事前作成された次のBI Publisherレポートが用意されています。

  • 容量計画サマリー

    このレポートではリカバリ・アプライアンスの記憶域の概要を示し、容量が使い尽くされる時期を予測できるようにします。特に便利なのがサマリー表で、容量を超過するまでの日数のクイック・ビューが示されます。ネットワーク容量計画サマリーでは、様々な期間にわたるネットワーク・トラフィック合計のビューを提供します。このビューには、ネットワーク・サンプルに基づく平均レートと最大レートの両方が表示されます。

  • 容量計画詳細

    このレポートは、容量計画のより詳細な情報を提供します。記憶域容量、ネットワーク・スループット、保護されたデータベース・ホストそれぞれのCPU使用率、一定期間におけるディスクおよびフラッシュ・ストレージのI/Oスループットについての情報を提供します。容量計画サマリーとは異なり、詳細レポートにはメモリーおよびIOPSサマリー情報や詳細な日次データも表示されます。

  • リカバリ・ウィンドウ・サマリー

    このレポートは、リカバリ・ウィンドウ目標を達成していない、または保護されていないウィンドウのしきい値を超えている保護されたデータベースのリストを示します(「CREATE_PROTECTION_POLICY」unprotected_windowを参照)。このレポートをリカバリ・アプライアンスのリカバリ・ウィンドウおよび保護されていないデータ・ウィンドウに関する問題のクイック・ビューとして使用し、保護されたデータベースの詳細レポートを使用して保護されたデータベースを個別にフォローアップすることができます。

  • 保護されたデータベースの詳細

    このレポートには、次のサマリーを含め、保護されたデータベースについての広範なステータス情報が含まれます。

  • データ転送別上位10の保護されたデータベース

    このレポートでは、リカバリ・アプライアンスとの間で転送されたバックアップ・データの量に従って、上位10の保護されたデータベースをランク付けします。このレポートでは、毎時または毎日データを集計します。特に、このレポートでは次の量を測定します。

    • リカバリ・アプライアンスに送信されたバックアップ・データ

    • リカバリ・アプライアンスによって送信されたレプリケーション・データ

    • リカバリ・アプライアンスによって送信されたCopy-to-tapeデータ

    このレポートは、ランク付けされたデータベースのバックアップによって使用されている領域の量と直接は関係ありません。

前述のレポートには、BI publisherを介してのみアクセスできます。また、Cloud Controlに付属するBI Publisherソフトウェアは、Enterprise Managerリポジトリ内のデータにのみアクセス可能で、リカバリ・アプライアンス・スキーマのデータにはアクセスできません。

注意:

パフォーマンス・データにはV$のSQL問合せおよびリカバリ・カタログ・ビューを介してアクセスできますが、BI Publisherレポートを使用することを強くお薦めします。リカバリ・アプライアンスのCPUおよびその他のリソースには限りがあるため、頻繁にまたは負荷の高いSQL問合せを実行すると、リカバリ・アプライアンスの全体的なパフォーマンスが低下することがあります。

関連項目:

BI Publisherレポートのスケジューリング

規則的なスケジュール(毎週など)で自動的にレポートを生成するようBI Publisherを構成し、バックアップ管理チームに電子メールでレポートを送信することをお薦めします。この章に説明されている技法を使用して、必要に応じてレポートを生成することもできます。

関連項目:

BI Publisherを使用してレポートをスケジュールする方法については、『Oracle Fusion Middleware Oracle Business Intelligence Publisherユーザーズ・ガイド』を参照してください。

Cloud Controlでのリカバリ・アプライアンス・レポート・ページへのアクセス

この項では、事前作成されたすべてのBI Publisherレポートにリンクしているリカバリ・アプライアンス・レポート・ページにアクセスする方法について説明します。

リカバリ・アプライアンス・レポート・ページにアクセスするには:

  1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

  2. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。

    BI Publisher Enterpriseレポート・ページが表示されます。

  3. Enterprise Manager Cloud Controlフォルダ、リカバリ・アプライアンス・レポート・サブフォルダの順に展開します。

    事前作成されているレポートへのリンクが表示されます。

関連項目:

BI Publisherでレポートを表示する方法については、Cloud Controlオンライン・ヘルプを参照してください。

リカバリ・アプライアンス・レポートにアクセスするための基本的なタスク

この項では、レポートの管理に関する基本的なタスクについて説明します。図11-1は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、レポート・タスクを強調して示したものです。

図11-1 リカバリ・アプライアンス・ワークフローでのレポート・タスク

図11-1の説明が続く
「図11-1 リカバリ・アプライアンス・ワークフローでのレポート・タスク」の説明

通常、レポート・タスクを実行する順序は次のとおりです。

  1. 計画フェーズでは、Cloud Controlを介して使用できるモニタリング・ツールとレポート・ツールについての理解を深めます。

    「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。

  2. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じてレポートをレビューします。一般的なタスクには次のものがあります。

記憶域容量レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスの記憶域容量レポートを表示する方法について説明します。

前提条件

リカバリ・アプライアンス環境において、次の文がtrueであると想定します。

  • 2週間以上前に、ZDLRA Londonという名前のリカバリ・アプライアンスが設定されました。

  • 20の保護されたデータベースをZDLRA Londonにバックアップします。

記憶域容量についてのレポートをレビューするには:

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

  2. 容量計画サマリーをクリックします。

    BI Publisher Enterpriseのページが表示されます。

  3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。

    容量計画サマリー・ページが表示されます。

  4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。

    たとえば、ZDLRA Londonを選択します。

  5. 「記憶域容量計画サマリー」セクションをレビューして、記憶域増加率および容量を超過するまでの日数を特定します。

    たとえば、次の図はZDLRA Londonのサマリーを示しています。

    主要なメトリックは、容量を超過するまでの日数の6.85です。1週間以内に、リカバリ・アプライアンスは保護ポリシーの設定に応じて、バックアップをパージするか受信バックアップを拒否します(「コピーの保証」を参照)。

  6. 履歴記憶域トレンドを表示します。

    たとえば、先週のトレンドを確認します。

    前述のチャートは、過去2日間にわたって、すべての保護されたデータベースのリカバリ・ウィンドウ目標を満たすために必要な領域合計が5.2TBから21TBに増加したことを示しています。保護されたデータベースの数は20で安定しています。

  7. ネットワーク容量計画サマリーで、ネットワーク・スループットを確認します。

    たとえば、先週のネットワーク・スループットを確認します。

    前述のチャートは、過去2日間、受信速度が急激に上昇していることを示しています。

    ネットワーク容量計画サマリーでは、様々な期間(24時間、7日、30日)にわたるネットワーク・トラフィック合計のビューを提供します。

  8. 事前作成されたレポートのページに戻ります。

  9. 容量計画詳細をクリックします。

    リカバリ・アプライアンス: 容量計画 - 詳細ページが表示されます。

    このレポートは、容量計画サマリーよりも詳細な情報を提供します。容量計画レポートとは異なり、詳細レポートにはメモリーおよびIOPS情報も表示されます。

  10. 必要なリカバリ・アプライアンスが「リカバリ・アプライアンス」でまだ選択されていない場合は、選択して「適用」をクリックします。

  11. レポートの冒頭で「記憶域容量計画詳細」をクリックして、このセクションにジャンプします。

  12. 「IO履歴データ」セクションの「セル・ディスクIO」サブセクションにスクロール・ダウンします。

    たとえば、次の表に記憶域サーバーごとの15分間隔でのIOPSおよびスループットを示します。

リカバリ・ウィンドウ・サマリー・レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスで保護されているデータベースのリカバリ・ウィンドウ・サマリーを表示する方法について説明します。

前提条件

環境において、次の文がtrueであると想定します。

  • ZDLRA Montrealという名前のリカバリ・アプライアンスは、13のデータベースを保護します。

  • リカバリ・ウィンドウを満たしていないデータベースがあるかどうかを特定したいと考えています。

リカバリ・ウィンドウ・サマリー・レポートをレビューするには:

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

  2. 「リカバリ・ウィンドウ・サマリー」をクリックします。

    リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。

  3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。

    リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。

  4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。

    たとえば、ZDLRA Montrealを選択します。

    ページがリフレッシュされ、次の例のように上部にサマリーが表示されます。

    円グラフは、75%を超えるデータベースがサービス・レベル合意を満たしていないことを示しています。表は、合計13のデータベースのうち、3つのデータベースがリカバリ・ウィンドウ目標を満たしていないことを示しています。また、8つのデータベースが、保護されていないデータしきい値内に入っていません。

  5. チャートを下にスクロールすると、リカバリ・ウィンドウ目標を満たしていないデータベースが表示されます。

    次の例で、2つのサンプル・レポートを示します。

    前述の例は、データベースDB1116DB1123の両方ともリカバリ・ウィンドウ目標は1日であるが、この目標に何時間も達していないリカバリ・ウィンドウがあることを示しています。DB11242の目標も1日ですが、実際のリカバリ・ウィンドウは1時間未満です。

保護されたデータベースの詳細レポートへのアクセス

保護されたデータベースの詳細レポートには、リカバリ・アプライアンス・レポート・ページまたは保護されたデータベース・ページからアクセスできます。

保護されたデータベース・ページからの詳細レポートへのアクセス

このアクセス・パスは、「エンタープライズ」メニューを使用してリカバリ・アプライアンス・レポート・ページに移動する代わりの方法です。

保護されたデータベースの詳細ページにアクセスするには:

  1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

    たとえば、ZDLRA Montrealのホームページにアクセスします。

  2. 「リカバリ・アプライアンス」メニューから、「保護されたデータベース」を選択します。

    保護されたデータベース・ページが表示されます。

  3. 「保護されたデータベース」表でデータベースを選択します。

    たとえば、DB1124を選択します。

    ページの下部で、「保護されたデータベースの詳細」セクションがリフレッシュされます。

  4. 「保護されたデータベースの詳細」セクションで「ステータス」選択します。

    次の例に示すように、「ステータス」サブページが表示されます。

  5. 「保護されたデータベースのレポート」をクリックします。

    BI Publisherページが表示されます。

  6. BI Publisherの資格証明を入力して、「サインイン」をクリックします。

    リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます(「リカバリ・アプライアンス・レポート・ページからの保護されたデータベースの詳細レポートへのアクセス」の手順4を参照)。

リカバリ・アプライアンス・レポート・ページからの保護されたデータベースの詳細レポートへのアクセス

このチュートリアルでは、保護されたデータベースの詳細レポートにアクセスする方法について説明します。

前提条件

ZDLRA Philadelphiaという名前のリカバリ・アプライアンスは、12のデータベースを保護するとします。

保護されたデータベースについてのレポートをレビューするには:

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

  2. 「保護されたデータベースの詳細」をクリックします。

    リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。

    注意:

    「保護されたデータベース・ページからの詳細レポートへのアクセス」に説明されているように、このレポートには保護されたデータベース・ページから直接アクセスすることもできます。

  3. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択します。

    たとえば、ZDLRA Philadelphiaを選択します。

  4. 「保護されたデータベース」でデータベースを選択し、「適用」をクリックします。

    たとえば、DB1124を選択します。

    リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。

  5. 「バックアップ/リカバリ」セクションにスクロール・ダウンします。

    たとえば、次の図にDB1124データベースの統計値を示します。

    前の統計は、データベースがリカバリ・ウィンドウ目標を達成するには182.83GBが必要なことを示しています。

  6. バックアップ履歴を確認します。

    たとえば、次のチャートは、先週DB1124によって送受信されたデータを示しています。

    前のチャートは、日次バックアップ・データが8/25 (この日は305.1GB)を除いて毎日31~49GBであったことを示しています。毎日、送信されたレプリケーション・データ量は受信したバックアップ・データよりも若干少ない量でした。

  7. 必要なだけ前述の2つの手順を繰り返して、すべての保護されたデータベースのバックアップ・アクティビティを調査します。

保護されたデータベースのデータ転送レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスのデータ転送レポートを表示する方法について説明します。

前提条件

環境において、次の文がtrueであると想定します。

  • ZDLRA Montrealという名前のリカバリ・アプライアンスは、10のデータベースを保護します。

  • リカバリ・アプライアンスは一部のデータベースについては、バックアップをレプリケートしますがテープにはアーカイブしません。

  • 過去1週間にわたって最もデータを転送したデータベースを特定したいと考えています。

データ転送レポートをレビューするには:

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

  2. データ転送別上位10の保護されたデータベースをクリックします。

    BI Publisher Enterpriseのページが表示されます。

  3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。

    データ転送別上位10の保護されたデータベース・ページが表示されます。

  4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。

    たとえば、ZDLRA Montrealを選択します。

  5. 「バックアップ・データ別上位10のデータベース」をクリックします。

    「バックアップ・データ」セクションが表示されます。

  6. 「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。

    たとえば、09/08から09/15の期間のデータは次のとおりです。

    前のチャートによると、データベースDB12CDBはほとんどのデータを毎日バックアップしました。ピーク転送は09/09で、約1.25TBでした。

  7. レポートの上部に戻って「レプリケーション・データ別上位10のデータベース」をクリックします。

    「レプリケーション・データ」セクションが表示されます。

  8. 「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。

    たとえば、09/08から09/15の期間のデータは次のとおりです。

    前のチャートによると、データベースDB12CDBはほとんどのデータを毎日レプリケートしました。ピーク転送は09/11で、約1.7TBでした。

保護されたデータベースのチャージバック・レポートへのアクセス

このチュートリアルでは、保護されたデータベースのチャージ計算情報を表示する方法について説明します。

保護されたデータベースのチャージバック・レポートについて

保護されたデータベースのチャージバック・レポートは、リカバリ・アプライアンスに登録された保護されたデータベースのチャージバックに使用されます。グラフとピボット・テーブルの両方の形式でデータが表示されます。

保護されたデータベースのチャージバック・レポートは、すぐに使用可能なレポートではありません。このレポートをデプロイした後、このレポートはデプロイされた場所からアクセスできます

レポートには次の2つのバージョンが含まれています。

  • リカバリ・アプライアンスの保護されたデータベースのチャージバック - 最大

    テープ記憶域の使用率と、使用されているバックアップ記憶域と予測されるリカバリ・ウィンドウ記憶域使用率の高い方の値に基づいたチャージ計算を提供します。このモデルを使用すると、ユーザーは、前もって必要なリカバリ・ウィンドウ領域全体に対して支払います。

  • リカバリ・アプライアンスの保護されたデータベースのチャージバック - 最小

    テープ記憶域の使用率と、使用されているバックアップ記憶域と予測されるリカバリ・ウィンドウ記憶域使用率の低い方の値に基づいたチャージ計算を提供します。このモデルを使用すると、ユーザーは使用した領域に対してのみ支払います。

保護されたデータベースのチャージバック・レポートの各バージョンには、次の2つのセクションがあります。

  • リカバリ・アプライアンスでの保護されたデータベース領域のチャージバック

  • テープ上の保護されたデータベース領域のチャージバック

各セクションはさらに次のサブセクションに分かれます。

  • 月次チャージバック(過去12か月)

    このサブセクションは、次で構成されています。

    • 領域分類

    • 予算分類

  • 年次チャージバック

    このサブセクションは、次で構成されています。

    • 領域分類

    • 予算分類

  • 日次情報(過去30日間)

    過去30日間で選択した保護されたデータベースの現在の最大領域、最大リカバリ・ウィンドウ領域および最大予約済領域が表示されます。

領域分類には、次の情報が含まれています。

  • 現在の領域

    示された期間中にこの保護されたデータベースで現在使用されているリカバリ・アプライアンスのディスク領域の量を表します

  • 予約済領域

    この保護されたデータベースがリカバリ・ウィンドウ目標を達成するために予約されている、リカバリ・アプライアンスのディスク領域の最小量を表します

  • リカバリ・ウィンドウ領域

    この保護されたデータベースのリカバリ・ウィンドウ目標を達成するために必要な推定領域(GB)を表します

予算分類には、次の情報が含まれています。

  • チャージバック金額

    特定の期間にデータベースに対してチャージされた固定金額を表します

  • チャージバック金額デルタ

    現在レポートされた値と前回レポートされた値の間のチャージバックの差異を表します

保護されたデータベースのチャージバック・レポートの表示

Enterprise Manager Cloud Controlを使用して、保護されたデータベースのチャージバック・レポートにアクセスします。

レポートにアクセスする前に、My Oracle SupportノートのドキュメントID 2247393.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2247393.1)の情報を使用して、保護されたデータベース・チャージバック・レポートをBI Publisherにデプロイします。
保護されたデータベースのチャージバック・レポートを表示するには、次のようにします。
  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
  2. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。

    BI Publisher Enterpriseレポート・ページが表示されます。

  3. 「マイ・フォルダ」フォルダを展開し、「ZDLRA – 新規BIレポート(段階2)」フォルダを展開します。
  4. アクセスするレポートのバージョンに応じて、「リカバリ・アプライアンス - 保護されたデータベースのチャージバック - 最大」または「リカバリ・アプライアンス - 保護されたデータベースのチャージバック - 最小」をクリックします。
  5. 「リカバリ・アプライアンス」、「保護ポリシー」、「保護されたデータベース」、「リカバリ・アプライアンス - コスト$/GB」および「テープ - コスト$/GB」で必要な値を選択します。
  6. 「適用」をクリックして、レポートを表示します。

    「リカバリ・アプライアンス」と「テープへのコピー」の両方で、領域分類と予算分類が表示されます。

    次のグラフに、リカバリ・アプライアンスの保護されたデータベースT12E8Kの月次領域分類を示します。各月の表形式の詳細には、現在の最大領域、最大リカバリ領域および最大予約済領域が含まれています。グラフの下の表には、表形式で同じ情報が表示されます。列ヘッダーをクリックして、表示されたデータをソートしてフィルタします。

    テープの月次予算分類が次に表示されます。チャージバック金額およびチャージバック金額デルタを含むデータは、グラフ形式と表形式の両方で表示されます。

    次のイメージは、過去30日間のリカバリ・アプライアンスの日次情報を表示します。詳細には、現在の最大領域、最大リカバリ・ウィンドウ領域および最大予約済領域が含まれます。

    pdb_chargeback_ra_30days.gifの説明が続きます
    図pdb_chargeback_ra_30days.gifの説明

アクティブ・インシデント・レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスの現在のアクティブ・インシデントを表示する方法を説明します。データは、円グラフおよび表形式の両方で表示されます。

インシデント・レポートは、コンポーネント、保護されたデータベースまたはインシデントの重大度ごとに分類できます。

My Oracle SupportノートのドキュメントID 2247391.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2247391.1)の情報を使用して、インシデント・レポートをBI Publisherにデプロイします。

前提条件

環境において、次の文がtrueであると想定します。

  • インシデント・レポートをBI Publisherにデプロイするために必要な手順が完了しています。

    アクティブ・インシデント・レポートは、すぐに使用可能なレポートではありませんん。このレポートをデプロイした後、このレポートはデプロイされた場所からアクセスできます

アクティブ・インシデント・レポートを確認するには、次の手順を実行します。

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
  2. 「リカバリ・アプライアンス・インシデント」をクリックします。

    リカバリ・アプライアンス・インシデント・ページが表示されます。

  3. 「リカバリ・アプライアンス」リストからでリカバリ・アプライアンスの名前を選択し、「適用」をクリックします。

    選択されたリカバリ・アプライアンスのアクティブ・インシデント・レポートが表示されます。このレポートには、3つの円グラフと1つの表が含まれています。

    たとえば、ZDLRA Baltimoreを選択し、「適用」をクリックします。

    ページがリフレッシュされ、コンポーネント別のアクティブ・インシデントの円グラフ、保護されたデータベース別のアクティブ・インシデントの円グラフ、重大度別のアクティブ・インシデントの円グラフ、および表形式のレポートを含むレポートが表示されます。

    たとえば、次の円グラフは、各リカバリ・アプライアンス・コンポーネントのアクティブ・インシデントの割合を示しています。

    選択されたセクションによって示されるコンポーネントのアクティブ・インシデントの詳細を表示するには、グラフ内のセクションをクリックします。たとえば、スケジューラのアクティブ・インシデントの詳細を表示するには、SCHEDULERを示すセクションをクリックします。データベースごとのアクティブ・インシデント、重大度ごとのアクティブ・インシデント、およびレポートの表表示は、選択に基づいて自動的に更新されます。

  4. 保護されたデータベースで分類されたアクティブ・インシデントを表示します。

    たとえば、次のグラフは、6つの保護されたデータベースに対してレポートされたアクティブ・インシデントの統計を示しています。

    特定の保護されたデータベースを表すセクションをクリックすると、選択に基づいて他の円グラフおよび表のデータが自動的に更新されます。

  5. 重要度で分類されたアクティブ・インシデントを表示します。

    インシデントの重要度は次のいずれかとなります。

    • 内部的重大度: ただちに対処が必要なエラーを示します。最も高いインシデントの分類になります。

    • エラー重大度: 操作がエラーで終了したため、注意が必要であることを示します。

    • 警告重大度: 操作の結果が警告となったことを示します。実行の必要の可能性のある追加処置の警告を確認できます。

    次のグラフは、選択されたリカバリ・アプライアンスに対して、警告のみがあり、内部的重大度またはエラー重大度のインシデントがないことを示しています。

    このグラフの下には、次の例に示すような、表形式のアクティブの履歴レポートがあります。

API履歴レポートへのアクセス

このチュートリアルでは、DBMS_RAパッケージのプロシージャに対して行われたAPIコールの履歴を表示する方法を説明します。このレポートでは、データが円グラフおよびピボット・テーブル形式で表示されます。

API履歴レポートの円グラフは、APIコールごとに分類できます。レポートには、APIコールの名前、それらが実行したデータおよびコール数のある表も含まれます。

My Oracle SupportノートのドキュメントID 2247392.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2247392.1)の情報を使用して、API履歴レポートをBI Publisherにデプロイします。

前提条件

環境において、次の文がtrueであると想定します。

  • インシデント・レポートをBI Publisherにデプロイするために必要な手順が完了しています。

    API履歴レポートは、すぐに使用可能なレポートではありませんん。このレポートをデプロイした後、このレポートはデプロイされた場所からアクセスできます

API履歴レポートを確認するには、次の手順を実行します。

  1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
  2. 「API履歴の監査」をクリックします。

    API履歴の監査ページが表示されます。

  3. 「リカバリ・アプライアンス」リストからでリカバリ・アプライアンスの名前を選択し、「適用」をクリックします。

    選択されたリカバリ・アプライアンスのAPIコール履歴レポートが表示されます。次の例に示すように、行われたAPIコールの統計が円グラフに表示されます。

    グラフの下の表に、選択されたセクションによって示されるAPIコールの詳細を表示するには、グラフ内のセクションをクリックします。たとえば、グラフ右側のGRANT DBを表すセクションをクリックして、このAPIの履歴の詳細を表示します。表のデータは、選択に基づいて自動的に更新されます。

  4. API履歴を表形式で表示します。

    デフォルトで、次の例に示されるような、各APIコールに対して1つの列がある日付ごとのサマリーがレポートに表示されます。

    選択されたセルによって示されるAPIコールの詳細および日付を表示するには、サマリー内のセルをクリックします。