ブローカ構成の管理

3 ブローカ構成の管理

構成の管理および監視には、Oracle Data Guard Brokerを使用します。Oracle Enterprise Managerはブローカを使用して、健全性およびその他の操作特性を報告します。

ブローカ構成の概要

Data Guard Brokerでは、相互に排他的な2つの構成がサポートされています。

コンテナ・データベース(DG CDB)用のData Guard

プライマリ・データベース全体を保護します。ロール変更によって、データベース全体がプライマリ・データベースからスタンバイ・データベースに変換されます。スタンバイ・データベースには、プライマリ・データベース内のすべてのプラガブル・データベース(PDB)が含まれます。プライマリ・データベースのREDOストリームを保護するために、1つ以上のフィジカルまたはロジカル・スタンバイ・データベースをデプロイします。
プラガブル・データベース(DG PDB)用のData Guard

プライマリ・データベース内の1つ以上のPDBを保護します。REDOデータの宛先は、ターゲット・データベースと呼ばれる別のプライマリ・データベースです。保護されたPDBで障害が発生した場合、ブローカはターゲット・データベースの対応するPDBにスイッチオーバーまたはフェイルオーバーできます。データベース全体のロールを変更する必要はありません。

構成のサポート

Oracle Data Guard Brokerでは、最大253のメンバーからなるブローカ構成を作成して、1つのプライマリ・データベースと、スタンバイ・データベース、遠隔同期インスタンスおよびZero Data Loss Recovery Applianceの組合せを含めることができます。

ブローカは、構成内のメンバーの制御、構成の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、Oracle Enterprise Manager Cloud Controlを使用している場合はOracle Enterprise Managerの通知メカニズム、DGMGRLを使用している場合はSHOWコマンドが使用されます。

サポートされるOracle Data Guard構成には、次のコンポーネントが含まれています。

プライマリ・データベース(Oracle RACまたは非Oracle RAC)
プライマリ・データベースからREDOを受信するスタンバイ・データベース、遠隔同期インスタンスおよびリカバリ・アプライアンスの組合せ。
データベース間の接続を定義するOracle Net Servicesネットワーク構成
スタンバイ(アーカイブREDOログ・ファイル)の接続先パラメータと構成プロパティ
プライマリ・データベースからスタンバイおよび遠隔同期インスタンスにREDOデータを送信するREDO転送サービス
アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルからREDOデータをスタンバイ・データベースに適用するログ適用サービス

Oracle Data Guardのログ適用サービスでは、スタンバイ・データベースが、REDO転送サービスによりプライマリ・データベースから自動的に転送されるREDOデータで更新されます。アーカイブREDOログ・ファイルとスタンバイREDOログ・ファイルには、リカバリ不能な変更や記録されていない変更を除き、すべてのデータベース変更が含まれています。

フィジカル・スタンバイ・データベースでは、REDO ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。
ロジカル・スタンバイ・データベースでは、SQL ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。
スナップショット・スタンバイ・データベースでは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。
遠隔同期インスタンス上では、REDOデータが受け取られ、フィジカル・スタンバイ・データベースに転送されます。遠隔同期インスタンスはデータ・ファイルを持たず、受け取ったREDOデータを適用しません。

ブローカのOracle Data Guardモニター(DMON)プロセスによって、ブローカ構成はオブジェクトのグループとして構成およびメンテナンスされ、1つの単位として管理および監視できるようになります。したがって、複数のデータベースに影響するコマンドを入力すると、DMONプロセスでは次の操作が実行されます。

プライマリ・データベースに対する要求を実行します。
要求に必要な相手側の各データベースのDMONプロセスと協調しながら動作します。
ローカル・システム上の構成ファイルを更新します。
相手側の各データベースのDMONプロセスと通信して、構成ファイルのコピーを更新します。

DMONプロセスによって、データベースと構成を1単位として構成、監視および制御できるようになります。構成を無効にした場合は、その構成の全データベースのブローカ管理も無効になります。後で構成を有効化すると、その構成の各データベースに対してブローカ管理が有効化されます。

図3-1に、プライマリ・データベースとフィジカル・スタンバイ・データベースからなるブローカ構成を示します。

