プライマリ・コンテンツに移動
Oracle® Data Guard Broker
12cリリース1 (12.1)
B71305-08
目次へ移動
目次
索引へ移動
索引

前
次

1 Oracle Data Guard Brokerの概要

次のトピックでは、Oracle Data Guard Broker、そのアーキテクチャとコンポーネント、およびOracle Data Guard構成の作成、制御および監視の自動化の方法について説明します。

Oracle Data Guard構成の定義およびOracle Data Guardの概念と用語の詳細は、『Oracle Data Guard概要および管理』を参照してください。

1.1 Oracle Data Guardおよびブローカの概要

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Oracle Data Guardでは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットが用意されており、本番のOracleデータベースを障害やデータ破損からリカバリできます。Oracle Data Guardでは、これらのスタンバイ・データベースが、トランザクション的に一貫性のあるプライマリ・データベースのコピーとして維持されます。計画的または計画外の障害によりプライマリ・データベースが使用できなくなると、Oracle Data Guardは任意のスタンバイ・データベースを本番ロールに切り替えることができるため、障害に関連する停止時間が最短に抑えられます。Oracle Data Guardは、従来のバックアップ、リカバリおよびクラスタ・テクニック、フラッシュバック・データベース機能と併用でき、高水準のデータ保護およびデータ可用性を提供します。

Oracle Data GuardとOracle RAC One Node

Oracle Database 11gリリース2(11.2.0.2)では、Oracle Data GuardとOracle Data Guard BrokerがOracle Real Application Clusters One Node (Oracle RAC One Node)と完全に統合されました。

1.1.1 Oracle Data Guard構成およびブローカ構成

Oracle Data Guard構成は、1つのプライマリ・データベースと、プライマリ・データベースからREDOを直接受信する、スタンバイ・データベースと遠隔同期インスタンスの組合せによって構成されます。Oracle Data Guard構成内のデータベースはOracle Netで接続され、地理的に散在していてもかまいません。相互の通信が可能であれば、データベースの位置に制限はありません。たとえば、スタンバイ・データベースの1つをプライマリ・データベースと同じシステムに置き、別のシステムに2つのスタンバイ・データベースを置くこともできます。

Oracle Data Guard Brokerでは、これらのプライマリ・データベースとスタンバイ・データベースを統合ユニットとしてまとめて管理および監視できるようにブローカ構成として論理的にグループ化されます。ブローカ構成の管理には、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用する方法と、Oracle Data Guardコマンドライン・インタフェースを使用する方法があります。

1.1.2 『Oracle Data Guard Broker』

Oracle Data Guard Brokerは、Oracle Data Guard構成の作成、メンテナンスおよび監視を自動化および集中化する分散管理フレームワークです。次のリストは、ブローカによって自動化および簡素化される操作を示しています。

  • 1つのプライマリ・データベース、新規または既存のスタンバイ(フィジカル、ロジカル、スナップショットおよび遠隔同期)、REDO転送サービスおよびログ適用サービスを含む、Oracle Data Guard構成の作成。スタンバイは、Oracle Real Application Clusters (Oracle RAC)データベースにすることができます。

  • 追加の新規または既存のスタンバイ(フィジカル、ロジカル、スナップショット、遠隔同期、Oracle RACまたは非Oracle RAC)の、既存のOracle Data Guard構成への追加。

  • ブローカ構成の保護モードの管理。

  • 単一のコマンドによるスイッチオーバーまたはフェイルオーバーの起動と、構成内のすべてのデータベースにわたる複雑なロール変更の開始および制御。

  • プライマリ・データベースの消失時に自動的に実行するフェイルオーバーの構成。手動操作なしで可用性が高まります。

  • 構成全体のステータスの監視、診断情報の取得、REDO適用率やREDO生成率などの統計のレポート、および集中化された監視、テストやパフォーマンス・ツールを使用した迅速な問題検出。

  • データベースがプライマリになる準備状況の評価。(「VALIDATE DATABASE」を参照してください)。

ブローカの使いやすいインタフェースである、Cloud Control内のOracle Data Guard管理ページ、およびDGMGRLと呼ばれるOracle Data Guardコマンドライン・インタフェースを使用すると、すべての管理操作をローカルまたはリモートで実行できます。

