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 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 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つのプライマリ・データベース、スタンバイ(フィジカル、ロジカル、スナップショットおよび遠隔同期)、Zero Data Loss Recovery Appliance、REDO転送サービスおよびログ適用サービスを含む、Oracle Data Guard構成の作成。データベースは、Oracle Real Application Clusters (Oracle RAC)データベースにすることができます。
-
スタンバイ(フィジカル、ロジカル、スナップショット、遠隔同期、Oracle RACまたは非Oracle RAC)およびZero Data Loss Recovery Applianceの、既存のOracle Data Guard構成への追加。
-
構成の保護モードの管理。
-
単一のコマンドによるスイッチオーバーまたはフェイルオーバーの起動と、構成内のすべてのデータベースにわたる複雑なロール変更の開始および制御。
-
プライマリ・データベースの消失時に自動的に実行するフェイルオーバーの構成。手動操作なしで可用性が高まります。
-
構成全体のステータスの監視、診断情報の取得、REDO適用率やREDO生成率などの統計のレポート、および集中化された監視、テストやパフォーマンス・ツールを使用した迅速な問題検出。
-
データベースがプライマリになる準備状況の評価。(VALIDATE DATABASEを参照してください)。
-
ネットワークが正しくデータベース間で構成されているかどうかの評価。(「VALIDATE NETWORK CONFIGURATION」を参照してください。)
ブローカの使いやすいインタフェースである、Cloud Control内のOracle Data Guard管理ページ、およびDGMGRLと呼ばれるOracle Data Guardコマンドライン・インタフェースを使用すると、すべての管理操作をローカルまたはリモートで実行できます。
これらのインタフェースにより、Oracle Data Guard構成の構成および管理が簡素化されます。次の表に、ブローカのインタフェースを使用する場合とSQL*Plusを使用する場合の構成管理の比較を示します。
表1-1 ブローカがある場合とない場合の構成管理
1.1.3 Oracle Data Guard BrokerおよびCDB
Oracle Data Guard Brokerは、ブローカ構成内のマルチテナント・コンテナ・データベース(CDB)をサポートします。
-
プライマリ・データベースがCDBの場合、ブローカ構成のすべてのスタンバイ・データベースもCDBである必要があります。
-
ブローカ構成がCDBで構成されている場合、ブローカ・アクションはすべてルート・レベルにあります。個々のプラガブル・データベース(PDB)のレベルではありません。
-
マルチテナント環境を管理するには、
CDB_DBA
ロールを持っている必要があります。 -
ロール変更の後で、ブローカは新しいプライマリのすべてのアクティブ・インスタンスを開きます。スナップショット・スタンバイとロジカル・スタンバイのすべてのアクティブ・インスタンスおよびフィジカル・スタンバイの最初のインスタンス(元のフィジカル・スタンバイが読取り可能の場合)も開かれます。
-
ブローカは、オープンするすべてのインスタンス上のPDBもすべてオープンします。
関連項目:
-
CDBの詳細は、『Oracle Database概要』を参照してください。
1.1.4 Oracle Data Guard BrokerとOracle Global Data Services
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のスタンバイ・データベースの追加ウィザードを使用すると、指示に従って、さらにデータベースを追加できます。
管理の簡素化、集中化および拡張:
コマンドを発行して、ブローカ構成の多くの側面を管理できます。次のような操作が可能です。
-
プライマリ・データベース、スタンバイ、Zero Data Loss Recovery Appliance、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モニターはブローカのサーバー側コンポーネントで、Oracleデータベースと統合されています。Oracle Data Guardモニターは、DMONプロセスなどのいくつかのプロセスとブローカ構成ファイルで構成されており、構成のデータベースの制御、実行時の動作の変更、構成全体の健全性の監視、およびその他の操作特性に関する通知の提供などを実行できます。
図1-1に、ブローカのこれらのコンポーネントを示します。
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ログ・ファイルおよびスタンバイ・データファイルも自動的に作成されます。
-
プロパティ・ページ。このページを使用すると、任意のデータベースに対してデータベース・プロパティを設定できます。可能な場合、この設定は、構成内の他のすべてのデータベースおよびサーバー・パラメータ・ファイルにただちに伝播されます。
さらに、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コマンドライン・インタフェース・リファレンス」を参照してください。
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の中央にあるジグザグの矢印は、同じブローカ構成に含まれる2つのデータベースのDMONプロセス間に存在する双方向のOracle Net Services通信チャネルを表しています。
この双方向通信チャネルは、データベース間での要求のやりとりと、ブローカ構成に含まれるすべてのデータベースの健全性の監視に使用されます。
Data Guard Brokerプロセスの監視
V$DATAGUARD_PROCESS
ビューを使用してブローカ・プロセスおよび他のData Guardプロセスのステータスを監視します。このビューには、ブローカDMONプロセスの詳細が表示されている行が含まれています。次に、DMONプロセスに表示される列および値を示します(ビューの他の列は、通常、ブローカに関連していません)。
-
NAME
— DMON -
ROLE
— ブローカ・モニター -
PID
— プロセスのオペレーティング・システムのプロセス識別子 -
PROC_TIME
— ビューへのプロセスの組込みの開始時または登録時のタイムスタンプ
関連項目:
-
V$DATAGUARD_PROCESS
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
1.5.2 構成管理
ブローカのDMONプロセスは、ブローカ構成のすべてのメンバーに関する情報をバイナリ構成ファイルに永続的に維持します。
構成ファイルのコピーは、ブローカ構成に属している各データベースに対するDMONプロセスによってメンテナンスされます。Oracle RACデータベースの場合は、このファイルのコピーが各データベースごとにすべてのインスタンスによって共有されます。
この構成ファイルには、構成内でのデータベースの状態とプロパティを記述する情報も含まれます。たとえば、このファイルには、構成内のデータベースと、各データベースのロール、プロパティおよび状態が記録されます。
構成データはDMONプロセスにより透過的に管理され、すべてのデータベース間で構成情報の一貫性が維持されます。ブローカは、構成ファイル内のデータを使用して、データベースの構成と起動、各データベースの動作の制御、およびDGMGRLとCloud Controlへの情報の提供を行います。
関連項目:
詳細は、「データベース・プロパティの管理」を参照してください
データベースをブローカ構成に追加したり、既存データベースのプロパティを変更すると、各DMONプロセスはその構成ファイルのコピーに新しい情報を記録します。
1.5.3 データベース・プロパティ管理
ブローカでは、各データベースに関連付けられている様々なプロパティを使用して、データベースの動作を制御します。
プロパティは、構成ファイルに記録されます。Oracle Data Guard環境に関連するデータベース初期化パラメータの制御には、多数のデータベース・プロパティが使用されます。
ブローカがデータベース自体と構成ファイル内の両方でパラメータの値を確実に更新できるように、サーバー・パラメータ・ファイルを使用して、静的および動的な初期化パラメータを制御する必要があります。サーバー・パラメータ・ファイルを使用すると、ブローカは、データベース管理者(DBA)がブローカの使用時に選択したプロパティ値と、サーバー・パラメータ・ファイルに記録された関連する初期化パラメータ値を調整できます。
ブローカ構成内のデータベース・プロパティに値を設定すると、ブローカはその変更を構成ファイルに記録し、Oracle Data Guard構成内のすべてのデータベースに伝播します。
注意:
ブローカは、デフォルトおよび非デフォルトのサーバー・パラメータ・ファイル名の両方をサポートします。非デフォルトのサーバー・パラメータ・ファイル名を使用する場合は、初期化パラメータ・ファイルでサーバー・パラメータ・ファイルの完全なファイル名と位置を指定する必要があります。Oracle RACデータベースの場合は、すべてのインスタンス用に非デフォルトのサーバー・パラメータ・ファイルが1つ必要です。
関連項目:
詳細は、「構成可能(変更可能)なプロパティ」を参照してください