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