これらのインタフェースにより、Oracle Data Guard構成の構成および管理が簡素化されます。表1-1に、ブローカのインタフェースを使用する場合とSQL*Plusを使用する場合の構成管理の比較を示します。

表1-1 ブローカがある場合とない場合の構成管理

操作 ブローカがある場合 ブローカがない場合

全般

プライマリ・データベース、スタンバイ・データベースおよび遠隔同期インスタンスの管理を、単一の統一構成として提供します。

プライマリ・データベース、スタンバイ・データベースと遠隔同期インスタンスを別々に管理する必要があります。

スタンバイ・データベースの作成

Cloud Controlのウィザードによって、スタンバイ制御ファイル、オンラインREDOログ・ファイル、データファイルおよびサーバー・パラメータ・ファイルの作成を含む、各サイトでOracleデータベースによる構成を作成するために必要な手順が自動化および簡素化されます。

次の操作を手動で行う必要があります(RMANまたは他のツールを使用して)。

  • データベース・ファイルをスタンバイ・データベース・システムにコピーします。

  • スタンバイ・データベース・システム上で制御ファイルを作成します。

  • スタンバイ・データベース・システム上でサーバー・パラメータ・ファイルまたは初期化パラメータ・ファイルを作成します。

  • プライマリ・データベース・パスワード・ファイルをスタンバイ・データベース・システムにコピーします。

    注意: ブローカを使用している場合でも、すべてのフィジカルおよびスナップショット・スタンバイ・データベースで、プライマリ・データベースからの現行のパスワード・ファイルのコピーを使用していることを確認する必要があります。管理権限(SYSDGSYSOPERSYSDBAなど)が付与または解除された場合、および管理権限を持つユーザーのパスワードが変更された場合は、コピーをリフレッシュする必要があります。

構成と管理

単一の場所から複数データベースの構成と管理を行うことができ、ブローカ構成内のすべてのデータベースが自動的に統一されます。

次の目的のために、複数の場所に手動で接続する必要があります。

  • 構成に含まれる各データベースでREDO転送サービスおよびログ適用サービスを設定します。

  • プライマリ・データベースとスタンバイ・データベースを個別に管理します。

制御

  • REDO転送サービスおよびログ適用サービスが自動的に設定されます。これらのサービスの管理が(特にOracle RAC環境で)簡素化されます。

  • スイッチオーバー、フェイルオーバー、回復、およびスナップショット・スタンバイ・データベースとの変換を単一のコマンドで起動できるため、これらの操作が簡素化されます。

  • ブローカによってフェイルオーバーの必要性を判断し、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーを開始できることにより、フェイルオーバーが自動化されます。DBAによる操作は不要であり、消失データなしでフェイルオーバーする場合と、構成可能なデータ量を消失する場合があります。

  • ロール変更がOracle Clusterwareと統合されます。

  • Cloud Controlによって管理および監視できます。

  • Oracle Global Data Servicesと統合して、ロール固有のグローバル・サービスをサポートします。

次の操作を手動で行う必要があります。

  • 複数のSQL文を使用してデータベースを管理します。

  • 複数データベース・サイト間で複数のコマンドの順序を調整し、スイッチオーバーおよびフェイルオーバー操作を実行します。

  • 複数のコマンドの順序を調整して、ロール遷移中にサービスおよびインスタンスを管理します。

監視

  • 構成の健全性、データベースの健全性および他のランタイム・パラメータが継続的に監視されます。

  • 統一された更新済ステータス・レポートおよび詳細レポートが提供されます。

  • Cloud Controlイベントに統合されます。

次の操作を手動で行う必要があります。

  • 各データベースで固定ビューを使用してステータスおよびランタイム・パラメータを監視します。構成に含まれるすべてのデータベースに関して統一されたステータス・ビューはありません。

  • Cloud Controlイベント監視用に独自の方法を用意します。

1.1.3 Oracle Data Guard BrokerおよびCDB