この図は、プライマリ・データベース上に、プライマリ・データベース、DMON、オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルの主要コンポーネント、およびREDO転送サービスを示しています。また、プライマリ側のスタンバイREDOログ・ファイルは、異なる輪郭線で描かれています。このスタンバイREDOログが異なる輪郭線で描かれているのは、現在有効でないけれども、スタンバイ・ロールへのスイッチオーバーまたはフェイルオーバーのために構成され準備されていることを示すためです。フィジカル・スタンバイ・データベースには、スタンバイ・データベース、ログ適用サービス、DMON、アーカイブREDOログ・ファイル、およびスタンバイREDOログ・ファイルのコンポーネントが含まれています。フィジカル・スタンバイ・データベース上のオンラインREDOログ・ファイルは、現在無効ですが、プライマリ・ロールへのスイッチオーバーまたはフェイルオーバーに備えて構成済であることを示すために輪郭線で描かれています。

関連項目:

スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください

図3-1 Oracle Data Guard Broker構成

「図3-1 Oracle Data Guard Broker構成」の説明

構成全体のサービス名

ブローカは、同じ名前を使用して各構成メンバーにサービスを公開します。この構成全体のサービスのデフォルト名はprimarydbname_CFGで、これは、構成の作成時にプライマリ・データベースのDB_UNIQUE_NAME初期化パラメータの値に接尾辞_CFGが追加されたものです。構成全体のサービス名を変更するには、ConfigurationWideServiceNameプロパティを使用します。ConfigurationWideServiceNameを参照してください。

DG PDBの構成サポート

個々のプラガブル・データベースのData Guardをサポートするには、2つのプライマリ・データベースが必要です。各プライマリ・データベースは独自のブローカ構成を構成するため、データ保護を提供するために2つのブローカ構成が必要です。2つの構成間の通信は、Oracle Netを使用して確立されます。

ブローカでは、一連のDGMGRLコマンドによってDG PDBのサポートが提供されます。

DG PDBの用語

DG PDB構成で使用される用語について学習します。

ソースPDB

保護する必要があるコンテナ・データベース内のプラガブル・データベース(PDB)。Data Guardは、ソースPDBのコピーをターゲット・コンテナ・データベースに保持します。
ソース・データベース

1つ以上のソースPDBを含み、REDOデータのソースであるプライマリ・コンテナ・データベース。
ターゲットPDB

ソースPDBのコピーであるPDB。ソースPDBからのREDOデータがターゲットPDBに適用されます。ソースPDBで障害が発生した場合、ブローカはターゲットPDBにスイッチオーバーまたはフェイルオーバーできます。
ターゲット・データベース

1つ以上のターゲットPDBを含むプライマリ・コンテナ・データベース。保護する必要があるソースPDBをインスタンス化および維持します。
ソース構成

ソース・データベースを含むData Guard Broker構成。
ターゲット構成

ターゲット・データベースを含むData Guard Broker構成。

DG PDB構成のコンポーネント

DG PDB構成には、2つのプライマリ・データベースがそれぞれ独自の構成内に含まれている必要があります。

一方のコンテナ・データベースの1つ以上のソースPDBを、もう一方のコンテナ・データベースでData Guard保護のために設定できます。コンテナ・データベースには、1つ以上のソースPDBまたはターゲットPDB (またはその両方)を含めることができます。REDOは、ソースPDBを含むコンテナ・データベースから、ターゲットPDBを含むコンテナ・データベースに送信されます。コンテナ・データベースにソースPDBとターゲットPDBの両方が含まれている可能性があるため、同時にREDOを送信することも、もう一方のコンテナ・データベースからREDOを受信することもできます。

図3-2に、DG PDB構成のコンポーネントを示します。

図3-2 Oracle DG PDBの構成

「図3-2 Oracle DG PDBの構成」の説明

Broker Configuration 1は、ソース構成PDB salesであり、DG PDBアカウントのターゲット構成です。Broker Configuration 2は、PDB acctのソース構成であり、DG PDBアカウントのターゲット構成です。両方の構成には、ソースDMON、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイルおよびアーカイブREDOログ・ファイルの主要コンポーネントに加えて、REDO転送サービスが表示されます。ソースPDBのpdb_salesは、ターゲット・データベースcdb_newyorkでdgpdb_salesとしてインスタンス化されます。

