| Oracle Data Guard Broker 11gリリース1（11.1） E05756-02 |
|
 戻る |
 次へ |
ブローカを使用すると、プライマリ・データベースと1つ以上のスタンバイ・データベースで構成されるData Guard構成を論理的に定義できます。ブローカを使用して、ブローカ構成を定義します。ブローカ構成とは、REDO転送サービスとログ適用サービスも含めてデータベースを論理的にグループ化したものです。ブローカはDBAの裁量に従って、構成内の論理オブジェクトの制御、実行時のオブジェクト動作の変更、構成全体の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、Oracle Enterprise Managerを使用している場合はOracle Enterprise Managerの通知メカニズム、DGMGRLを使用している場合はSHOWコマンドが使用されます。
ブローカは、Data Guard構成をサポートします。各構成は、1つのプライマリ・データベースと、そのプライマリ・データベースに対してローカルまたはリモートのスタンバイ・データベース（最大9つ）で構成されます。データベースのいずれかにOracle Real Application Clusters（RAC）データベースを使用できます。
サポートされるData Guard構成には、次のコンポーネントが含まれています。
プライマリ・データベースとスタンバイ・データベースを管理する物理システム
アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルからREDOデータをスタンバイ・データベースに適用するログ適用サービス
Data Guardのログ適用サービスでは、スタンバイ・データベースが、REDO転送サービスによりプライマリ・データベースから自動的に転送されるREDOデータで更新されます。アーカイブREDOログ・ファイルとスタンバイREDOログ・ファイルには、リカバリ不能な変更や記録されていない変更を除き、すべてのデータベース変更が含まれています。フィジカル・スタンバイ・データベースでは、REDO ApplyによりREDOデータが適用され、プライマリ・データベースとのトランザクション的な一貫性が保たれます。ロジカル・スタンバイ・データベースでは、SQL ApplyによりREDOデータが適用され、プライマリ・データベースとのトランザクション的な一貫性が保たれます。スナップショット・スタンバイ・データベースでは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。
ブローカのData Guardモニター（DMON）プロセスによって、ブローカ構成はオブジェクトのグループとして構成およびメンテナンスされ、1つの単位として管理および監視できるようになります。したがって、複数のデータベースに影響するコマンドを入力すると、DMONプロセスでは次の操作が実行されます。
プライマリ・データベースに対する要求を実行します。
要求に必要な相手側の各データベースのDMONプロセスと協調しながら動作します。
ローカル・システム上の構成ファイルを更新します。
相手側の各データベースのDMONプロセスと通信して、構成ファイルのコピーを更新します。
DMONプロセスによって、データベースと構成を1単位として構成、監視および制御できるようになります。構成を無効にした場合は、その構成の全データベースのブローカ管理も無効になります。後で構成を有効化すると、その構成の各データベースに対してブローカ管理が有効化されます。
図3-1に、プライマリ・データベースとフィジカル・スタンバイ・データベースからなるブローカ構成を示します。
この図では、プライマリ・データベースについて、主要コンポーネントであるプライマリ・データベース、DMON、オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルに加えて、REDO転送サービスを示しています。また、プライマリ側にスタンバイREDOログ・ファイルを輪郭の状態で示しています。スタンバイREDOログは、現在無効であるが、スタンバイ・ロールへのスイッチオーバーに備えて構成済であることを示すために、輪郭で描かれています。フィジカル・スタンバイ・データベースに含まれるコンポーネントは、スタンバイ・データベース、ログ適用サービス、DMON、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルです。フィジカル・スタンバイ・データベース上のオンラインREDOログ・ファイルは、現在無効であるが、プライマリ・ロールへのスイッチオーバーに備えて構成済であることを示すために、輪郭で描かれています。
|
関連項目: フィジカル、スナップショットおよびロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
構成ファイルのコピーはデータベースごとに2つずつメンテナンスされるため、最後に認識された有効な構成の状態が常に記録されています。ブローカを初めて起動すると、オペレーティング・システム固有のデフォルト・パス名とファイル名を使用して、構成ファイルが自動的に作成されます。このデフォルト・パス名とファイル名を上書きするには、そのデータベースで次の初期化パラメータを設定します。
DG_BROKER_CONFIG_FILE1 DG_BROKER_CONFIG_FILE2
DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2初期化パラメータを設定する場合、次の制限事項に注意してください。
これらのパラメータは、Data Guard Brokerが実行中でない場合のみ設定または変更できます（DG_BROKER_START=FALSE）。
これらのパラメータには、すべてのOracle RACインスタンスで共有するRAWデバイス、ASMファイルまたはクラスタ・ファイル・システムのファイルを指定する必要があります。
Data Guard Brokerは、Oracleにより管理されるデータファイルまたはユーザーが管理するデータファイルのいずれかを使用するデータベースと連動します。これらのデータファイルは、RAWデバイス、ファイル・システムまたはASMディスク・グループに格納できます。この項の内容は、次のとおりです。
構成ファイル名は、SQL文ALTER SYSTEMを発行して動的に変更できます。ただし、これらのパラメータはブローカのDMONプロセスの実行中は変更できません。特定のデータベースでこれらの構成ファイルの名前を変更するには、次の手順を実行します。
DGMGRL DISABLEコマンドを使用してブローカ構成を無効化します。3.5項を参照してください。
次のSQL文を使用して、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の値が、同じ物理ファイル・セットを指す必要があります。 |
ファイルを移動する方法は、現在ファイルが格納されている場所およびファイルの移動先によって異なります。
ファイルがオペレーティング・ファイル・システムに格納されている場合は、オペレーティング・システムのコマンドを使用してファイルを新しい場所に移動します。
ファイルがRAWデバイスに格納されている場合は、新しい場所にファイルを手動で転送します。
元の場所または新しい場所がASMディスク・グループである場合は、DBMS_FILE_TRANSFER.COPY_FILE関数を使用して、新しい場所にファイルを転送します。
次のSQL文を使用してData Guard BrokerのDMONプロセスを再起動します。
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
DGMGRLのENABLEコマンドまたはEnterprise ManagerのData Guard管理ページの有効化操作を使用して、ブローカ構成を有効化します。
ブローカが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
ブローカの構成ファイルは、ASMディスク・グループにも格納できます。図3-3に、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）ではありません。ブローカの構成ファイルをASMディスク・グループ上に作成するには、初期化パラメータDG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2を、既存のASMディスク・グループの名前、そのディスク・グループ内の既存のディレクトリおよび構成ファイル自体の名前を含む文字列値に設定します。
CFSを使用できず、ASMを使用していない場合は、ファイルをRAWデバイスに格納する必要があります。この場合、各インスタンスのパラメータ値はRAWデバイスを指すように設定します。図3-4に、RAWデバイス上のブローカ構成ファイルの設定を示します。UNIXシステムでは、各ノードで次のように設定します。
% ln -s /dev/rdsk/c1t2d3s5 dr1inst1.dat % ln -s /dev/rdsk/c1t2d3s6 dr2inst2.dat
ブローカ構成ファイルをRAWデバイスに格納する必要がある場合は、それぞれ1MBのRAWデバイスを2つ追加設定します。DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2パラメータの値が、RAWデバイスを指すように設定します。1MBの構成ファイルは、データベース間に合計45のインスタンスを持つ10個のデータベースに対応します。
この構成のインスタンス数が46以上の場合は、さらに大きいデバイスが必要になる可能性があります。追加のインスタンスごとに15KBが必要になります。
構成ファイルの設定後に、各データベースのDG_BROKER_START初期化パラメータをTRUEに設定し、DMONプロセスを起動する必要があります。
デフォルトでは、DG_BROKER_START初期化パラメータはFALSEに設定されています。ただし、値は次の方法で設定できます。
Oracle Enterprise Managerを使用している場合、新規に作成されるスタンバイ・データベースのDG_BROKER_START初期化パラメータは自動的にTRUEに設定されます。
DGMGRLを使用している場合、DG_BROKER_START初期化パラメータは明示的にTRUEに設定する必要があります。TRUEに設定しないと、ブローカは起動しません。DG_BROKER_START初期化パラメータは、次のSQL文を使用して設定できます。
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE; System altered. SQL> SHOW PARAMETER DG_BROKER_START NAME TYPE VALUE ------------------------------------ dg_broker_start boolean TRUE
Enterprise ManagerとDGMGRLのどちらを使用している場合も、プライマリとスタンバイの各データベース上で、サーバー・パラメータ・ファイルのDG_BROKER_START初期化パラメータの値をTRUEに設定します。この設定により、いずれかのデータベース・インスタンスの次回起動時にData Guard Brokerが自動的に起動することが保証されます。
ブローカを使用すると、新規構成を作成したり既存の構成を管理できます。図3-5に、ブローカ構成のライフ・サイクルを示します。
Enterprise Managerを使用している場合は、スタンバイ・データベースの追加ウィザードを使用して、構成に既存のスタンバイ・データベース（RACまたは非RAC）を追加するか、新規のスタンバイ・データベース（RACまたは非RAC）を作成して構成に追加できます。スタンバイ・データベースは、フィジカル、ロジカルまたはスナップショットのどれでもかまいません。
DGMGRLを使用する場合は、プライマリ・データベースとスタンバイ・データベースがすでに存在している必要があります。スタンバイ・データベースは、プライマリ・データベースの制御ファイルとデータ・ファイルのバックアップから作成し、リカバリ用に準備します。
ブローカ構成の有効化
Data Guard構成は、ブローカで管理または監視するために有効化する必要があります。逆に、ブローカで管理する必要がなくなった場合には、構成を無効化します。構成を無効化すると、そのすべてのデータベースに関するブローカ管理も無効化されます。
|
注意: DGMGRLを使用すると構成を有効化または無効化できます。Enterprise Managerを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Enterprise Managerを使用して有効化できます。 |
ブローカ構成は、Enterprise Managerを使用して最初に作成された時点で、スタンバイ・データベースの追加ウィザードの完了後すぐに自動的に有効化されます。
ブローカ構成は、最初にDGMGRLを使用して作成された時点では無効な状態になっています。つまり、その構成要素であるデータベースは、まだブローカの制御下にありません。DGMGRLを使用してデータベースをブローカ構成に組み込んだ後は、ブローカで管理できるように構成を有効化する必要があります。
次のいずれかを有効化できます。
すべてのデータベースを含む構成全体
個々のスタンバイ・データベース
問題が発生して、ブローカ構成内のデータベースが正常に機能しない場合は、データベースを簡単に無効化できます。プライマリ・データベースは無効化できないことに注意してください。プライマリ・データベースを無効化するには、構成全体を無効にする必要があります。
さらに、構成を一時的に無効化し、実際のデータベース・プロパティに影響を与えずに、ブローカ構成内の一部のプロパティを変更することもできます。変更されたプロパティが有効になるのは、ブローカによる管理のために構成が再度有効化された場合です。
必要に応じたブローカ構成内のロール変更
単一のコマンドを発行することで、構成内のデータベースのロールをいつでも変更できます。なんらかのイベントによってプライマリ・データベースが使用不能になった場合は、スタンバイ・データベースの1つが新しいプライマリ・データベースになるようにフェイルオーバーできます。
また、メンテナンスのために予定されている停止時間を短縮できます。これは、本番処理を現行のプライマリ・データベースからスタンバイ・データベースにすばやく切り替えて、予定されたメンテナンスの完了後に逆の切替えをすばやく実行できるためです。
必要に応じたデータベースの状態変更
構成を初めて有効化すると、デフォルトで、プライマリのREDO転送サービスおよびスタンバイ（スナップショット・スタンバイを除く）のログ適用サービスが開始します。
Enterprise ManagerまたはDGMGRLを介して単一のコマンドを発行し、いつでもデータベースの状態を変更できます。たとえば、プライマリ・データベースをTRANSPORT-OFF状態にして、スタンバイ・データベースへのREDOデータの送信を一時的に停止できます。その後、別のコマンドを発行して、スタンバイ・データベースへのREDOデータの送信を再開することもできます。
必要に応じたデータベース・プロパティの更新
ブローカでは、データベース・プロパティを設定できます。一部のプロパティは、データベース初期化パラメータに対応しています。これらのプロパティを変更すると、REDOの転送、スタンバイ・ファイルの管理、ログの適用などを動的に制御し、構成の保護モード全体をサポートできます。ブローカは、Data Guard構成内のデータベースごとにブローカ構成ファイルに変更を記録し、その変更を必要に応じてサーバー・パラメータ・ファイル内の関連する初期化パラメータに伝播します。
必要に応じたデータ保護モードの設定
ブローカでは、構成のデータ保護モードを設定できます。保護モードを構成することで、データ保護、可用性またはパフォーマンスを最大化できます。
構成の監視
構成の健全性をチェックし、データベースのプロパティを表示および更新し、Oracle Enterprise Managerイベントを設定できます。
Enterprise Managerには、指定の間隔でグラフ・データやステータスを自動的および動的にリフレッシュする動的パフォーマンス・ページも用意されています。パフォーマンス・グラフには、生成および適用されているREDOデータの遅れと量のサマリーがグラフ形式で示されます。
ブローカによる管理における重要な概念は、ブローカ構成に含まれるデータベースのブローカ管理の有効化と無効化です。有効化と無効化の操作は、ブローカ構成に取り込まれているデータベースに対して定義されます。これらのブローカ操作は、ブローカ構成に属していないデータベースでは実行できません。これは、ブローカ構成内のデータベースを有効または無効にすると、実際にはブローカの次の機能が有効または無効になるためです。
指定されたデータベースの管理および監視
各データベースのブローカ構成ファイル内のプロファイル情報の管理
ただし、ブローカ構成を無効にしても、実際のData Guard構成内の現行のサービスと操作は影響を受けません。たとえば、ブローカ構成を無効にすると、Data Guard構成内のREDO転送サービスとログ適用サービスは引き続き機能しますが、ブローカ・インタフェース経由では管理できなくなります。
また、データベースを無効にしても、そのプロファイルがブローカ構成ファイルから削除されることはありません。無効化されたデータベースのプロパティを変更した後、DGMGRLのENABLE CONFIGURATIONまたはENABLE DATABASEコマンド、あるいはEnterprise ManagerのData Guard管理ページの「有効化」オプションを使用して、ブローカによる管理機能を再び有効化できます。
|
注意: ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。 |
ブローカによる構成管理を無効化すると、ブローカのデータベース監視および制御機能を削除する場合にも役立ちます。たとえば、構成を一時的に無効化し、ブローカ構成内の1つ以上のプロパティをすべて同時に変更すると便利な場合があります。無効化された構成でプロパティを変更した場合、その変更は構成を再び有効化するまで実行中のデータベースには適用されないため、制御対象となる実際のデータベース・プロパティに影響を与えることはありません。たとえば、無効化された構成で、構成の保護モード全体とREDO転送サービスのプロパティを変更し、次の有効化操作時にすべての変更を同時に構成へ適用できます。
構成ステータスは、構成全体の健全性を示します。この情報は、そのすべてのデータベースのステータスから取得されます。
構成に可能なステータス・モードは、次のとおりです。
構成は、内部で構成されているすべてのデータベースも含めて、エラーや警告なしでユーザーの指定どおりに動作しています。
構成内の1つ以上のデータベースで、ユーザーの指定どおりに操作が行われていません。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name> StatusReportコマンドまたはEnterprise Manager画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。
構成内の1つ以上のデータベースで障害が発生したか、またはユーザーの指定どおりに操作が行われない可能性があります。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name> StatusReportコマンドまたはEnterprise Manager画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。
UNKNOWN/DISABLED
構成のブローカ管理は無効化されており、ブローカは構成内のデータベースのステータスを監視していません。