Oracle Data Guard Brokerは、ブローカ構成内のマルチテナント・コンテナ・データベース(CDB)をサポートします。次のことに注意してください。

  • プライマリ・データベースがCDBの場合、ブローカ構成のすべてのスタンバイ・データベースもCDBである必要があります。

  • ブローカ構成がCDBで構成されている場合、ブローカ・アクションはすべてルート・レベルにあります。個々のプラガブル・データベース(PDB)のレベルではありません。

  • マルチテナント環境を管理するには、CDB_DBAロールを持っている必要があります。

  • ロール変更の後で、ブローカは新しいプライマリのすべてのアクティブ・インスタンスを開きます。スナップショット・スタンバイとロジカル・スタンバイのすべてのアクティブ・インスタンスおよびフィジカル・スタンバイの最初のインスタンス(元のフィジカル・スタンバイが読取り可能の場合)も開かれます。

参照:

  • CDBの詳細は、『Oracle Database概要』を参照してください。

  • CDBとPDBにある権限とロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.1.4 Oracle Data Guard BrokerとOracle Global Data Services

Oracle Global Data Services (GDS)をサポートするブローカ構成を管理するには、ブローカのコマンドライン・インタフェース(DGMGRL)とGDSコマンドライン・インタフェース(GDSCTL)を使用します。ブローカ構成は、GDSプール(複数のGDSリージョンにまたがるGDSデータベースの論理的なグルーピング)に追加されます。

GDSプールでのブローカ構成の管理

GDSプールにブローカ構成を追加するには、GDSコマンドライン・インタフェース(GDSCTL)を使用します。ブローカ構成は、空のプールにのみ追加できます。ブローカ構成は複数のプールにまたがることができません。

プールにあるブローカ構成を削除するには、先にGDSCTL REMOVE BROKERCONFIG ...コマンドを使用してブローカ構成をプールから削除する必要があります。一致しない場合は、エラーが戻ります。

GDSCTLを使用して追加および削除できるのは全体のブローカ構成だけです。ブローカ構成に対して、個々のデータベースを追加および削除するには、ブローカのコマンドライン・インタフェース、DGMGRLを使用します。

個々の構成データベースがGDSプールの一部である場合の管理

GDSプールにすでにブローカ構成が含まれている場合、プールに追加できるのは、その構成に属するデータベースだけです。プール内のブローカ構成に対して個々のデータベースを追加または削除する唯一の方法は、ブローカのコマンドライン・インタフェース、DGMGRLを使用することです。

ブローカ構成に追加されたデータベースは、構成が属するGDSプールにも自動的に追加されます。

ブローカ構成から削除されたデータベースは、構成が属するGDSプールから自動的に削除されます。

ブローカはGDSと相互に作用してロールや構成の変更を通知し、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。

参照:

  • GDSの詳細は、『Oracle Database Global Data Services概要および管理ガイド』を参照してください。

1.2 Oracle Data Guard Brokerの利点

ブローカのインタフェースによって利便性が向上し、Oracle Data Guard構成の管理と監視が集中化されます。ブローカはOracle DatabaseのEnterprise EditionおよびPersonal Editionの機能として選択可能で、OracleデータベースおよびCloud Controlとも統合されます。これらのブローカ属性には次のようなメリットがあります。

障害時の保護:

ブローカを使用すると、Oracle Data Guard構成の構成と監視に必要な手動による作業の多くが自動化され、Oracle Data Guard本来の高可用性、データ保護および障害時保護機能が強化されます。Oracle Data Guard構成内のどのシステムのクライアントからでもアクセスが可能であるため、単一の障害箇所は排除されます。プライマリ・データベースに障害が発生すると、ブローカはプロセスを自動化し、いずれかのスタンバイ・データベースがプライマリ・データベースにかわって本番処理を引き継ぎます。Oracle Data Guardが提供するデータベースの可用性により、データの保護が容易になります。

Oracle Real Application Clusters (Oracle RAC)データベースでの高可用性とスケーラビリティ:

Oracle Data Guard Brokerでは、プライマリ・データベースの一貫したコピーをトランザクションごとに維持することで障害時保護が強化されますが、Oracle Real Application Clusters (RAC)データベースのようなOracleの高可用性ソリューションとともにOracle Data Guardを構成すると、そのデータベースの特定のコピーの可用性およびスケーラビリティがさらに拡張されます。Oracle RACデータベースのサイト内の高可用性により、Oracle Data Guard Brokerが提供するサイト間の保護が補完されます。