DG PDB構成のプライマリ・データベースは、REDOデータのソースまたはターゲットのいずれかです。ソースPDBとターゲットPDBが存在する場所に応じて、プライマリCDBはソースCDBとターゲットCDBの両方になります。最大2つのCDBを指定できます。たとえば、上の図のcdb_newyorkには、データベースcdb_bostonのdgpdb_acctに点線を使用して接続されたpdb_acctという名前のPDBが含まれています。これは、ソースPDB pdb_acctにdgpdb_acctとしてインスタンス化されたDG PDBがあることを示しています。ただし、プライマリ・データベースは、1つのREDOストリーム(1つのソース・データベースのみ)のターゲットにしかできません。

Oracle Data Guardモニター(DMON)プロセスによって、ブローカ構成はオブジェクトのグループとして構成およびメンテナンスされ、1つの単位として管理および監視できるようになります。この機能は、DG PDBのブローカ構成で説明されている機能と同じです。

DGPDB_INTユーザー・アカウントについて

DGPDB_INTユーザー・アカウントは、DG PDB構成に関係する他のサイトに接続するときにデータベース・サーバーによって使用されます。通常、これはスタンバイPDBの作成およびスイッチオーバー時に発生します。

最初のDG PDBが追加されると、DGMGRLはDGPDB_INTアカウントのパスワードを求めます。アカウントがリモート・サイトでまだロックされている場合、DGMGRLはロックを解除し、指定されたパスワードを割り当て、必要な権限を付与します。パスワードは、ローカル・サイトのDBMS_CREDENTIALパッケージを使用して安全に記録されます。リモート・サイトの接続識別子とともに、必要に応じて、資格証明およびDGPDB_INTアカウントを使用してリモート・サイトに接続します。

ソースPDBのターゲットPDBを作成する前に、ソースPDBのDGPDB_INTユーザーにSYSDG管理権限を付与する必要があります。DGMGRLは、特定のソースPDBのターゲットPDBの作成の一環としてこの権限を付与します。

DGMGRLはSYSDG管理権限を取り消し、必要に応じてDGPDB_INTアカウントをロックします。

DG PDB構成の制限

DG PDB構成を使用する場合、いくつかの制限が適用されます。

DG PDB構成では、次はサポートされません。

スナップショット・スタンバイ・データベース、遠隔同期インスタンスおよびその他のスタンバイ
最大可用性および最大保護モード
DBMS_ROLLINGパッケージを使用したローリング・アップグレード
1つのソースCDBのターゲットCDBを複数にはできず、1つのターゲットCDBのソースCDBを複数にはできません。
DG PDB構成のサポートを提供する構成の一部としてのOracle GoldenGate
Oracle GoldenGateのダウンストリーム・データ・キャプチャ
Data Guard Brokerの外部宛先
Zero Data Loss Recovery Appliance (ZDLRA)のData Guard Broker機能
ZDLRAへのバックアップ
アプリケーション・コンテナ

Oracle Data Guardでは、個々のPDBのみがサポートされます。
DBMS_ROLLINGパッケージを使用したローリング・アップグレード

ノート:

DG PDB構成を使用するためのワークフロー

ワークフローを使用して、DG PDB構成の設定および管理に必要なタスクを理解します。

DG PDB構成を使用して1つ以上のPDBにデータ保護を提供するには:

保護する必要があるソースPDBを識別します。これらのソースPDBはソース・データベースに含まれています。
ソース・データベースからのREDOデータの宛先であるターゲット・データベースを識別します。
ソース構成とターゲット構成の間の関係を確立します。unresolvable-reference.html#GUID-BF4FFB12-E16A-4096-93BD-28EC58E7A2F4を参照してください。
ターゲット構成にスタンバイREDOログおよびアーカイブREDOログの位置を設定します。「アーカイブREDOログ・ファイルの位置の指定」を参照してください。
ターゲット・データベースでソースPDBをインスタンス化します。unresolvable-reference.html#GUID-9AEE2588-AEB3-4A12-A088-407C5DFA6351を参照してください。
ソース・データベースからターゲット・データベースへのREDO転送を開始し、ターゲット・データベースでリカバリを開始します。unresolvable-reference.html#GUID-B8C509B1-C56C-4623-BF47-E2DDCEBD5BABを参照してください。
必要に応じて、スイッチオーバー操作を実行します。「PDBスイッチオーバーの実行」を参照してください。

