| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成の他のメンバーに送信する、リモートのOracle Data Guardの宛先です。遠隔同期インスタンスは、制御ファイルを管理し、REDOをスタンバイREDOログ(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログにアーカイブしますが、スタンバイとの類似はそこまでです。遠隔同期インスタンスにはユーザー・データファイルは含まれず、アクセスのために開くことも、REDO Applyを実行することもできず、プライマリ・ロールで機能することも、スタンバイ・データベースの任意のタイプに変換することもできません。
遠隔同期インスタンスはOracle Active Data Guard遠隔同期機能の一部で、Oracle Active Data Guardのライセンスが必要です。
遠隔同期インスタンスは、ディスク・リソースおよび処理リソースをほとんど消費しませんが、データ消失せずにターミナル宛先にフェイルオーバーする機能を提供します。また、プライマリ・データベースの他のタイプのオーバーヘッドをオフロードする機能(REDO転送など)も提供します。
一般的なスタンバイ宛先のサービス中にプライマリで使用可能なすべてのREDO転送オプションは、遠隔同期インスタンスのサービス中にも使用可能です。また、すべてのREDO転送オプションは、ターミナル宛先のサービス中に遠隔同期インスタンスで使用可能です(Oracle Advanced Compressionオプションのライセンスを保有している場合、REDO転送圧縮の実行など)。
多くの構成では、フェイルオーバー時に一部のデータが消失するリスクがあっても非同期転送を使用してスタンバイ・データベースにREDOを送信するプライマリ・データベースがあります。同期REDO転送を使用したデータ消失ゼロの実現は、2つのデータベース間のネットワーク待機時間によるプライマリでのコミット・レスポンス時間への影響のため、実行可能なオプションではない場合があります。
プライマリの近くに遠隔同期インスタンスを作成する利点は、データ保護の保証を強化できると同時に、(プライマリと遠隔同期インスタンス間のネットワーク待機時間が小さくなるため)コミット・レスポンス時間に対する影響を許容しきい値まで最小限に抑えることができることです。プライマリに障害が発生した場合、障害時に遠隔同期インスタンスが同期していたとすると、遠隔同期インスタンスおよびターミナル・スタンバイは、遠隔同期インスタンスからスタンバイへの最終REDO送信を調整してスタンバイでまだ使用できないREDOを送信してから、データ消失ゼロのフェイルオーバーを実行します。
次のトピックを参照してください。
遠隔同期インスタンスの作成は、データファイルが遠隔同期インスタンスには存在しないことを除き、フィジカル・スタンバイの作成と似ています。そのため、遠隔同期インスタンスでは、データファイルのコピーまたはバックアップからのデータファイルのリストアが不要です。遠隔同期インスタンスを作成したら、構成を変更して、プライマリ・データベースから遠隔同期インスタンスに同期的に最大可用性モードでREDOが送信された後、遠隔同期インスタンスによって非同期でリアルタイムに転送されるようにします。最後に、元の非同期スタンバイ(ターミナル・スタンバイと呼ばれます)を構成して、遠隔同期インスタンスとの通信が割り込まれたときには遠隔同期インスタンスに対する代替として機能するようにします。
注意:
遠隔同期インスタンスを含む構成では、プライマリ・データベースとリモート・スタンバイ・データベース間にネットワークの直接接続が存在している必要があります。プライマリとリモート・スタンバイ間の直接接続は、ヘルス・チェックおよびスイッチオーバー処理タスクの実行に使用されます。この接続は、遠隔同期インスタンスが失敗し、保護レベルを維持するために構成された代替の遠隔同期が存在しない場合に備えて、スタンバイが代替の宛先として構成されていないかぎり、REDO転送には使用されません。
この項の内容は次のとおりです。
遠隔同期インスタンスを作成するには、次の手順を実行します。
例5-1 遠隔同期インスタンスに使用される初期化パラメータ(一部)
プライマリ・データベースchicago
DB_UNIQUE_NAME=chicago CONTROL_FILES='/arch1/chicago/control01.ctl' DB_FILE_NAME_CONVERT='/boston/','/chicago/' LOG_FILE_NAME_CONVERT='/boston/','/chicago/' FAL_SERVER=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS'
遠隔同期インスタンスchicagoFS
DB_UNIQUE_NAME=chicagoFS CONTROL_FILES='/arch2/chicagoFS/control01.ctl' DB_FILE_NAME_CONVERT='/chicago/','/chicagoFS/','/boston/','/chicagoFS/' LOG_FILE_NAME_CONVERT='/chicago/','/chicagoFS/','/boston/','/chicagoFS/' FAL_SERVER=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston'
フィジカル・スタンバイboston
DB_UNIQUE_NAME=boston CONTROL_FILES='/arch3/boston/control01.ctl' DB_FILE_NAME_CONVERT='/chicago/','/boston/' LOG_FILE_NAME_CONVERT='/chicago/','/boston/' FAL_SERVER='chicagoFS','chicago' LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
「遠隔同期インスタンスの作成および構成」の手順を実行すると、この時点で、遠隔同期インスタンスにより、WAN経由のリモート・サイトにあるターミナル・スタンバイに対して構成にはデータ消失ゼロ機能が備わっています。遠隔同期インスタンスとの通信が失われた場合に、構成が最大パフォーマンス・レベルで保護されたままにするために、自動的に代替宛先になるようにターミナル・スタンバイをオプションで構成できます。これにより、Oracle Data Guardは遠隔同期インスタンスを一時的にバイパスして、プライマリからターミナル・スタンバイに直接REDOを非同期で送信できるため、データ消失量が削減されます。
代替宛先を構成するには、プライマリ・データベースで次のようにパラメータを設定します。
プライマリ・データベースchicago
LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=boston ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
これにより、Oracle Data Guardは遠隔同期インスタンスchicagoFSに直接REDOを送信できなくなったときに、ターミナル・スタンバイbostonにREDOを非同期で送信し続けることができます。遠隔同期インスタンスが再度使用できるようになると、Oracle Data Guardは遠隔同期インスタンスchicagoFSと自動的に再同期し、プライマリが遠隔同期インスタンスにREDOを送信し、遠隔同期インスタンスがターミナル・スタンバイにそのREDOを転送する元の構成に戻ります。同期が完了すると、代替宛先(前の例ではLOG_ARCHIVE_DEST_3)は再度代替として休止状態になります。
ALTERNATE属性の詳細は、「ALTERNATE」を参照してください。
この項では、2つの追加の遠隔同期インスタンス構成の例を示します。これらの例では、遠隔同期インスタンスを使用する場合に、データ保護がより強固になるバリエーションを示します。
ロール変更後も保護を継続するために、2つの遠隔同期インスタンスを構成できます。一方は構成の各データベースの近くにあり、いつでもアクティブなのは1つのみです。他方はプライマリ・データベースとターミナル・スタンバイ・データベース間でロール変更が発生するとアクティブになります。これにより、どのデータベースがプライマリ・データベースであるかに関係なく、構成を希望する保護モードのままにすることができます。
システム障害またはネットワーク障害からの保護を強固にするため、アクティブな遠隔同期インスタンスが高い可用性を保持するように2つの追加の遠隔同期インスタンスを構成できます。この構成では、一方は優先アクティブ遠隔同期インスタンスであり、他方は代替遠隔同期インスタンスです。代替遠隔同期インスタンスを構成することで、優先遠隔同期インスタンスがなんらかの理由で失敗した場合に、構成に対する保護が継続されます。プライマリは遠隔同期インスタンスで障害が検知されると、自動的に代替遠隔同期インスタンスへの送信を開始します。優先遠隔同期インスタンスが再確立すると、プライマリは優先遠隔同期インスタンスに切り替わり、代替遠隔同期インスタンスは代替状態に戻ります。
このタイプの構成では、プライマリはいつでもこれらの遠隔同期インスタンスの一方のみを使用してREDOを再配信します。
「遠隔同期インスタンスの作成および構成」および「ALTERNATE宛先の構成」で説明している構成は、bostonがプライマリ・データベースになり、chicagoがターミナル・スタンバイになるロールの推移後では不適切です。遠隔同期インスタンスchicagoFSは、2つのサイト間のネットワーク待機時間がコミット・レスポンス時間に影響を及ぼすほど大きいため、bostonが同期宛先として使用するには遠すぎます。データ消失ゼロのために最大可用性の保護レベルを維持するには、将来のロールの推移イベントに備えて、2つ目の遠隔同期インスタンスをbostonの近くに確立する必要があります。
「遠隔同期インスタンスの作成および構成」および「ALTERNATE宛先の構成」で説明しているのと同じ手順を使用して、bostonFSという遠隔同期インスタンスをスタンバイ・データベースbostonの近くに作成します。例5-2に、新しい遠隔同期インスタンスbostonFSに設定したパラメータを示します。
注意:
遠隔同期インスタンスbostonFSはbostonからREDOを受け取り、bostonがプライマリ・データベースである場合のみchicagoにそれを送信します。ただし、bostonがプライマリ・データベースでない場合でも、将来のロールの推移に備えて、遠隔同期インスタンスbostonFSをマウントしたままにすることをお薦めします。
例5-2 ロール変更後の保護設定に使用されるパラメータ
遠隔同期インスタンスbostonFS
DB_UNIQUE_NAME=bostonFS CONTROL_FILES='/arch2/bostonFS/control01.ctl' FAL_SERVER=boston LOG_FILE_NAME_CONVERT='boston','bostonFS' LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_2='SERVICE=chicago ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago'
スタンバイ・データベースbostonのパラメータ・セットは、次のように変更しておきます。
フィジカル・スタンバイ・データベースboston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=chicago ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
最後に、chicagoのパラメータを次のように変更します。
プライマリ・データベースchicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' FAL_SERVER='bostonFS','boston'
ALTERNATEリモート宛先が、非同期REDO転送を使用して2つのデータベース間に直接設定されている場合、アクティブな遠隔同期インスタンスで障害が発生すると、構成の保護レベルは最大パフォーマンスに低下し、フェイルオーバー時にデータ消失の可能性があります。
最大可用性の保護レベルを維持するために、2つ目の遠隔同期インスタンスを、各データベースで使用される遠隔同期インスタンス(プライマリ)に対するALTERNATEとして設定できます。その結果、アクティブな遠隔同期インスタンスが使用できなくなった場合、プライマリ・データベースは代替遠隔同期インスタンスにREDOを同期モードで送信することを自動的に開始できるため、最大可用性の高保護レベルを維持します。前述のように、元の遠隔同期インスタンスが再確立すると、プライマリはそれをアクティブな遠隔同期インスタンスとして使用することを自動的に再開し、2つ目のローカル遠隔同期インスタンスは再び代替になります。
これらの高可用性遠隔同期インスタンスは、「遠隔同期インスタンスの作成および構成」に示しているのと同じ手順を使用して作成されると、ターミナル・スタンバイではなくローカル遠隔同期インスタンスに対する代替になります。完了したときのchicagoおよびbostonのパラメータは、次のように構成されています(名前chicagoFS1およびbostonFS1は、新しい遠隔同期インスタンスの名前とします)。
例5-3 高可用性遠隔同期インスタンスの設定に使用されるパラメータ
プライマリ・データベースchicago
FAL_SERVER=bostonFS, bostonFS1, boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston,bostonFS,bostonFS1)' LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=chicagoFS1 SYNC AFFIRM ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS1'
フィジカル・スタンバイboston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston,bostonFS,bostonFS1)' LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=bostonFS1 SYNC AFFIRM ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS1'
この時点で、Oracle Data Guardは、遠隔同期インスタンスにREDOを同期的に送信し続けることができ、chicagoとbostonのどちらがプライマリ・データベースであるかに関係なく、必要なデータ消失ゼロの最大可用性保護モードを維持します。前述のように、障害が発生した遠隔同期インスタンスが再度使用できるようになると、Oracle Data Guardは自動的に再同期し、プライマリが1つ目の遠隔同期インスタンスにREDOを送信し、遠隔同期インスタンスがターミナル・スタンバイにそのREDOを転送する元の構成に戻ります。同期が完了すると、代替宛先(前の例ではLOG_ARCHIVE_DEST_3)は再度代替として休止状態になります。
最大可用性モードでは、遠隔同期インスタンスはネットワーク待機時間を最小化するために比較的プライマリ・データベースに近く、プライマリはSYNC転送を使用して遠隔同期インスタンスにサービスを提供します。
注意:
最大可用性モードでのプライマリと遠隔同期インスタンスの間の距離に、アーキテクチャ上の制限はありません。実際の距離の制限は、同期構成でのネットワーク待機時間の影響に対する、特定のアプリケーションの許容度範囲により異なります。また、新しいOracle Data Guard FastSync機能(SYNC/NOAFFIRM)を使用して、どのような距離に対してもパフォーマンスの影響を低減することが可能です。「最大可用性モードでのパフォーマンス対保護」を参照してください。
SYNC/AFFIRMセマンティクスとSYNC/NOAFFIRMセマンティクスはいずれも、遠隔同期インスタンス用にプライマリで確立されるLOG_ARCHIVE_DEST_nでサポートされています。それぞれの使用のトレードオフについては、「Oracle Data Guardの保護モード」を参照してください。
プライマリがSYNC転送を使用した遠隔同期インスタンスをサービスするとき、すべてのコミットされたREDOは遠隔同期インスタンスのディスクに存在します。これにより、プライマリ・データベースが失われると、遠隔同期インスタンスはデータの消失のないフェイルオーバーのために、ターミナル・スタンバイ宛先の1つを使用できます。
遠隔同期インスタンスはASYNC転送を使用して、より遠くにあるターミナル・スタンバイに受信REDOを送信します。これにより、トランザクション・スループットの低下が生じるために、プライマリ・データベースにとってSYNC転送を使用して直接サービスするには遠すぎる宛先へ、データの消失のない保護が拡大されます。これは、構成内に1つのスタンバイ宛先しか存在しない場合でも、遠隔同期インスタンスが役に立つ例です。
最大パフォーマンス・モードでは、プライマリ・データベースは、プライマリと遠隔同期インスタンス間の距離に関係なく、ASYNC REDO転送を使用して遠隔同期インスタンス宛先にサービスを提供します。ASYNC転送を使用して宛先にサービスが提供される場合は、長いネットワーク待機時間はトランザクション・スループットに影響しないからです。
最大パフォーマンス・モードでは、遠隔同期インスタンスは複数のリモート宛先を管理するOracle Data Guard構成に役立ちます。各ASYNC宛先のプライマリ・データベースのパフォーマンスに与える影響はほとんどゼロですが、多くのリモート宛先が存在する場合は(リーダー・ファームを形成する複数のOracle Active Data Guardスタンバイなど)、その影響が少なからず発生することがあります。遠隔同期インスタンスが使用される場合、リモート宛先が構成に追加されることで影響が増加することはありません。さらに、REDO転送圧縮も遠隔同期インスタンスへオフロードすることができます。遠隔同期インスタンスを使用する場合、プライマリは遠隔同期インスタンスにサービスを提供するだけで、その遠隔同期インスタンスが残りの構成にサービスを提供します。宛先の数が多くなるほど、パフォーマンスは大きく向上します。
