| Oracle® Data Guard Broker 12cリリース1 (12.1) B71305-08 |
|
 前 |
 次 |
次のトピックでは、ブローカ構成そのものを管理する方法について説明します。ブローカ構成のコンポーネント管理に関する情報は、「ブローカ構成のメンバーの管理」を参照してください。
Oracle Data Guard Brokerでは、最大253のメンバーからなるブローカ構成を作成して、1つのプライマリ・データベースと、プライマリ・データベースからREDOを直接受信する、スタンバイ・データベースと遠隔同期インスタンスの組合せを含めることができます。ブローカは、構成内のメンバーの制御、構成の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、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概要および管理』を参照してください。
構成プロパティは、ブローカ構成の動作を制御します。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。
構成プロパティは構成全体が有効範囲です。つまり、プロパティに対して設定した値は、構成内の各データベースに均一に適用されます。
参照:
すべてのブローカ構成プロパティの詳細は、「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 Data Guard Brokerは、Oracleにより管理されるデータファイルまたはユーザーが管理するデータファイルのいずれかを使用するデータベースと連動します。これらのデータファイルは、ファイル・システムまたはOracle ASMディスク・グループに格納できます。この項の内容は、次のとおりです。
構成ファイル名は、SQL文ALTER SYSTEMを発行して動的に変更できます。ただし、これらのパラメータはブローカのDMONプロセスの実行中は変更できません。特定のデータベースでこれらの構成ファイルの名前を変更するには、次の手順を実行します。
注意:
リリース11.2以降、このファイルはサポートされている4KB以下のセクター・サイズ(物理ブロック・サイズ)を持つディスク上に格納できます。11.2より前のリリースで生成された構成ファイルは、最初にファイルが作成されたときと同じセクター・サイズを持つディスクにしか格納できないように制限されていました。これらのファイルは異なるセクター・サイズの場所に移動する前に、まずリリース11.2にアップグレードする必要があります。アップグレードしない場合、任意のブローカ構成内で、様々なセクター・サイズの場所に格納される可能性があります。詳細は、「Oracle Database 10gおよびOracle Database 11gからOracle Database 12cリリース1(12.1)へのアップグレード」参照してください。
ブローカがOracle RACデータベースを管理している場合は、各インスタンスのDG_BROKER_CONFIG_FILE1の値とDG_BROKER_CONFIG_FILE2の値が、同じ物理ファイル・セットを指す必要があります。つまり、データベースのインスタンスがすべて同じ構成ファイル・セットを参照する必要があります。構成ファイルは、次のいずれかの方法でデプロイできます。
クラスタ・ファイル・システム(CFS)が使用可能で、構成ファイルがCFSに格納されている場合は、すべてのインスタンスのDG_BROKER_CONFIG_FILEnパラメータに、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
ブローカの構成ファイルは、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ディスク・グループの名前、そのディスク・グループ内の既存のディレクトリおよび構成ファイル自体の名前を含む文字列値に設定します。
構成ファイルの設定後に、各データベースの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が自動的に起動することが保証されます。
ブローカを使用すると、新規構成を作成したり既存の構成を管理できます。図3-4に、ブローカ構成のライフ・サイクルを示します。
ブローカ構成の作成
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のプロパティ」を参照
必要に応じたデータ保護モードの設定
ブローカでは、構成のデータ保護モードを設定できます。保護モードを構成することで、データ保護、可用性またはパフォーマンスを最大化できます。
注意:
データ保護モードの管理の詳細は、「データ保護モードの管理」を参照
構成の監視
ブローカによる管理についての重要な概念は、ブローカ構成におけるデータベースのブローカ管理の有効化および無効化です。有効化と無効化の操作は、ブローカ構成にあるデータベース用に定義されます。ブローカ構成にないデータベース上ではブローカ操作を実行できません。これは、ブローカ構成内のデータベースを有効または無効にすると、実際には、ブローカが指定されたデータベースを管理および監視する機能が有効または無効になるためです。
ただし、ブローカ構成を無効にしても、実際の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
構成のブローカ管理は無効化されており、ブローカは構成内のデータベースのステータスを監視していません。