または、必要に応じて、ターゲットPDBへのフェイルオーバーを開始します。「PDBフェイルオーバーの実行」を参照してください。
ソース・データベースでのREDO転送およびターゲット・データベースでのリカバリの進行状況を監視します。unresolvable-reference.html#GUID-91802A61-7A08-43CB-B7F3-874A071BC77Fを参照してください。

構成プロパティ

構成プロパティは、ブローカ構成の動作を制御します。

これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。

構成プロパティは構成全体が有効範囲です。つまり、プロパティに対して設定した値は、構成内の各データベースに均一に適用されます。

ノート:

Oracle Databaseリリース19c以降では、データベース初期化パラメータに関連するプロパティ(log_archive_dest_nおよびlog_archive_dest_state_nを除く)は、ブローカ構成ファイルに格納されなくなりました。

関連項目:

すべてのブローカ構成プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

ブローカ構成ファイルの設定

ブローカを初めて起動すると、オペレーティング・システム固有のデフォルト・パス名とファイル名を使用して、構成ファイルが自動的に作成されます。

構成ファイルのコピーはデータベースごとに2つずつメンテナンスされるため、最後に認識された有効な構成の状態が常に記録されています。デフォルト・パス名とファイル名を上書きするには、そのデータベースで次の初期化パラメータを設定します。

DG_BROKER_CONFIG_FILE1
DG_BROKER_CONFIG_FILE2

DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2初期化パラメータを設定する場合、次の制限事項に注意してください。

これらのパラメータは、Oracle Data Guard Brokerが実行中でない場合のみ設定または変更できます(DG_BROKER_START=FALSE)。
Oracle RACデータベースの場合、これらのパラメータでは、Oracle ASM、Oracle OCFSまたはNFSの場所として、すべてのOracle RACインスタンスで共有される同一の場所を指定する必要があります。
PL/SQLパッケージDBMS_ROLLINGを使用してアップグレードが実行されている場合は、DG_BROKER_CONFIG_FILEnパラメータで、Oracleホームの外部の場所を指定する必要があります。(デフォルトの場所はOracleホーム内のdbsディレクトリです。)

Oracle Data Guard Brokerは、Oracleにより管理されるデータファイルまたはユーザーが管理するデータファイルのいずれかを使用するデータベースと連動します。これらのデータファイルは、ファイル・システムまたはOracle ASMディスク・グループに格納できます。この項の内容は、次のとおりです。

ブローカ構成ファイルの名前の変更

ブローカ構成ファイルの名前は、SQL文ALTER SYSTEMを発行して変更できます。

ただし、これらのパラメータはブローカのDMONプロセスの実行中は変更できません。特定のデータベースで構成ファイルの名前を変更するには、次のステップを実行します。

DGMGRL DISABLEコマンドを使用してブローカ構成を無効化します。「操作の有効化と無効化」を参照してください。
次のSQL文を使用して、Oracle Data Guard BrokerのDMONプロセスを停止します。
```
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
```
データベースの構成ファイル名を次のように変更します。
```
SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1=filespec1;
SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2=filespec2;
```
ノート:

ブローカがOracle RACデータベースを管理している場合は、各インスタンスのDG_BROKER_CONFIG_FILE1の値とDG_BROKER_CONFIG_FILE2の値が、同じ物理ファイル・セットを指す必要があります。
ファイルを移動する方法は、現在ファイルが格納されている場所およびファイルの移動先によって異なります。
- ファイルがオペレーティング・システムのファイル・システムに格納されている場合は、オペレーティング・システムのコマンドを使用してファイルを新しい場所に移動します。
- 元の場所または新しい場所がOracle ASMディスク・グループである場合は、DBMS_FILE_TRANSFER.COPY_FILE関数を使用して、新しい場所にファイルを転送します。
次のようにOracle Data Guard BrokerのDMONプロセスを再起動します。
```
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
```
DGMGRLのENABLEコマンドまたはCloud ControlのOracle Data Guard管理ページの「有効化」操作を使用して、ブローカ構成を有効化します。

Oracle RAC環境でのブローカ構成ファイルの管理

Oracle RAC環境では、データベースのインスタンスがすべて同じ構成ファイル・セットを参照する必要があります。