クラスタ・システムでプライマリOracle RACデータベースが管理されており、そのデータベースへのアクセスを複数のインスタンスが共有している場合を考えてみます。ここで、計画外の障害が発生したとします。Oracle Data Guard Brokerの観点からは、クラスタ化データベースの1つ以上のインスタンスが引き続きスタンバイ・データベースにREDOデータを転送可能であるかぎり、プライマリ・データベースは使用可能であるとみなされます。Oracle Clusterwareは、Oracle RACデータベースのインスタンスの可用性を管理します。プライマリ・データベースを使用可能な状態に保つために、障害が発生したインスタンスを迅速にリカバリしようとします。障害が発生したインスタンスをOracle Clusterwareがリカバリできない場合、ブローカは自動的に1つ少なくなったインスタンスで引き続き動作します。プライマリ・データベースの最後のインスタンスに障害が発生すると、ブローカは指定されたスタンバイ・データベースにフェイルオーバーする手段を提供します。プライマリ・データベースの最後のインスタンスに障害が発生し、ファスト・スタート・フェイルオーバーが有効化されている場合は、事前決定済のスタンバイ・データベースへのフェイルオーバーが自動的に実行され、継続的な高可用性を提供できます。

ブローカはOracle Clusterwareと統合されているため、データベース・ロールの変更はスムーズかつシームレスに実行されます。このことが特に明らかなのは、計画的なロール・スイッチオーバーの場合です(元のプライマリ・データベースがスタンバイのロールを引き継いでいる間に、フィジカル・スタンバイ・データベースがプライマリ・ロールを引き継ぐように指示される場合など)。ブローカとOracle Clusterwareは連動してプライマリ・データベースでのサービスの可用性を一時的に停止し、Oracle Clusterwareがブローカで動作し元のプライマリ・データベースで必要に応じてインスタンスを正常に再起動する間に、両方のデータベースについて実際のロール変更を行ってから、定義されたサービスを新規プライマリ・データベースで開始します。ブローカは基礎となるOracle Data Guard構成とそのデータベース・ロールを管理しますが、Oracle Clusterwareはロールに依存するサービスの可用性を管理します。サービスの可用性の管理をOracle Clusterwareに依存するアプリケーションでは、Oracle Data Guard構成内でロール変更が発生した場合に、サービスが一時停止していることのみ確認されます。

Oracle Clusterwareによって各Oracle RACデータベース・インスタンスの可用性が維持されることに加え、ブローカは地理的に離れた複数の場所で発生する処理を整理して1つ以上のフィジカルまたはロジカル・データベースのコピーを維持することで、障害時保護を提供します。また、ブローカとOracle Clusterwareは、Oracleの高可用性アーキテクチャに強力な基盤を提供します。

参照:

Oracle Clusterwareの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle RAC One Nodeのサポート:

Oracle Database 11gリリース2(11.2.0.2)では、Oracle Data GuardとOracle Data Guard BrokerがOracle Real Application Clusters One Node (Oracle RAC One Node)と完全に統合されました。このサポートによってOracle RAC構成について説明されたOracle Clusterwareの多数の利点を生かすことができ、ローカル・サイトでより高いレベルの可用性が実現されます。

Oracle Data Guard構成の自動作成。

ブローカにより、Oracle Data Guard構成を論理的に定義および作成できます。Oracle Data Guard構成内のメンバー間での通信は、Oracle Net Servicesを使用して自動的に実行されます。メンバーは、LANで接続されたローカルのメンバーでも、WANを介して接続された地理的に散在するリモートのメンバーでもかまいません。

Cloud Controlには、次のようなブローカ構成の作成に伴う複雑なタスクを自動化するウィザードが付属しています。

  • 既存のスタンバイ・データベースの追加、またはCloud Controlを通じて取得された既存のバックアップからの新規スタンバイ・データベースの作成

  • スタンバイ制御ファイル、サーバー・パラメータ・ファイルおよびデータファイルの構成

  • スタンバイとの通信の初期化

  • スタンバイREDOログ・ファイルの作成

  • ファスト・スタート・フェイルオーバーを使用する場合のフラッシュバック・データベースの有効化

DGMGRLでは新規スタンバイを自動的に作成できませんが、DGMGRLコマンドを使用して、既存のスタンバイ(Cloud Controlを使用して作成されたスタンバイを含む)を構成および監視できます。

追加のスタンバイの構成が容易:

