この章では、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レポートが用意されています。
このレポートではリカバリ・アプライアンスの記憶域の概要を示し、容量が使い尽くされる時期を予測できるようにします。特に便利なのがサマリー表で、容量を超過するまでの日数のクイック・ビューが示されます。ネットワーク容量計画サマリーでは、様々な期間にわたるネットワーク・トラフィック合計のビューを提供します。このビューには、ネットワーク・サンプルに基づく平均レートと最大レートの両方が表示されます。
このレポートは、容量計画のより詳細な情報を提供します。記憶域容量、ネットワーク・スループット、保護されたデータベース・ホストそれぞれのCPU使用率、一定期間におけるディスクおよびフラッシュ・ストレージのI/Oスループットについての情報を提供します。容量計画サマリーとは異なり、詳細レポートにはメモリーおよびIOPSサマリー情報や詳細な日次データも表示されます。
リカバリ・ウィンドウ・サマリー
このレポートは、リカバリ・ウィンドウ目標を達成していない、または保護されていないウィンドウのしきい値を超えている保護されたデータベースのリストを示します(「CREATE_PROTECTION_POLICY」のunprotected_window
を参照)。このレポートをリカバリ・アプライアンスのリカバリ・ウィンドウおよび保護されていないデータ・ウィンドウに関する問題のクイック・ビューとして使用し、保護されたデータベースの詳細レポートを使用して保護されたデータベースを個別にフォローアップすることができます。
このレポートには、次のサマリーを含め、保護されたデータベースについての広範なステータス情報が含まれます。
予約済領域。これは、データベースがディスク・リカバリ・ウィンドウ目標を達成するために予約されている、リカバリ・アプライアンスのディスク領域の最小量です。
データ損失を排除するリアルタイムREDOトランスポートのステータス。
バックアップ操作、copy-to-tape操作およびリカバリ・アプライアンス・レプリケーション操作のために一定期間にわたって送受信されたデータ。これらにより、保護されたデータベースとリカバリ・アプライアンスとの間のトラフィックの概要を把握できます。
このレポートでは、リカバリ・アプライアンスとの間で転送されたバックアップ・データの量に従って、上位10の保護されたデータベースをランク付けします。このレポートでは、毎時または毎日データを集計します。特に、このレポートでは次の量を測定します。
リカバリ・アプライアンスに送信されたバックアップ・データ
リカバリ・アプライアンスによって送信されたレプリケーション・データ
リカバリ・アプライアンスによって送信されたCopy-to-tapeデータ
このレポートは、ランク付けされたデータベースのバックアップによって使用されている領域の量と直接は関係ありません。
前述のレポートには、BI publisherを介してのみアクセスできます。また、Cloud Controlに付属するBI Publisherソフトウェアは、Enterprise Managerリポジトリ内のデータにのみアクセス可能で、リカバリ・アプライアンス・スキーマのデータにはアクセスできません。
注意:
パフォーマンス・データにはV$
のSQL問合せおよびリカバリ・カタログ・ビューを介してアクセスできますが、BI Publisherレポートを使用することを強くお薦めします。リカバリ・アプライアンスのCPUおよびその他のリソースには限りがあるため、頻繁にまたは負荷の高いSQL問合せを実行すると、リカバリ・アプライアンスの全体的なパフォーマンスが低下することがあります。
関連項目:
すべてのリカバリ・アプライアンス・ビューの完全なリストについては、「リカバリ・アプライアンスのビュー・リファレンス」を参照してください
Oracle Enterprise Managerライセンス情報
リカバリ・アプライアンス・レポート・ページにアクセスするには:
「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。
「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。
BI Publisher Enterpriseレポート・ページが表示されます。
Enterprise Manager Cloud Controlフォルダ、リカバリ・アプライアンス・レポート・サブフォルダの順に展開します。
事前作成されているレポートへのリンクが表示されます。
関連項目:
BI Publisherでレポートを表示する方法については、Cloud Controlオンライン・ヘルプを参照してください。
この項では、レポートの管理に関する基本的なタスクについて説明します。図11-1は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、レポート・タスクを強調して示したものです。
通常、レポート・タスクを実行する順序は次のとおりです。
計画フェーズでは、Cloud Controlを介して使用できるモニタリング・ツールとレポート・ツールについての理解を深めます。
「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。
進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じてレポートをレビューします。一般的なタスクには次のものがあります。
容量計画詳細を使用して記憶域容量計画サマリーを毎週レビューし、詳細情報を取得します。
このタスクについては、「記憶域容量レポートへのアクセス」に説明されています。
必要に応じて、保護されたデータベース・レポートをレビューします。
このタスクについては、「リカバリ・ウィンドウ・サマリー・レポートへのアクセス」に説明されています。
このタスクについては、「リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス」に説明されています。
このタスクについては、「保護されたデータベースのデータ転送レポートへのアクセス」に説明されています。
このチュートリアルでは、リカバリ・アプライアンスの記憶域容量レポートを表示する方法について説明します。
前提条件
リカバリ・アプライアンス環境において、次の文がtrueであると想定します。
2週間以上前に、ZDLRA London
という名前のリカバリ・アプライアンスが設定されました。
20の保護されたデータベースをZDLRA London
にバックアップします。
記憶域容量についてのレポートをレビューするには:
「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
容量計画サマリーをクリックします。
BI Publisher Enterpriseのページが表示されます。
BI Publisherの資格証明を入力して、「サインイン」をクリックします。
容量計画サマリー・ページが表示されます。
「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Londonを選択します。
「記憶域容量計画サマリー」セクションをレビューして、記憶域増加率および容量を超過するまでの日数を特定します。
たとえば、次の図はZDLRA Londonのサマリーを示しています。
主要なメトリックは、容量を超過するまでの日数の6.85です。1週間以内に、リカバリ・アプライアンスは保護ポリシーの設定に応じて、バックアップをパージするか受信バックアップを拒否します(「コピーの保証」を参照)。
履歴記憶域トレンドを表示します。
たとえば、先週のトレンドを確認します。
前述のチャートは、過去2日間にわたって、すべての保護されたデータベースのリカバリ・ウィンドウ目標を満たすために必要な領域合計が5.2TBから21TBに増加したことを示しています。保護されたデータベースの数は20で安定しています。
ネットワーク容量計画サマリーで、ネットワーク・スループットを確認します。
たとえば、先週のネットワーク・スループットを確認します。
前述のチャートは、過去2日間、受信速度が急激に上昇していることを示しています。
ネットワーク容量計画サマリーでは、様々な期間(24時間、7日、30日)にわたるネットワーク・トラフィック合計のビューを提供します。
事前作成されたレポートのページに戻ります。
容量計画詳細をクリックします。
リカバリ・アプライアンス: 容量計画 - 詳細ページが表示されます。
このレポートは、容量計画サマリーよりも詳細な情報を提供します。容量計画レポートとは異なり、詳細レポートにはメモリーおよびIOPS情報も表示されます。
必要なリカバリ・アプライアンスが「リカバリ・アプライアンス」でまだ選択されていない場合は、選択して「適用」をクリックします。
レポートの冒頭で「記憶域容量計画詳細」をクリックして、このセクションにジャンプします。
「IO履歴データ」セクションの「セル・ディスクIO」サブセクションにスクロール・ダウンします。
たとえば、次の表に記憶域サーバーごとの15分間隔でのIOPSおよびスループットを示します。
このチュートリアルでは、リカバリ・アプライアンスで保護されているデータベースのリカバリ・ウィンドウ・サマリーを表示する方法について説明します。
前提条件
環境において、次の文がtrueであると想定します。
ZDLRA Montreal
という名前のリカバリ・アプライアンスは、13のデータベースを保護します。
リカバリ・ウィンドウを満たしていないデータベースがあるかどうかを特定したいと考えています。
リカバリ・ウィンドウ・サマリー・レポートをレビューするには:
「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
「リカバリ・ウィンドウ・サマリー」をクリックします。
リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。
BI Publisherの資格証明を入力して、「サインイン」をクリックします。
リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。
「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Montrealを選択します。
ページがリフレッシュされ、次の例のように上部にサマリーが表示されます。
円グラフは、75%を超えるデータベースがサービス・レベル合意を満たしていないことを示しています。表は、合計13のデータベースのうち、3つのデータベースがリカバリ・ウィンドウ目標を満たしていないことを示しています。また、8つのデータベースが、保護されていないデータしきい値内に入っていません。
チャートを下にスクロールすると、リカバリ・ウィンドウ目標を満たしていないデータベースが表示されます。
次の例で、2つのサンプル・レポートを示します。
前述の例は、データベースDB1116
とDB1123
の両方ともリカバリ・ウィンドウ目標は1日であるが、この目標に何時間も達していないリカバリ・ウィンドウがあることを示しています。DB11242
の目標も1日ですが、実際のリカバリ・ウィンドウは1時間未満です。
保護されたデータベースの詳細レポートには、リカバリ・アプライアンス・レポート・ページまたは保護されたデータベース・ページからアクセスできます。
このアクセス・パスは、「エンタープライズ」メニューを使用してリカバリ・アプライアンス・レポート・ページに移動する代わりの方法です。
保護されたデータベースの詳細ページにアクセスするには:
「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。
たとえば、ZDLRA Montreal
のホームページにアクセスします。
「リカバリ・アプライアンス」メニューから、「保護されたデータベース」を選択します。
保護されたデータベース・ページが表示されます。
「保護されたデータベース」表でデータベースを選択します。
たとえば、DB1124を選択します。
ページの下部で、「保護されたデータベースの詳細」セクションがリフレッシュされます。
「保護されたデータベースの詳細」セクションで「ステータス」選択します。
次の例に示すように、「ステータス」サブページが表示されます。
「保護されたデータベースのレポート」をクリックします。
BI Publisherページが表示されます。
BI Publisherの資格証明を入力して、「サインイン」をクリックします。
リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます(「リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス」の手順4を参照)。
このチュートリアルでは、保護されたデータベースの詳細レポートにアクセスする方法について説明します。
前提条件
ZDLRA Philadelphia
という名前のリカバリ・アプライアンスは、12のデータベースを保護するとします。
保護されたデータベースについてのレポートをレビューするには:
「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
「保護されたデータベースの詳細」をクリックします。
リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。
注意:
「保護されたデータベース・ページからの詳細レポートへのアクセス」に説明されているように、このレポートには保護されたデータベース・ページから直接アクセスすることもできます。
「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択します。
たとえば、ZDLRA Montrealを選択します。
「保護されたデータベース」でデータベースを選択し、「適用」をクリックします。
たとえば、DB1124を選択します。
リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。
「バックアップ/リカバリ」セクションにスクロール・ダウンします。
たとえば、次の図にDB1124データベースの統計値を示します。
前の統計は、データベースがリカバリ・ウィンドウ目標を達成するには182.83GBが必要なことを示しています。
バックアップ履歴を確認します。
たとえば、次のチャートは、先週DB1124によって送受信されたデータを示しています。
前のチャートは、日次バックアップ・データが8/25 (この日は305.1GB)を除いて毎日31~49GBであったことを示しています。毎日、送信されたレプリケーション・データ量は受信したバックアップ・データよりも若干少ない量でした。
必要なだけ前述の2つの手順を繰り返して、すべての保護されたデータベースのバックアップ・アクティビティを調査します。
このチュートリアルでは、リカバリ・アプライアンスのデータ転送レポートを表示する方法について説明します。
前提条件
環境において、次の文がtrueであると想定します。
ZDLRA Montreal
という名前のリカバリ・アプライアンスは、10のデータベースを保護します。
リカバリ・アプライアンスは一部のデータベースについては、バックアップをレプリケートしますがテープにはアーカイブしません。
過去1週間にわたって最もデータを転送したデータベースを特定したいと考えています。
データ転送レポートをレビューするには:
「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。
データ転送別上位10の保護されたデータベースをクリックします。
BI Publisher Enterpriseのページが表示されます。
BI Publisherの資格証明を入力して、「サインイン」をクリックします。
データ転送別上位10の保護されたデータベース・ページが表示されます。
「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Montrealを選択します。
「バックアップ・データ別上位10のデータベース」をクリックします。
「バックアップ・データ」セクションが表示されます。
「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。
たとえば、09/08から09/15の期間のデータは次のとおりです。
前のチャートによると、データベースDB12CDB
はほとんどのデータを毎日バックアップしました。ピーク転送は09/09で、約1.25TBでした。
レポートの上部に戻って「レプリケーション・データ別上位10のデータベース」をクリックします。
「レプリケーション・データ」セクションが表示されます。
「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。
たとえば、09/08から09/15の期間のデータは次のとおりです。
前のチャートによると、データベースDB12CDB
はほとんどのデータを毎日レプリケートしました。ピーク転送は09/11で、約1.7TBでした。