つまり、ブローカがOracle RACデータベースを管理している場合は、各インスタンスの DG_BROKER_CONFIG_FILE1の値とDG_BROKER_CONFIG_FILE2の値が、同じ物理ファイル・セットを指す必要があります。構成ファイルは、次のいずれかの方法でデプロイできます。

構成ファイルに対するクラスタ・ファイル・システム(CFS)の使用

ブローカ構成ファイルはクラスタ・ファイル・システム(CFS)に格納できます。

その場合は、すべてのインスタンスに対するDG_BROKER_CONFIG_FILEnパラメータを、CFS領域へのパスを含むこれらのファイルに設定する必要があります。図3-3に、CFS上のブローカ構成ファイルの設定を示します。この使用例では、すべてのインスタンスのパラメータと値は次のとおりです。

DG_BROKER_CONFIG_FILE1=$ORACLE_BASE/admin/db_unique_name/dr1db_unique_name.dat
DG_BROKER_CONFIG_FILE2=$ORACLE_BASE/admin/db_unique_name/dr2db_unique_name.dat

図3-3 CFS領域でのブローカ構成の設定

「図3-3 CFS領域でのブローカ構成の設定」の説明

構成ファイルに対するOracle ASMディスク・グループの使用

ブローカの構成ファイルは、Oracle ASMディスク・グループにも格納できます。

次のいずれかの方法を使用して、ブローカ構成ファイルの場所を設定します。

構成ファイル名と完全パスの指定

DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2初期化パラメータを、既存のOracle ASMディスク・グループの名前、そのディスク・グループ内の既存ディレクトリ、および構成ファイル自体の名前を含む文字列値に設定します。
ディスク・グループ名のみの指定

DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2初期化パラメータをASMディスク・グループの名前に設定します。ディスク・グループ名は、ブローカによって、事前定義済のパスおよびファイル名に自動的に変換されます。構成ファイルは次のとおりです。
```
DG_BROKER_CONFIG_FILE1 = '+DG/db_unique_name/DATAGUARDCONFIG/dr1db_unique_name.dat'
DG_BROKER_CONFIG_FILE2 = '+DG/db_unique_name/DATAGUARDCONFIG/dr2db_unique_name.dat'
```

図3-4に、Oracle ASMデバイス上のブローカ構成ファイルの設定を示します。この使用例では、パラメータと値は次のように指定されます。

ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1 = '+DG/North_Sales/dr1.dat' SCOPE=BOTH;
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2 = '+DG/North_Sales/dr2.dat' SCOPE=BOTH;

図3-4 Oracle ASMでのブローカ構成の設定

「図 3-4 Oracle ASMでのブローカ構成の設定」の説明

Data Guard Brokerの起動

構成ファイルの設定後に、各データベースのDG_BROKER_START初期化パラメータをTRUEに設定し、DMONプロセスを起動する必要があります。

デフォルトでは、DG_BROKER_START初期化パラメータはFALSEに設定されています。ただし、値は次の方法で設定できます。

Cloud Controlを使用している場合、新規に作成されるスタンバイ・データベースのDG_BROKER_START初期化パラメータは自動的にTRUEに設定されます。
DGMGRLを使用している場合、明示的にDG_BROKER_START初期化パラメータをTRUEに設定する必要があります。TRUEに設定しないと、ブローカは起動しません。次のSQL文を使用すると、DG_BROKER_START初期化パラメータを設定できます。
```
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

System altered.

SQL> SHOW PARAMETER DG_BROKER_START

NAME               TYPE      VALUE
------------------------------------  
dg_broker_start    boolean   TRUE
```

Cloud ControlとDGMGRLのどちらを使用している場合も、各データベースおよび遠隔同期インスタンスで、DG_BROKER_START初期化パラメータの値をTRUEに設定します。これにより、いずれかのデータベース・インスタンスの次回起動時にOracle Data Guard Brokerが自動的に起動することが保証されます。

ノート:

初期化パラメータDG_BROKER_START=TRUEの場合は、プライマリ・データベースが有効になっていて、どのインスタンスでもデータベースがオープンされていないと、アーカイブ・ログ・モードが自動的に有効になります。

ブローカ構成の管理サイクル

この図はブローカ構成のライフ・サイクルを示し、その付随するテキストではサイクルの各フェーズについて説明します。

図3-5 ブローカ構成とそのデータベースのライフ・サイクル

