| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
この章では、Oracle Grid Controlを使用してアプリケーション・スタックのすべての層で高可用性環境を監視および管理するためのベスト・プラクティスについて説明します。
この章には、次の各項が含まれます。
システム、ネットワーク、データベース操作、アプリケーション、およびその他のシステム・コンポーネントを継続的に監視することで、問題を早期に検出できます。早期の検出により、問題を迅速に回避または解決できるため、ユーザーのシステム使用感が向上します。また、監視では、増加するシステム・パフォーマンスの傾向や再発する問題の傾向を示すシステム・メトリックを取得できます。この情報を使用して、予防対策の促進、セキュリティ・ポリシーの適用、およびジョブ処理の管理を行うことができます。データベース・サーバーでは、堅牢な監視システムで可用性を測定し、データベース・サーバーを使用不可能にする危険性のあるイベントを検出すると同時に、重大な障害については担当各所に即座に通知する必要があります。
監視システムは、それ自体が高可用性を保持し、監視対象のリソースと同じ運用ベスト・プラクティスと可用性プラクティスに準拠している必要があります。監視システムに障害が発生すると、すべての監視対象システムで診断データを取得することや管理者に問題を通知することができなくなります。
Oracle Grid Controlには、様々な通知オプションを備えた管理および監視機能が付属しています。環境の可用性およびパフォーマンスを監視する方法と、環境内の変化に対応してツールを使用する方法の推奨事項が含まれます。
Oracle Grid Controlの主なメリットは、ホスト・オペレーティング・システムからユーザー・アプリケーション（またはパッケージ・アプリケーション）までのアプリケーション・スタック全体で複数のコンポーネントを管理できることです。Oracle Grid Controlでは、アプリケーションの各レイヤーをターゲットとして扱います。ターゲット（データベース、アプリケーション・サーバー、ハードウェアなど）は、同じタイプの他のターゲットとともに表示するか、アプリケーション・タイプごとにグループ化することができます。また、すべてのターゲットを、HA Consoleから単一のビューで確認することも可能です（詳細は3.3.3項「高可用性コンソールを使用したデータベース可用性の管理」参照）。各ターゲット・タイプには、特定のターゲットに関連する詳細情報のサマリーを含む、デフォルトで生成されるホームページがあります。異なるタイプのターゲットは、機能ごとに（つまり、同じアプリケーションをサポートするリソースとして）グループ化できます。
すべてのターゲットは、Oracle管理エージェントによって監視されます。すべての管理エージェントは、任意のシステム上で稼働し、ターゲットのセットを監視対象とします。ターゲットは、管理エージェントが稼働するシステムとは別のシステム上にあってもかまいません。たとえば、管理エージェントでは、エージェントをネイティブにホストしないストレージ・アレイを監視できます。管理エージェントをホストにインストールすると、そのホストはマシン上の他のターゲットとともに自動的に検出されます。
さらにGrid Controlには、最大可用性アーキテクチャ（MAA）のベスト・プラクティス実装を支援するMAAアドバイザ（3.3.4項「MAAアドバイザを使用した高可用性ソリューションの構成」参照）が用意されています。MAAアドバイザのページでは、大部分の停止タイプにOracleソリューションを推奨し、各ソリューションの利点を説明しています。
図3-1に示すとおり、Oracle Grid Controlのホームページには、検出されたすべてのターゲットの可用性に関するグラフが表示されます。
Oracle Grid Controlのホームページには、主に次の種類の情報が表示されます。
すべてのターゲットを対象とする現在の可用性のスナップショット。可用性に関連付けられた円グラフにより、管理者は、使用可能なターゲット（「稼働中」）、使用不可能なターゲット（「停止中」）、またはコンソールとの通信が途絶えているターゲット（「不明」）を即座に判別できます。
監視対象システム全体で認識されているイベントのアラート数とジョブの問題数の概要。詳細情報を表示するには、対応するリンクをクリックするか、任意のOracle Grid Controlページの右上部分から「アラート」に移動します。
重大度と、すべての管理対象ターゲットでのポリシー違反の総数のビュー。ドリルダウンすると、違反のソースとタイプが判明します。
システム内で実際に何が検出されたかを示す概要情報。このリストは、ハードウェア・レベルとOracleレベルで表示できます。
「すべてのターゲット・ジョブ」には、すべてのEnterprise Managerジョブについて、スケジュール済の実行、実行中の実行、一時停止中の実行、問題のある実行（停止中/失敗）の数が一覧表示されます。ステータス・グループの隣にある数をクリックすると、それぞれのジョブのリストが表示されます。
アラートは、複数の要因の組合せにより生成されるもので、特定のメトリックに対して定義されます。メトリックは、管理エージェントにより調査されてOracle管理リポジトリに送信されるデータ・ポイントです。メトリックは、単純なハートビート・テストに基づくコンポーネントの可用性である場合や、特定のパフォーマンス測定（ディスク・ビジーまたは特定の待機イベントを待機するプロセスの割合など）の評価である場合があります。
どのメトリックでも、エラー、警告、クリティカルおよびクリアという4つの状態をチェックできます。管理者は、次のようなポリシーを決定する必要があります。
どのオブジェクトを監視するか（データベース、ノード、リスナー、またはその他のサービス）。
何を計測対象として調査するか（可用性、CPUビジー割合など）。
どの程度の頻度でイベントを調査するか。
事前定義されたしきい値をメトリックが超えたときに何を実行するか。
これらすべての項目は、システムのビジネス要件に基づいて決定します。たとえば、すべてのコンポーネントで可用性を監視する場合でも、一部のシステムは業務時間中にのみ監視することが可能です。特定のパフォーマンス問題のあるシステムでは、問題をデバッグするために、追加のパフォーマンス・トレース機能を有効化できます。
|
関連項目: Oracle Grid Controlでメトリックを監視および使用する方法の詳細は、『Oracle Enterprise Manager概要』を参照してください。 |
通知ルールは、Oracle Grid Controlに検出されたターゲットに自動的に適用される、メトリックに対する定義済のアラートのセットです。たとえば、管理者は、データベース・ターゲットの可用性を監視して、データベースに障害が発生した場合は電子メール・メッセージを生成するルールを作成できます。作成したルールは、既存のすべてのデータベースと、将来作成される任意のデータベースに適用できます。これらのルールにアクセスするには、「プリファレンス」に移動し、「ルール」を選択します。
ルールでは、サービス可用性に影響する可能性のある問題など、即座に対処する必要のある問題や、Oracleエラーまたはアプリケーション・エラーを監視します。サービス可用性は、アプリケーション・スタックの任意のレイヤー（ノード、データベース、リスナー、重大なアプリケーション・データなど）の停止によって影響を受けます。データベースに接続できない、またはアプリケーション機能に不可欠なデータにアクセスできないなどのサービス可用性の障害については、迅速に特定してレポートを確認し、問題に対処する必要があります。アーカイブ・ログ・ディレクトリが一杯であるなど、サービス停止につながる可能性のある問題も、システム停止を避けるために適切に対処する必要があります。
Oracle Grid Controlには、可用性を監視するための強力なフレームワークとなる一連のデフォルト・ルールが含まれます。デフォルト・ルールは、Oracle Grid Controlに付属する事前インストール済のターゲット・タイプごとに用意されています。これらのルールは、個々のサイトのポリシーに合せて変更できます。また、サイト固有のターゲットまたはアプリケーション用にルールを作成することも可能です。特定期間中にユーザーに通知するようルールを設定して、自動カバレッジ・ポリシーを作成することもできます。
次のベスト・プラクティスを使用します。
ターゲット・アーキテクチャの重要なコンポーネントの各ルールは、ルール変更ウィザードを使用して可用性要件を満たすように変更します。データベース・ルールの場合、ターゲットごとに表3-1、表3-2および表3-3のイベントを設定します。監視頻度は、各コンポーネントの品質保証契約（SLA）に基づいて決定します。
ビーコン機能を使用して、個々のアプリケーションのパフォーマンスを追跡します。ビーコンを設定すると、通常のアプリケーション作業のかわりとなるユーザー・トランザクションを実行できます。Enterprise Managerでは、このトランザクションのレスポンス時間を分析用のコンポーネントに分割します。また、このトランザクションの実行時間が事前定義済の制限値を超えた場合、アラートを起動できます。
通知メソッドを追加して各通知ルールで使用します。デフォルトでは、潜在的な問題を管理者に通知する最も簡単な方法は、電子メールの送信です。この通知メソッドを拡張するため、電子メール以外の方法でアラートを送信するSNMPトラップまたはオペレーティング・システム・スクリプトへのコールアウトを追加できます。これにより、電子メール・システムのコンポーネントが停止した場合に問題が発生することを回避できます。追加の通知メソッドを設定するには、任意のOracle Grid Controlページの上部にある「設定」リンクを使用します。
ターゲットの可用性の計算でエラーが発生した場合に管理者に通知するよう通知ルールを変更します。これにより、コンポーネントの可用性の誤った読取りが発生することもありますが、システム管理者にとって最高度の通知レベルが保証されます。
|
関連項目:
|
図3-2は、可用性状態を選択するための「通知ルールの編集: 」プロパティ・ページを示しています。「停止中」オプションが選択されています。
また、データベース・ルールにより監視されるメトリックを変更して、表3-1、表3-2および表3-3に記載されているメトリックをレポートします。すべてのデータベース・ターゲットを対象にこれらのメトリックを収集することで、将来の分析において傾向データを使用できます。表3-1、表3-2および表3-3に記載されているすべてのイベントにアクセスするには、データベースのホームページで「メトリックとポリシー設定」を選択します。
サービス停止の原因となる可能性のある領域管理の条件は、表3-1のイベントを使用して監視します。
表3-1 領域を監視するための推奨事項
| メトリック | 推奨事項 |
|---|---|
|
表領域使用率（%） |
このデータベース・レベルのメトリックを設定すると、各表領域の使用可能な領域の使用率（%）をチェックできます。クラスタ・データベースでは、このメトリックは、メンバー・インスタンス単位ではなく、クラスタ・データベース・ターゲット・レベルで監視されます。このメトリックを使用する場合、管理者は、Oracle Grid Controlがテスト対象とするしきい値の割合と、メッセージを管理者に生成および送信する前に検出を必要とするエラーの発生数を選択できます。使用済領域の割合がしきい値の引数で指定された値を超えると、警告アラートまたはクリティカル・アラートが生成されます。 デフォルト設定は、85%を警告、97%を領域使用率のクリティカルしきい値とすることをお薦めしますが、これらの値はシステムの使用状況に応じて適切に調整してください。また、このメトリックは、特定の表領域を監視するようカスタマイズできます。たとえば、このメトリックを設定すると、 このメトリックと類似イベントは、 |
|
アーカイバの停止 アラート・ログ・エラー |
このメトリックを設定すると、アーカイブREDOログ・ディレクトリが一杯であることを示す このメトリックは、「アラート・ログ・エラー・ステータス」メトリック・グループで設定します。 |
|
ダンプ領域使用率（%） |
このメトリックを設定すると、ダンプ出力先ディレクトリを監視できます。最初にエラーが発生したときに最大量の診断情報を保存するためには、ダンプ領域が使用可能である必要があります。デフォルト設定は、70%で警告、90%でエラーとすることをお薦めしますが、これらの値はシステムの使用状況に応じて調整してください。 このメトリックは、「ダンプ領域」メトリック・グループで設定します。 |
|
リカバリ領域空き領域(%) |
これは、15分ごと、またはファイル作成時のいずれか早い方の時点で、サーバーにより評価されるデータベース・レベルのメトリックです。このメトリックは、アラート・ログにも出力されます。クラスタ・データベースでは、このメトリックは、メンバー・インスタンス単位ではなく、クラスタ・データベース・ターゲット・レベルで監視されます。 クリティカルのしきい値は3%未満に、警告のしきい値は15%未満に設定されています。これらのしきい値はカスタマイズできません。アラートが最初に発生したときに警告が戻されます。アラートは、使用可能な領域が15%を超えるまでクリアされません。 関連項目: 「リカバリ領域空き領域(%)」メトリックの設定方法の詳細は、サポート・ノート467653.1を参照してください（ |
|
使用可能なファイル・システム（%） |
デフォルトで、このメトリックにより各ホストのルート・ファイル・システムを監視します。デフォルトの警告レベルは20%で、クリティカル警告は5%です。 |
|
アーカイブ領域使用率(%) |
このメトリックを設定すると、アーカイブ領域保存先の領域使用率が戻されます。使用済領域がしきい値の引数で指定されたしきい値を超えると、警告アラートまたはクリティカル・アラートが生成されます。データベースが |
「アラート・ログ」メトリック・グループで、表3-2のエラーについてアラート・ログを監視するようOracle Grid Controlを設定します。
表3-2 アラート・ログを監視するための推奨事項
| メトリック | 推奨事項 |
|---|---|
|
アラート |
このメトリックを設定すると、 |
|
データ・ブロックの破損 |
このメトリックを設定すると、 |
処理容量を超えることがないようシステムを監視します。これらのイベントの警告レベルとクリティカル・レベルは、システムの使用パターンに基づいて変更してください。表3-3の推奨事項を使用して、「データベース制限」メトリック・グループでイベントを設定します。
表3-3 処理容量を監視するための推奨事項
| メトリック | 推奨事項 |
|---|---|
|
プロセス制限 |
このメトリックのしきい値を設定すると、現在のプロセス数が |
|
セッション制限 |
このメトリックのしきい値を設定すると、インスタンスがデータベースに許可されている同時接続の最大数に接近したときに警告を生成できます。 |
図3-3は、メトリックを選択および編集するための「メトリックとポリシー設定」ページを示しています。オンライン・ヘルプには、すべてのメトリックに関する完全なリファレンス情報があります。個別のメトリックのリファレンス情報にアクセスするには、オンライン・ヘルプの検索機能を使用します。
|
関連項目:
|
図3-4の「データベース・ターゲット」ページには、システム・パフォーマンス、領域使用量、および重要な可用性コンポーネントの構成（アーカイブREDOログ・ステータス、フラッシュバック・ログ・ステータス、推定インスタンス・リカバリ時間など）の概要を示した、データベースの「ホーム」ページが表示されます。また、アラートも即座に表示されます。各アラート値は、このページのリンクを使用して構成できます。
Oracle Grid Controlのメトリックの多くは、パフォーマンスに関連します。パフォーマンス品質保証契約に到達しないシステムは、HAシステムの要件を満たしません。パフォーマンスの問題が大規模なシステム停止の原因となることはまれですが、それでも顧客の一部に対するサービスを停止させる可能性があります。このタイプの停止は、一般的にアプリケーション・サービス低下と呼ばれます。サービス低下の主な原因は、1つ以上のインフラストラクチャ・コンポーネントの断続的または部分的障害です。ITマネージャは、インフラストラクチャ・コンポーネントの稼働状況（レスポンス時間、待機時間および可用性）と、エンド・ユーザーに提供されるアプリケーション・サービスの品質に対するこれらのコンポーネントの影響を把握しておく必要があります。
パフォーマンス・ベースラインは、品質保証契約を満たす通常の操作から導出されるもので、パフォーマンス・メトリック・アラートの構成項目を決定する際の基準となります。ベースライン・データは、アプリケーションが本番環境に導入された初日から収集します。ベースライン・データには、次の統計が含まれる必要があります。
アプリケーション統計（トランザクション量、レスポンス時間、Webサービス時間）
データベース統計（トランザクション率、REDO速度、ヒット率、上位5位の待機イベント、上位5位のSQLトランザクション）
オペレーティング・システム統計（CPU、メモリー、I/O、ネットワーク）
Oracle Grid Controlを使用すると、ベースラインとしてデータベース・パフォーマンスのスナップショットを取得できます。Oracle Grid Controlでは、これれらの値をシステム・パフォーマンスと比較して、その結果をデータベース・ターゲットのページに表示します。基準のベースラインから値が大きく逸脱した場合に、アラートを送信することも可能です。
すべてのデータベース・ターゲットに対して、表3-4のメトリックを取得するようデータベース通知ルールを設定します。それにより、1つのツールでこれらのパラメータを分析することができます。履歴データも利用できます。
表3-4 メトリックの推奨通知ルール
| メトリック | 推奨事項 |
|---|---|
|
1秒当たりのディスクI/O |
これは、データベースにより実行されるI/O操作を監視するデータベース・レベルのメトリックです。このメトリックは、操作の数がユーザー定義のしきい値を超えたときにアラートを送信します。このメトリックは、Oracle Grid Controlで同様に使用できるオペレーティング・システム・レベルのイベントと組み合せて使用します。 このメトリックは、システムで使用可能な合計I/Oスループット、使用可能なI/Oチャネルの数、ネットワーク帯域幅（SAN環境の場合）、ディスク・キャッシュの効果（ストレージ・アレイ・デバイスを使用している場合）、最大I/Oレート、およびデータベースで使用可能なスピンドルの数に基づいて設定します。 |
|
CPU使用率(%) |
UNIXベースのプラットフォームの場合、このメトリックは、使用可能なCPU処理性能全体に対する割合としてCPUの使用率を示します。Windowsの場合、このメトリックは、アイドル状態ではないスレッドを実行するのにCPUが費やした時間の割合を示します。「CPU使用率(%)」はプロセッサ・アクティビティの主要インジケータです。 このメトリックは、80%で警告、95%でクリティカル・アラートを自動的に表示するよう設定されています。 |
|
%待機時間 |
過剰なアイドル時間は、1つ以上のリソースにボトルネックが発生していることを示します。このメトリックは、アプリケーションが問題なく動作しているときのシステム待機時間に基づいて設定します。 |
|
1秒当たりのネットワーク・バイト |
このメトリックは、Oracleによって生成されるネットワーク・トラフィックをレポートします。その内容は、潜在的なネットワーク・ボトルネックを示します。このメトリックは、ピーク期間中の実際の使用状況に基づいて設定します。 |
|
1秒当たりの合計解析 |
このメトリックは、SQLパフォーマンスを測定します。その内容は、リソース不足の原因であるアプリケーション変更または使用状況の変更を示します。このメトリックは、ピーク期間に基づいて設定します。 |
|
関連項目:
|
推奨メトリックの補足に使用できる多くのオペレーティング・システム・イベントがあります。このようなオペレーティング・システム・イベントは、ホストやインスタンスごとに設定する必要はありません。定義済のすべてのメトリックは、オブジェクト・ターゲット・ページのナビゲーション・バーの下部にある「メトリックの管理」リンクを使用して、インスタンスまたはデータベースごとに個別に設定できます。警告アラートまたはクリティカル・アラートを起動する値は、この場所で変更できます。また、Oracle Grid Controlで生成される標準のアラート以外に、オペレーティング・システム・スクリプトをアクティブ化してメトリックしきい値に応答することも可能です。
Oracle Grid Controlのメトリックを設定すると、Data Guardの論理構成および物理構成の可用性を監視できます。表3-5に、Data Guardデータベースの監視に利用できるイベントを示します。
表3-5 Data Guardイベントを設定するための推奨事項
| メトリック | 推奨事項 |
|---|---|
|
Data Guard構成におけるシステムの問題について通知します。 |
|
|
プライマリ・データベースに対するスタンバイの遅れを表示します（単位は秒）。遅れが、ユーザーが指定したしきい値（指定した場合）を超過すると、このメトリックによりスタンバイ・データベース上でアラートが生成されます。 |
|
|
このスタンバイ・データベースにフェイルオーバーするのに必要な時間のおよその秒数を表示します。 |
|
|
このスタンバイ・データベース上でのREDO Apply速度を表示します（単位はKB/秒）。 |
|
|
このスタンバイ・データベースでまだ利用できないREDOのおよその秒数を表示します。ラグがあるのは、REDOデータが未転送だったり、ギャップがある可能性があったりするためです。遅れが、ユーザーが指定したしきい値（指定した場合）を超過すると、このメトリックによりスタンバイ・データベース上でアラートが生成されます。 |
Oracle Grid Controlは、問題の通知と分析以外に、任意のシステムのプロアクティブな管理に使用できます。この項には、次の推奨事項が含まれます。
Oracle Grid Controlには、すべてのデータベースのベスト・プラクティスとして、ポリシーと推奨事項の事前インストール済のセットが付属しています。これらのポリシーはデフォルトでチェックされ、違反の数は図3-4のように「ターゲット」ページに表示されます。すべての違反のリストを参照するには、「ターゲット」ページで「ポリシー違反」を選択します。
|
関連項目: 既存のポリシー定義の詳細は、『Oracle Enterprise Managerポリシー・リファレンス・マニュアル』を参照してください。 |
Oracle Grid Controlを使用して、アプリケーション環境の監視対象システムに適用するパッチをMy Oracle Support（旧OracleMetalink http://metalink.oracle.com/）からダウンロードして管理できます。ジョブを設定して、ユーザー環境に関連するパッチを定期的にチェックできます。これらのパッチは、ダウンロードして管理リポジトリに直接保存できます。パッチは、管理リポジトリから複数のシステムにステージングして、メンテナンス・ウィンドウ中に適用できます。
あるシステムのパッチ・レベルを調査して、それらを1対1または1対多の関係において複数のシステム間で比較できます。この場合、1台のシステムをベースラインとして区別し、他の複数のシステムにおけるメンテナンス要件の実証に使用できます。この機能は、データベース・パッチと同様に、オペレーティング・システム・パッチにも使用可能です。
高可用性（HA）コンソールは、各データベースの可用性を一箇所で監視できる、ダッシュボード・スタイルのページです。あらゆるデータベース上で使用でき、データベースがData Guard構成の一部の場合、HAコンソールで、プライマリ・データベースから任意のスタンバイ・データベースにビューを変更することができます。
HAコンソールを使用すると、次のことが可能です。
関連ターゲット（スタンバイ・データベースなど）からのイベントなどの、高可用性イベントの表示
データベースのステータスなど、高可用性サマリーの表示
最後のバックアップ・ステータスの表示
フラッシュ・リカバリ領域が構成されている場合、その使用量の表示
Oracle Data Guardが構成されている場合: Data Guardサマリーの表示、任意のデータベース・ターゲットに対するData Guardスタンバイ・データベースのセットアップ、管理リポジトリを含むデータベース以外のデータベース・ターゲットのスイッチオーバーとフェイルオーバーの管理、およびData Guard構成の状態の集中監視
Oracle RACが構成されている場合: 上位サービスなどのOracle RACサービスのサマリーの表示
HAコンソールには、Oracle Enterprise Managerの管理エージェント（リリース10.2.0.5）と、Grid Controlリリース10.2.0.5が必要です。
|
関連項目: Grid Controlリリース10.2.0.5を実行するための運用要件、および標準的な管理設定の確立についての情報は、『Oracle Enterprise Manager Grid Controlクイック・スタート・ガイド』と『Oracle Enterprise Manager概要』を参照してください。 |
次のHAコンソールのスクリーンショットには、プライマリ・データベースのサマリー情報、詳細および履歴統計情報が表示されています。例のページには、プライマリ・ターゲットのスタンバイ・データベース、様々なData Guardスタンバイ・パフォーマンス・メトリックおよび設定、データ保護モードが示されています。
「可用性のサマリー」は、プライマリ・データベースが稼働中で、その可用性が現在99.09%であることを示しています。可用性のパーセンテージは、ページ右端の「可用性履歴」で、さらに「日」、「週」、「月」の、横向き棒グラフに分割されています。このデータベースはOracle RACデータベース（クラスタdglnx-cl1内）なので、「可用性のサマリー」にはインスタンス・ステータスも示されます。このデータベースにASMが構成されている場合は、ASMステータスも表示されます。「可用性イベント」セクションには、特定の高可用性イベント（アラート）が示されます。エラーをクリックすると、詳細情報を表示することができます（あるいは、そのイベントが簡略表示に戻ります）。このデータベースで特定のソリューション領域をセットアップ、管理および構成するには、「MAAアドバイザ」の「詳細」をクリックして、「最大可用性アーキテクチャ(MAA)アドバイザ」ページに移動します（詳細は3.3.4項「MAAアドバイザを使用した高可用性ソリューションの構成」を参照）。
「バックアップ/リカバリ・サマリー」には、「最終バックアップ」および「次のバックアップ」情報が表示されます。「フラッシュ・リカバリ領域の使用量」グラフは、フラッシュ・リカバリ領域のおよそ1.35%が現在使用されていることを示しています。「使用済(再利用不可能)フラッシュ・リカバリ領域(%)」グラフには、過去2時間の使用量が表示されます。グラフをクリックすると、メトリック詳細のページが表示されます。
「Data Guardサマリー」は、プライマリ・データベースが「最大パフォーマンス」モードで稼働していて、ファスト・スタート・フェイルオーバーが有効化されていることを示しています。「保護モード」の隣のリンクをクリックすると、データ保護モードを変更できます。「スタンバイ・データベース」表を見ると、フィジカル・スタンバイ・データベース（west）はプライマリ・データベースのメトリック（「適用ラグ」/「トランスポート・ラグ」）に追随しており、使用済フラッシュ・リカバリ領域（「使用済FRA」）は0.5%です。「プライマリ・データベースREDO率」グラフには、過去2時間のREDO傾向が示されます。Data Guardが構成されていない場合、コンソール右上隅の「切替え」ボックスは表示されません。
「サービス・サマリー」には、顧客、注文およびSalesサービスの詳細が表示されます。
図3-6の説明は、「Data Guardサマリー」セクションと、ページ右下のグラフを除いて、図3-5「HAコンソールでのプライマリ・データベースの監視」と同じです。図3-6は、スタンバイ・データベース（west）の情報を示しています。これは、リアルタイム問合せを実行しているフィジカル・スタンバイ・データベースです。「スタンバイ・データベース」表は、「適用ラグ」/「トランスポート・ラグ」のメトリックがフィジカル・スタンバイ・データベースがプライマリ・データベースに追随していて、使用済フラッシュ・リカバリ領域（「使用済FRA」）は0.5%であることを示しています。「スタンバイ・データベース適用ラグ」グラフには、過去2時間、遅れがなかったことが示されています。Data Guardが構成されていない場合、コンソール右上隅の「切替え」ボックスは表示されません。
MAA Advisorは、最適な高可用性アーキテクチャを実現するためのOracleベスト・プラクティスの実装を支援するために設計されています。
高可用性コンソールの「可用性のサマリー」セクションでは、MAAアドバイザへのリンクで次のことが可能です。
各停止タイプ（サイト障害、コンピュータ障害、ストレージ障害、ヒューマン・エラーおよびデータ破損）の推奨Oracleソリューションの表示
構成ステータスの表示、「Oracleソリューション」列のリンクを使用した「Enterprise Manager」ページへの移動、およびそこでのソリューションの構成
各ソリューションの利点の把握
ホワイト・ペーパー、ドキュメントなどの情報があるMAA Webサイトへのリンク
「MAAアドバイザ」ページの表には、停止タイプ、それぞれの停止に対するOracleソリューション、構成ステータス、および利点が表示されます。MAAアドバイザを使用すると、次のようにしてHAソリューションを表示できます。
プライマリ・データベースの推奨事項のみ: プライマリ・データベースの推奨ソリューション（デフォルト・ビュー）のみを簡略表示します。
すべてのプライマリ・データベースのソリューション: 表の拡張ビューです。プライマリ・データベースのすべての推奨構成およびステータスが表示されます。
すべてのデータベースのソリューション（スタンバイを含む）: 表の拡張ビューです。この構成のすべてのプライマリおよびスタンバイ・データベースの、すべての推奨構成およびステータスが表示されます。追加のターゲット名/ロール列にデータベース名と、データベースのロール（プライマリ、フィジカル、ロジカルのいずれか）が表示されます。
図3-7は、すべてのプライマリ・データベースのソリューションを表示するビューの例を示しています。
「Oracleソリューション」列でリンクをクリックすると、移動先のページで特定のソリューション領域をセットアップ、管理および構成することができます。ソリューションの構成が終わったら、「リフレッシュ」をクリックしてページ上の構成ステータスを更新します。ページがリフレッシュされたら、「コンソール」ページで「アドバイザの詳細」をクリックして、更新された値を参照します。