Oracle Data Guard構成を作成した後で、各Oracle Data Guard構成に新規または既存のスタンバイを追加できます。Cloud Controlのスタンバイ・データベースの追加ウィザードを使用すると、指示に従って、さらにデータベースを追加できます。

管理の簡素化、集中化および拡張:

コマンドを発行して、ブローカ構成の多くの側面を管理できます。次のような操作が可能です。

  • プライマリ・データベース、スタンバイ、REDO転送サービスおよびログ適用サービスなど、構成内のすべてのコンポーネントの管理を簡素化できます。

  • データベースの状態遷移を調整し、データベース・プロパティを動的に更新できます。このときブローカは、構成内の全データベースの情報を含むブローカ構成ファイルに変更を記録します。さらに、変更を構成内の全データベースとそのサーバー・パラメータ・ファイルに伝播します。

  • 構成保護モード(最大保護、最大可用性または最大パフォーマンス)の制御を簡素化できます。

  • Cloud Controlの検証操作を起動して、REDO転送サービスとログ適用サービスが正しく構成され、機能していることを確認します。

スイッチオーバー操作とフェイルオーバー操作の簡略化:

ブローカでは、Cloud Controlでキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このマニュアルでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイへのフェイルオーバーの自動開始が可能になり、DBAによる操作は不要です。ファスト・スタート・フェイルオーバーの構成により、消失データなしでフェイルオーバーする場合と、構成可能なデータ量を消失する場合があります。

ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。フェイルオーバーが完了すると、ブローカが高速アプリケーション通知(FAN)イベントを発行して新しいプライマリが使用可能であることをアプリケーションに通知します。

DBMS_DG PL/SQLパッケージを使用すると、特定の条件が満たされたときにアプリケーションによるファスト・スタート・フェイルオーバーの開始が可能になります。詳細は、「アプリケーションによるファスト・スタート・フェイルオーバーの開始」を参照してください。

構成内の全データベースにわたるスイッチオーバー操作またはフェイルオーバー操作に関する複雑なロール変更の開始に必要なコマンドは、1つのみです。ブローカにより、ブローカ構成内の指定スタンバイ・データベースへのスイッチオーバーとフェイルオーバーが自動化されます。Cloud Controlを使用すると、実行可能な(有効化され、実行されているNORMALステータスの)スタンバイ・データベースのセットから、新しいプライマリ・データベースを選択できます。DGMGRLのSWITCHOVERコマンドとFAILOVERコマンドでは、ターゲット・スタンバイ・データベースを指定するだけで、構成内の複数のデータベースにわたるスイッチオーバー操作またはフェイルオーバー操作における多数の手順が自動的に開始および完了します。

組込みの監視、アラートおよび制御メカニズム:

ブローカには、構成内のすべてのデータベースの健全性を監視する組込みの検証機能があります。構成内の任意のデータベースに接続している間、診断情報を取得し、集中化された監視、テストおよびパフォーマンスの各ツールを使用して、明白な問題と潜在的な問題を迅速に検出できます。Cloud ControlとDGMGRLの両方で、プライマリ・データベースにおけるREDO転送サービスの進行状況と、スタンバイ・データベースにおけるREDO ApplyまたはSQL Applyの進行状況の詳細な構成ビューを取得できます。

ブローカの健全性チェック・メカニズムおよびCloud Controlのイベント管理システムとの緊密な統合により、ローカルとリモートのデータベースを監視し、イベントに応答する機能も大幅に強化されています。

アプリケーションに対する透過性:

ブローカはアプリケーションと透過的に動作するため、あらゆるデータベースで使用できます。ブローカで管理する構成にあわせたアプリケーション・コードの変更は不要です。

1.3 Oracle Data Guard Brokerのコンポーネント

Oracle Data Guard Brokerは、次のコンポーネントで構成されています。

Cloud ControlおよびOracle Data Guardコマンドライン・インタフェース(DGMGRL)は、プライマリ・データベースとスタンバイ・データベースの集合からなる構成を定義および管理できるようにするブローカのクライアント・インタフェースです。DGMGRLには、ファスト・スタート・フェイルオーバーを容易にするプロセスである、オブザーバを作成するコマンドも含まれます。「Oracle Data Guard Brokerのユーザー・インタフェース」で、これらのインタフェースについてより詳しく説明します。