「図3-5 ブローカ構成とそのデータベースのライフ・サイクル」の説明

ノート:

DG PDB構成では、状態や保護モードを変更できません。

ブローカ構成の作成

Cloud Controlを使用している場合は、スタンバイ・データベースの追加ウィザードを使用して、既存の単一インスタンスまたはOracle RACスタンバイ・データベースを構成に追加するか、新しい単一インスタンスまたはOracle RACスタンバイ・データベースを作成して構成に追加できます。スタンバイ・データベースは、フィジカル、ロジカルまたはスナップショットのどれでもかまいません。

DGMGRLを使用する場合は、プライマリ・データベースとスタンバイ・データベースがすでに存在している必要があります。スタンバイ・データベースは、プライマリ・データベースの制御ファイルとデータファイルのバックアップから作成し、リカバリ用に準備します。

ブローカ構成の有効化

Oracle Data Guard構成は、ブローカで管理または監視するために有効化する必要があります。逆に、ブローカで管理する必要がなくなった場合には、構成を無効化します。構成を無効化すると、そのすべてのデータベースに関するブローカ管理も無効化されます。

ノート:

DGMGRLを使用すると構成を有効化または無効化できます。Cloud Controlを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Cloud Controlを使用して有効化できます。

ブローカ構成は、初めてCloud Controlを使用して作成されると、スタンバイ・データベースの追加ウィザードの完了後すぐに自動的に有効化されます。

ブローカ構成は、最初にDGMGRLを使用して作成された時点では無効な状態になっています。つまり、その構成要素であるデータベースは、まだブローカの制御下にありません。DGMGRLを使用してデータベースをブローカ構成に組み込んだ後は、ブローカで管理できるように構成を有効化する必要があります。

次のいずれかを有効化できます。

すべてのデータベースを含む構成全体
個々のスタンバイ・データベース

問題が発生して、ブローカ構成内のデータベースが正常に機能しない場合は、データベースを簡単に無効化できます。プライマリ・データベースは無効化できないことに注意してください。プライマリ・データベースを無効化するには、構成全体を無効にする必要があります。

さらに、構成を一時的に無効化し、実際のデータベース・プロパティに影響を与えずに、ブローカ構成内の一部のプロパティを変更することもできます。変更されたプロパティが有効になるのは、ブローカによる管理のために構成が再度有効化された場合です。

必要に応じたブローカ構成内のロール変更

単一のコマンドを発行することで、構成内のデータベースのロールをいつでも変更できます。なんらかのイベントによってプライマリ・データベースが使用不能になった場合は、スタンバイ・データベースの1つが新しいプライマリ・データベースになるようにフェイルオーバーできます。

以前のプライマリ・データベース上でフラッシュバック・データベースが有効な場合、フェイルオーバーの完了後、元のプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとして回復できます。これにより、新しいプライマリ・データベースのコピーから古いプライマリ・データベースを再作成する必要がなくなります。

また、メンテナンスのために予定されている停止時間を短縮できます。これは、本番処理を現行のプライマリ・データベースからスタンバイ・データベースにすばやく切り替えて、予定されたメンテナンスの完了後に逆の切替えをすばやく実行できるためです。

関連項目:

ロール変更の詳細は、スイッチオーバー操作とフェイルオーバー操作を参照してください

スナップショット・スタンバイ・データベースへの変換

いつでも、コマンドを発行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できます。スナップショット・スタンバイ・データベースは完全に更新可能なデータベースで、プライマリ・データベースから生成されたREDOデータを受信しますが、適用しません。

スナップショット・スタンバイ・データベースを使用して処理を終了後、再びコマンドを発行してフィジカル・スタンバイ・データベースに変換できます。フィジカル・スタンバイ・データベースへの変換の完了後、REDO Applyサービス(状態がAPPLY-ONであれば)が開始され、すべての累積REDOデータが適用されます。スナップショット・スタンバイに加えられた変更は保持されません。

必要に応じたデータベースの状態変更

構成を初めて有効化すると、デフォルトで、プライマリのREDO転送サービスおよびスタンバイ(スナップショット・スタンバイを除く)のログ適用サービスが開始します。

