H ALTERNATE属性を使用したリモート代替宛先の構成
Oracle Database 12cリリース2 (12.2)以降、アクティブな宛先に障害があった場合に引き継ぐリモート・スタンバイ・データベースおよび遠隔同期インスタンスの代替ログ・アーカイブ先を作成するための優先的な方法は、GROUPおよびPRIORITY属性を使用することです。
ローカル・アーカイブの場所(LOCATION=…)にはALTERNATE属性が引き続き使用されます。これは、アーカイブの場所へのアクセスを妨げるディスクまたはネットワークの問題が原因で元のアーカイブ・ディレクトリが使用できなくなった場合に高可用性を提供するためです。しかし、リモートのログ・アーカイブ先(SERVICE=…)に対するALTERNATE属性の使用は、下位互換性のためにのみ維持されています。この方法を使用するために次の項に示されている例は、遠隔同期インスタンスを作成するための続きですが、REDO宛先のカスケードにも適用されます。
遠隔同期インスタンスの作成および構成のステップを実行すると、この時点で、遠隔同期インスタンスにより、WAN経由のリモート・サイトにあるターミナル・スタンバイに対する構成にデータ消失ゼロ機能が備わります。遠隔同期インスタンスとの通信が失われた場合に、低い保護レベルでも構成が保護されたままにするために、オプションでターミナル・スタンバイを自動的に代替宛先になるよう構成できます。これにより、Oracle Data Guardは遠隔同期インスタンスを一時的にバイパスして、プライマリからターミナル・スタンバイに直接REDOを非同期で送信できるため、データ消失量が削減されます。
関連項目:
H.1 代替宛先の構成
代替宛先を構成するには、プライマリ・データベースでこれらのパラメータを設定します。
プライマリ・データベース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リモート宛先が非同期REDO転送を使用して2つのデータベース間に直接設定されている場合、アクティブな遠隔同期インスタンスで障害が発生すると、構成の保護レベルは元の最大パフォーマンスに低下してフェイルオーバー時にデータ消失が発生します。システム障害またはネットワーク障害からの保護を強固にするため、アクティブな遠隔同期インスタンスが高い可用性を保持するように追加の遠隔同期インスタンスを構成できます。
次の構成では、一方は遠隔同期インスタンスであり、他方は代替遠隔同期インスタンスです。代替遠隔同期インスタンスを構成することで、優先遠隔同期インスタンスがなんらかの理由で失敗した場合に、構成に対する保護が継続されて最大の可用性で維持されます。プライマリは遠隔同期インスタンスで障害が検知されると、自動的に代替遠隔同期インスタンスへの送信を開始します。その後優先遠隔同期インスタンスが再確立すると、プライマリは優先遠隔同期インスタンスに切り替わり、代替遠隔同期インスタンスは代替状態に戻ります。
このタイプの構成では、プライマリはいつでも2つの遠隔同期インスタンスの一方のみを使用してREDOを再配信します。
2つ目の高可用性遠隔同期インスタンスは、遠隔同期インスタンスの作成および構成に示された同じステップを使用して作成されると、ターミナル・スタンバイではなく既存の遠隔同期インスタンスに対する代替になります。完了したときのchicagoのパラメータは、次のように構成されています(名前chicagoFS1は、新しい遠隔同期インスタンスの名前とします)。
プライマリ・データベースchicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston)'
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)'この時点で、Oracle Data Guardは、遠隔同期インスタンスにREDOを同期的に送信し続けることができ、なんらかの理由で遠隔同期インスタンスに障害が発生しても、必要なデータ消失ゼロの最大可用性保護モードを維持します。前述のように、障害が発生した遠隔同期インスタンスが再度使用できるようになると、Oracle Data Guardは自動的に再同期し、プライマリが1つ目の遠隔同期インスタンスにREDOを送信し、遠隔同期インスタンスがターミナル・スタンバイにそのREDOを転送する元の構成に戻ります。同期が完了すると、代替宛先(前の例ではLOG_ARCHIVE_DEST_3)は再度代替として休止状態になります。しかし、両方の遠隔同期インスタンスに障害が発生した場合、3つ目の代替機能がないためREDOはターミナル・スタンバイbostonに送信されません。そのシナリオは、ALTERNATEのかわりにGROUPおよびPRIORITY属性を使用して実現できます。