Oracle Data Guardモニターはブローカのサーバー側コンポーネントで、Oracleデータベースと統合されています。Oracle Data Guardモニターは、DMONプロセスなどのいくつかのプロセスとブローカ構成ファイルで構成されており、構成のデータベースの制御、実行時の動作の変更、構成全体の健全性の監視、およびその他の操作特性に関する通知の提供などを実行できます。「Oracle Data Guardモニター」で、Oracle Data Guardモニターについてより詳しく説明します。

図1-1に、ブローカのこれらのコンポーネントを示します。

図1-1 Oracle Data Guard Broker

図1-1の説明が続きます。
「図1-1 Oracle Data Guard Broker」の説明

1.4 Oracle Data Guard Brokerのユーザー・インタフェース

ブローカのいずれかのユーザー・インタフェースを使用してブローカ構成を作成し、構成を制御および監視できます。次の各項では、ブローカのユーザー・インタフェースについて説明します。

1.4.1 Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control)は、Oracle Data Guardモニターと連動して、Oracle Data Guard構成の管理を自動化および簡素化します。

Cloud Controlを使用すると、スタンバイ・データベースの作成と管理に関する複雑な操作が、次のようなOracle Data Guard管理ページおよびウィザードによって簡素化されます。

  • スタンバイ・データベースの追加ウィザード。プライマリ・データベースとローカルまたはリモートのスタンバイ・データベースで構成されるブローカ構成が存在しない場合に、このウィザードを使用して新規に作成できます。このウィザードでは、フィジカル、スナップショットまたはロジカル・スタンバイ・データベースを作成したり、既存のフィジカル、スナップショットまたはロジカル(Oracle RACまたは非Oracle RAC)スタンバイ・データベースをインポートできます。フィジカル、スナップショットまたはロジカル・スタンバイ・データベースを作成すると、スタンバイ制御ファイル、サーバー・パラメータ・ファイル、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイルおよびスタンバイ・データファイルも自動的に作成されます。

  • スイッチオーバー操作。プライマリ・データベースとスタンバイ・データベース間でロールを切り替えることができます。

  • フェイルオーバー操作。スタンバイ・データベースの1つがプライマリ・データベースのロールに変更されます。

  • パフォーマンス・ツールとグラフ。REDO転送サービスとログ適用サービスの監視とチューニングに役立ちます。

  • プロパティ・ページ。このページを使用すると、任意のデータベースに対してデータベース・プロパティを設定できます。可能な場合、この設定は、構成内の他のすべてのデータベースおよびサーバー・パラメータ・ファイルにただちに伝播されます。

  • 電子メールを介したイベントのレポート。

さらに、REDO転送サービスおよびログ適用サービスのサポートに必要なOracle Net Servicesのすべての構成変更を行います。

参照:

Oracle Data Guardのすべての機能をOracle Databaseの各リリースで管理するために必要なCloud Controlのバージョンの詳細は、http://support.oracle.comにあるMy Oracle Supportノート787461.1を参照してください

1.4.2 Oracle Data Guardコマンドライン・インタフェース(DGMGRL)

Oracle Data Guard コマンドライン・インタフェース(DGMGRL)では、Oracle Data Guard構成をDGMGRLプロンプトまたはスクリプト内から制御および監視できます。構成内のデータベースの管理と監視に必要なアクティビティのほとんどは、DGMGRLコマンドを使用して実行できます。

DGMGRLには、プライマリ・データベースおよびターゲット・スタンバイ・データベースを継続的に監視し、フェイルオーバーの必要性を評価して、条件を満たしたときにファスト・スタート・フェイルオーバーを開始するオブザーバ・プロセスを作成するコマンドも含まれます。

参照:

Oracle Data Guardコマンドライン・インタフェースの参照情報の詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください。表7-1にDGMGRLコマンドの概要を示します。

1.5 Oracle Data Guardモニター

ブローカの構成、制御および監視機能は、ブローカの管理対象となる各データベースでメンテナンスされるサーバー側ソフトウェアと構成ファイルにより実装されます。このソフトウェアは、Oracle Data Guardモニターと呼ばれます。

以降の各項では、ブローカ構成を管理するための、Oracle Data GuardモニターとOracleデータベースおよびリモートOracle Data Guardモニターの相互作用について説明します。