どの時点でも、Cloud ControlまたはDGMGRLを介して単一のコマンドを発行して、データベースの状態を変更できます。たとえば、プライマリ・データベースをTRANSPORT-OFF状態にして、スタンバイ・データベースへのREDOデータの送信を一時的に停止できます。続いて、プライマリ・データベースをTRANSPORT-ON状態にして、REDOデータのスタンバイへの送信を再開できます。

関連項目:

データベースの状態の変更は、ブローカ構成のメンバーの管理を参照してください

必要に応じたデータベース・プロパティの更新

ブローカを使用すると、データベース・プロパティを設定できます。一部のプロパティは、データベース初期化パラメータに対応しています。これらのプロパティを変更すると、REDO転送、スタンバイ・ファイル管理、ログ適用などを動的に制御し、全体的な構成保護モードをサポートできます。ブローカは、Oracle Data Guard構成で各データベースのブローカ構成ファイルに変更を記録し、必要に応じて、サーバーのパラメータ・ファイルの関連初期化パラメータにその変更を伝播します。

関連項目:

データベース・プロパティの詳細は、ブローカ構成のメンバーの管理およびOracle Data Guard Brokerのプロパティを参照してください

必要に応じたデータ保護モードの設定

ブローカでは、構成のデータ保護モードを設定できます。保護モードを構成することで、データ保護、可用性またはパフォーマンスを最大化できます。

関連項目:

データ保護モードの管理の詳細は、「データ保護モードの管理」を参照

構成の監視

構成の健全性をチェックし、データベースのプロパティを表示および更新し、Cloud Controlイベントを設定できます。

Cloud Controlには、指定の間隔でグラフ・データやステータスを自動的および動的にリフレッシュする動的パフォーマンス・ページも用意されています。パフォーマンス・グラフには、生成および適用されているREDOデータの遅れと量のサマリーがグラフ形式で示されます。

操作の有効化と無効化

ブローカ構成内のデータベースを有効または無効にすると、実際には、ブローカが指定されたデータベースを管理および監視する機能が有効または無効になります。

有効化と無効化の操作は、ブローカ構成にあるデータベース専用に定義されます。ブローカ構成にないデータベース上ではブローカ操作を実行できません。

ただし、ブローカ構成を無効にしても、実際のOracle Data Guard構成内の現行のサービスと操作は影響を受けません。たとえば、ブローカ構成を無効にすると、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは引き続き機能しますが、ブローカ・インタフェース経由では管理できなくなります。

また、データベースを無効にしても、それがブローカ構成ファイルから削除されることはありません。無効化されたデータベースのプロパティを変更した後、DGMGRLのENABLE CONFIGURATIONまたはENABLE DATABASEコマンド、あるいはCloud ControlのOracle Data Guard管理ページの「有効化」オプションを使用して、ブローカによる管理機能を再び有効化できます。

ノート:

ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。

ブローカによる構成管理を無効化すると、ブローカのデータベース監視および制御機能を削除する場合にも役立ちます。たとえば、構成を一時的に無効化し、ブローカ構成内の1つ以上のプロパティをすべて同時に変更すると便利な場合があります。無効化された構成でプロパティを変更した場合、その変更は構成を再び有効化するまで実行中のデータベースには適用されないため、制御対象となる実際のデータベース・プロパティに影響を与えることはありません。たとえば、無効化された構成で、構成の保護モード全体とREDO転送サービスのプロパティを変更し、次の有効化操作時にすべての変更を同時に構成へ適用できます。

関連項目:

保護モードによるブローカ操作への影響

構成ステータス

構成ステータスは、構成全体の健全性を示します。

この情報は、そのすべてのデータベースのステータスから取得されます。

構成に可能なステータス・モードは、次のとおりです。

成功

構成は、内部で構成されているすべてのデータベースも含めて、エラーや警告なしでユーザーの指定どおりに動作しています。
警告

構成内の1つ以上のデータベースで、ユーザーの指定どおりに操作が行われていません。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name>コマンドまたはCloud Control画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。
エラー

構成内の1つ以上のデータベースで障害が発生したか、またはユーザーの指定どおりに操作が行われない可能性があります。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name>コマンドまたはCloud Control画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。
UNKNOWN/DISABLED

構成のブローカ管理は無効化されており、ブローカは構成内のデータベースのステータスを監視していません。
ROLLING DATABASE MAINTENANCE IN PROGRESS

PL/SQLパッケージDBMS_ROLLINGを使用して実行された操作が進行中です。