3 ブローカ構成の管理
構成の管理および監視には、Oracle Data Guard Brokerを使用します。ブローカは、Oracle Enterprise Managerを使用して、健全性および他の操作上の特性を報告します。
3.1 構成のサポート
Oracle Data Guard Brokerでは、最大253のメンバーからなるブローカ構成を作成して、1つのプライマリ・データベースと、スタンバイ・データベース、遠隔同期インスタンスおよびZero Data Loss Recovery Applianceの組合せを含めることができます。
ブローカは、構成内のメンバーの制御、構成の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、Oracle Enterprise Manager Cloud Controlを使用している場合はOracle Enterprise Managerの通知メカニズム、DGMGRLを使用している場合はSHOW
コマンドが使用されます。
サポートされるOracle Data Guard構成には、次のコンポーネントが含まれています。
-
スタンバイ・データベース、遠隔同期インスタンス、およびプライマリ・データベースから直接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概要および管理』を参照してください。
構成全体のサービス名
ブローカは、同じ名前を使用して各構成メンバーにサービスを公開します。この構成全体のサービスのデフォルト名はprimarydbname_CFG
で、これは、構成の作成時にプライマリ・データベースのDB_UNIQUE_NAME
初期化パラメータの値に接尾辞_CFG
が追加されたものです。構成全体のサービス名を変更するには、ConfigurationWideServiceName
プロパティを使用します。ConfigurationWideServiceNameを参照してください。
3.2 構成プロパティ
構成プロパティは、ブローカ構成の動作を制御します。
これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。
構成プロパティは構成全体が有効範囲です。つまり、プロパティに対して設定した値は、構成内の各データベースに均一に適用されます。
関連項目:
すべてのブローカ構成プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照
3.3 ブローカ構成ファイルの設定
ブローカを初めて起動すると、オペレーティング・システム固有のデフォルト・パス名とファイル名を使用して、構成ファイルが自動的に作成されます。
構成ファイルのコピーはデータベースごとに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を指定する必要があります。
-
アップグレードがPL/SQLパッケージ
DBMS_ROLLING
を使用して実行されている場合、DG_BROKER_CONFIG_FILEn
パラメータでOracleホームの外部の場所を指定する必要があります。(デフォルトの場所はOracleホームのdbs
ディレクトリです。)
Oracle Data Guard Brokerは、Oracleにより管理されるデータファイルまたはユーザーが管理するデータファイルのいずれかを使用するデータベースと連動します。これらのデータファイルは、ファイル・システムまたはOracle ASMディスク・グループに格納できます。この項の内容は、次のとおりです。
3.3.1 ブローカ構成ファイルの名前の変更
ブローカ構成ファイルの名前は、SQL文ALTER SYSTEM
を発行して変更できます。
ただし、これらのパラメータはブローカのDMONプロセスの実行中は変更できません。特定のデータベースで構成ファイルの名前を変更するには、次の手順を実行します。
注意:
リリース11.2以降、このファイルはサポートされている4KB以下のセクター・サイズ(物理ブロック・サイズ)を持つディスク上に格納できます。11.2より前のリリースで生成された構成ファイルは、最初にファイルが作成されたときと同じセクター・サイズを持つディスクにしか格納できないように制限されていました。これらのファイルは異なるセクター・サイズの場所に移動する前に、まずリリース11.2にアップグレードする必要があります。アップグレードしない場合、任意のブローカ構成内で、様々なセクター・サイズの場所に格納される可能性があります。詳細は、「Oracle Database 10gおよびOracle Database 11gからOracle Database 12cへのアップグレード」参照してください。
3.3.2 Oracle RAC環境でのブローカ構成ファイルの管理
Oracle RAC環境では、データベースのインスタンスがすべて同じ構成ファイル・セットを参照する必要があります。
つまり、ブローカがOracle RACデータベースを管理している場合は、各インスタンスのDG_BROKER_CONFIG_FILE1
の値とDG_BROKER_CONFIG_FILE2
の値が、同じ物理ファイル・セットを指す必要があります。構成ファイルは、次のいずれかの方法でデプロイできます。
3.3.2.1 構成ファイルに対するクラスタ・ファイル・システム(CFS)の使用
ブローカ構成ファイルはクラスタ・ファイル・システム(CFS)に格納できます。
その場合は、すべてのインスタンスのDG_BROKER_CONFIG_FILE
nパラメータに、CFS領域へのパスを含むファイル名を設定します。図3-2に、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.2.2 構成ファイルに対するOracle ASMディスク・グループの使用
ブローカの構成ファイルは、Oracle ASMディスク・グループにも格納できます。
図3-3に、Oracle ASMデバイス上のブローカ構成ファイルの設定を示します。この使用例では、パラメータと値は次のように指定されます。
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1 = '+DG/DIRECTORY/DR1.DAT' SCOPE=BOTH; ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2 = '+DG/DIRECTORY/DR2.DAT' SCOPE=BOTH;
構成ファイルにはユーザーが明示的に名前を付ける必要があるため、これらの構成ファイルはOracle Managed Files(OMF)ではありません。ブローカの構成ファイルをOracle ASMディスク・グループ上に作成するには、初期化パラメータDG_BROKER_CONFIG_FILE1
およびDG_BROKER_CONFIG_FILE2
を、既存のOracle ASMディスク・グループの名前、そのディスク・グループ内の既存のディレクトリおよび構成ファイル自体の名前を含む文字列値に設定します。
3.4 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
を指定し、SQL STARTUP MOUNT
またはALTER DATABASE MOUNT
文をプライマリ・データベースに対して実行している場合、アーカイブ・ログ・モードは自動的にデータベース・レベルで有効になっています。
3.5 ブローカ構成の管理サイクル
この図はブローカ構成のライフ・サイクルを示し、その付随するテキストではサイクルの各フェーズについて説明します。
ブローカ構成の作成
Cloud Controlを使用している場合は、スタンバイ・データベースの追加ウィザードを使用して、既存のスタンバイ・データベース(Oracle RACまたは非Oracle RAC)を構成に追加するか、新規のスタンバイ・データベース(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データの遅れと量のサマリーがグラフ形式で示されます。
3.6 操作の有効化と無効化
ブローカ構成内のデータベースを有効または無効にすると、実際には、ブローカが指定されたデータベースを管理および監視する機能が有効または無効になります。
有効化と無効化の操作は、ブローカ構成にあるデータベース専用に定義されます。ブローカ構成にないデータベース上ではブローカ操作を実行できません。
ただし、ブローカ構成を無効にしても、実際のOracle Data Guard構成内の現行のサービスと操作は影響を受けません。たとえば、ブローカ構成を無効にすると、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは引き続き機能しますが、ブローカ・インタフェース経由では管理できなくなります。
また、データベースを無効にしても、それがブローカ構成ファイルから削除されることはありません。無効化されたデータベースのプロパティを変更した後、DGMGRLのENABLE CONFIGURATION
またはENABLE DATABASE
コマンド、あるいはCloud ControlのOracle Data Guard管理ページの「有効化」オプションを使用して、ブローカによる管理機能を再び有効化できます。
注意:
ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。
ブローカによる構成管理を無効化すると、ブローカのデータベース監視および制御機能を削除する場合にも役立ちます。たとえば、構成を一時的に無効化し、ブローカ構成内の1つ以上のプロパティをすべて同時に変更すると便利な場合があります。無効化された構成でプロパティを変更した場合、その変更は構成を再び有効化するまで実行中のデータベースには適用されないため、制御対象となる実際のデータベース・プロパティに影響を与えることはありません。たとえば、無効化された構成で、構成の保護モード全体とREDO転送サービスのプロパティを変更し、次の有効化操作時にすべての変更を同時に構成へ適用できます。
関連項目:
3.7 構成ステータス
構成ステータスは、構成全体の健全性を示します。
この情報は、そのすべてのデータベースのステータスから取得されます。
構成に可能なステータス・モードは、次のとおりです。
-
構成は、内部で構成されているすべてのデータベースも含めて、エラーや警告なしでユーザーの指定どおりに動作しています。
-
構成内の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
を使用して実行された操作が進行中です。