1.5.1 Oracle Data Guardモニター(DMON)プロセス

Oracle Data Guardモニター(DMON)プロセスは、ブローカの管理対象となる各データベース・インスタンスに対して実行されるOracleバックグラウンド・プロセスです。Oracle Data Guard Brokerを起動すると、DMONプロセスが作成されます。

参照:

ブローカの起動方法は、「Data Guard Brokerの起動」を参照してください

データベースの管理にCloud ControlとDGMGRLのどちらを使用する場合でも、DMONプロセスはサーバー側コンポーネントであり、ローカル・データベースおよび他のデータベースで実行中のDMONプロセスと相互に作用して、要求された機能を実行します。また、DMONプロセスはブローカ構成の健全性を監視し、構成に関する一貫した記述が各データベースに確実に存在するようにします。

図1-2に、Oracleデータベースのインスタンスを構成する複数のバックグラウンド・プロセスの1つであるブローカのDMONプロセスを示します。図中の各データベース・インスタンスには固有のDMONプロセスがあります。

図1-2 データベースとブローカ(DMON)プロセス

図1-2の説明は図の下のリンクをクリックしてください。
「図1-2 データベースとブローカ(DMON)プロセス」の説明

図1-2の中央にあるジグザグの矢印は、同じブローカ構成に含まれる2つのデータベースのDMONプロセス間に存在する双方向のOracle Net Services通信チャネルを表しています。

この双方向通信チャネルは、データベース間での要求のやりとりと、ブローカ構成に含まれるすべてのデータベースの健全性の監視に使用されます。

1.5.2 構成管理

ブローカのDMONプロセスは、ブローカ構成のすべてのメンバーに関する情報をバイナリ構成ファイルに永続的に維持します。このファイルのコピーは、ブローカ構成に属している各データベースに対するDMONプロセスによってメンテナンスされます。Oracle RACデータベースの場合は、このファイルのコピーが各データベースごとにすべてのインスタンスによって共有されます。

この構成ファイルには、構成内でのデータベースの状態とプロパティを記述する情報も含まれます。たとえば、このファイルには、構成内のデータベースと、各データベースのロール、プロパティおよび状態が記録されます。

構成データはDMONプロセスにより透過的に管理され、すべてのデータベース間で構成情報の一貫性が維持されます。ブローカは、構成ファイル内のデータを使用して、データベースの構成と起動、各データベースの動作の制御、およびDGMGRLとCloud Controlへの情報の提供を行います。

参照:

詳細は、「データベース・プロパティの管理」を参照してください

データベースをブローカ構成に追加したり、既存データベースのプロパティを変更すると、各DMONプロセスはその構成ファイルのコピーに新しい情報を記録します。

1.5.3 データベース・プロパティ管理

各データベースには、DMONプロセスがデータベースの動作を制御するための様々なプロパティが関連付けられています。プロパティは、構成ファイルに記録されます。Oracle Data Guard環境に関連するデータベース初期化パラメータの制御には、多数のデータベース・プロパティが使用されます。

ブローカがデータベース自体と構成ファイル内の両方でパラメータの値を確実に更新できるように、サーバー・パラメータ・ファイルを使用して、静的および動的な初期化パラメータを制御する必要があります。サーバー・パラメータ・ファイルを使用すると、ブローカは、データベース管理者(DBA)がブローカの使用時に選択したプロパティ値と、サーバー・パラメータ・ファイルに記録された関連する初期化パラメータ値を調整できます。

ブローカ構成内のデータベース・プロパティに値を設定すると、ブローカはその変更を構成ファイルに記録し、Oracle Data Guard構成内のすべてのデータベースに伝播します。

注意:

ブローカは、デフォルトおよび非デフォルトのサーバー・パラメータ・ファイル名の両方をサポートします。非デフォルトのサーバー・パラメータ・ファイル名を使用する場合は、初期化パラメータ・ファイルでサーバー・パラメータ・ファイルの完全なファイル名と位置を指定する必要があります。Oracle RACデータベースの場合は、すべてのインスタンス用に非デフォルトのサーバー・パラメータ・ファイルが1つ必要です。

参照:

詳細は、「構成可能(変更可能)なプロパティ」を参照してください