5 遠隔同期インスタンスの使用
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を送信してから、データ消失ゼロのフェイルオーバーを実行します。
次のトピックを参照してください。
5.1 遠隔同期インスタンスの作成
遠隔同期インスタンスの作成は、データファイルが遠隔同期インスタンスには存在しないことを除き、フィジカル・スタンバイの作成と似ています。
そのため、遠隔同期インスタンスでは、データファイルのコピーまたはバックアップからのデータファイルのリストアが不要です。遠隔同期インスタンスを作成したら、構成を変更して、プライマリ・データベースから遠隔同期インスタンスに同期的に最大可用性モードでREDOが送信された後、遠隔同期インスタンスによって非同期でリアルタイムに転送されるようにします。最後に、元の非同期スタンバイ(ターミナル・スタンバイと呼ばれます)を構成して、遠隔同期インスタンスとの通信が割り込まれたときには遠隔同期インスタンスに対する代替として機能するようにします。
注意:
遠隔同期インスタンスを含む構成では、プライマリ・データベースとリモート・スタンバイ・データベース間にネットワークの直接接続が存在している必要があります。プライマリとリモート・スタンバイ間の直接接続は、ヘルス・チェックおよびスイッチオーバー処理タスクの実行に使用されます。この接続は、遠隔同期インスタンスが失敗し、保護レベルを維持するために構成された代替の遠隔同期が存在しない場合に備えて、スタンバイが代替の宛先として構成されていないかぎり、REDO転送には使用されません。
5.1.1 遠隔同期インスタンスの作成および構成
遠隔同期インスタンスを作成するには、次の手順を実行します。
例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'
5.2 代替アーカイブ先
遠隔同期インスタンスの作成および構成の手順を実行すると、その後、遠隔同期インスタンスには、WAN経由のリモート・サイトにあるターミナル・スタンバイにREDOを転送することで構成にデータ消失ゼロ機能が備わります。遠隔同期インスタンスがアクセスできない場合でも構成が保護されたままにするには、スタンバイ・データベースへの代替REDO転送パスを構成する必要があります。これは、LOG_ARCHIVE_DEST_n
パラメータのGROUP
およびPRIORITY
属性を使用して達成できます。(Oracle Database 12cリリース2 (12.2.0.1)以降、GROUP
およびPRIORITY
属性で遠隔REDO宛先のALTERNATE
属性が置き換えられています。)
可能な代替遠隔宛先の数は、ログ・アーカイブ先グループの概念により増加しました。ログ・アーカイブ先グループで複数のアーカイブ先を指定し、遠隔同期インスタンスから、またはカスケードにより、複数の宛先にREDOを配布するために使用できます。グループ内の宛先は、プライマリ・データベース上で一度に1つの宛先のみがアクティブになるように優先順位付けできます。その他の宛先は、アクティブな宛先が使用不可になると使用可能でアクティブになります。使用しているデータベースの可能なアーカイブ先の数を拡張するには、複数のグループを指定できます。
関連項目:
-
古い
ALTERNATE
構文を使用した代替リモート宛先の構成については、ALTERNATE属性を使用したリモート代替宛先の構成を参照してください。
5.2.1 グループへのログ・アーカイブ先の割当て
LOG_ARCHIVE_DEST_n
初期化パラメータのGROUP
属性を使用して、ログ・アーカイブ先をグループに割り当てます。
ログ・アーカイブ先グループが使用されている場合、グループ内に少なくとも1つの宛先が使用できるかぎり、引き続き少なくとも1つの宛先が有効でアクティブになります。グループに割り当てられていないログ・アーカイブ先は、Oracle Database 12cリリース2 (12.2.0.1)より前のログ・アーカイブ先と同じように動作します。
1つのグループに最大30のログ・アーカイブ先が可能です。ログ・アーカイブ先グループは、グループの作成時に割り当てられるグループ番号で参照されます。グループは1から8まで番号付けされます。ログ・アーカイブ先グループには遠隔の(SERVICE=
…)宛先のセットが含まれます。(ローカル・アーカイブ(LOCATION=
…)の宛先はログ・アーカイブ先グループではサポートされず、代替ローカル・アーカイブ場所にはALTERNATE
属性を使用する必要があります。ALTERNATEを参照してください。
グループ内の1つのログ・アーカイブ先が常にアクティブで、その他はアクティブなログ・アーカイブ先の障害の場合に使用可能です。障害があった宛先が再度使用可能になった場合、現在アクティブな宛先に障害が発生した場合の対象になりますが、その他のグループ・メンバーもすべて使用不可にならないかぎりすぐにアクティブにはなりません。たとえば、次の宣言を使用して3つの遠隔同期インスタンスを同じグルーブのメンバーで同じ優先順位を持つと指定できます(グループ内の優先順位は次の項で説明します)。これらはサンプル・パラメータ定義で、必要な属性のすべては含んでいません。Verbatimで使用しないでください。この例では、最初の宛先のみがアクティブで、2番目の宛先は宛先1が使用不可になった場合の引継ぎに使用できます。
LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=chicagoFS1 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
注意:
ログ・アーカイブ先グループはLOG_ARCHIVE_DEST_n
ALTERNATE
属性を置き換えるため、デフォルト・グループ(GROUP
が1から8として指定)にないログ・アーカイブ先でのALTERNATE
属性の使用は許可されていません。
5.2.2 グループ内のログ・アーカイブ先に対する優先順位の割当て
LOG_ARCHIVE_DEST_n
初期化パラメータのPRIORITY
属性を使用してログ・アーカイブ先グループ内に宛先の優先順位を割り当てると、フェイルバック・メカニズムを、特に1つのグループ内に複数のメンバーがある場合に制御できます。また、PRIORITY属性を使用して、優先宛先に障害があった場合に複数の宛先に送信するようにグループを構成することもできます。
前出の項では、2つの遠隔同期インスタンスが優先順位を持っていませんでした。これは、最初の宛先の障害後に代替宛先がアクティブ化されると、障害が発生するまではアクティブな宛先のままになることを意味します。優先順位は、データベースまたは遠隔同期インスタンスが起動したとき、または宛先に障害が発生したときにグループ内のどのログ・アーカイブ先をアクティブにするかを決定するために使用されます。ログ・アーカイブ先は、プライマリ・データベースが読取り/書込みモードでオープンされるか、遠隔同期インスタンスがマウントされるか、スタンバイ・データベースがマウントされるか読取り専用でオープンされる場合にアクティブになります。同じ優先順位値を2つ以上のログ・アーカイブ先に割り当てることができます。優先順位値は1から8の範囲の整数です。数値が低いほど優先度が高くなります。デフォルトの優先順位は1 (最も高い優先順位)です。
優先順位は、以前に障害が発生したアーカイブ先が再び使用可能になったときに機能します。同じグループに割り当てられたログ・アーカイブ先のセットは、デフォルトで同じ優先順位を持ちます。したがって、1つの宛先に障害があるともう一方のセット・メンバーに対してフェイルオーバーが発生します。障害が発生した宛先が再度使用可能になった場合、両方の宛先が同じ優先順位を持つためアクティブになりません。最初のアーカイブ先が再度使用可能になった後で2番目のアーカイブ先に障害が発生した場合、データベースは最初のアーカイブ先またはグループ内の同じ優先順位を持つ別のアーカイブ先にフェイルオーバーします。このサイクルは、アクティブな宛先に障害が発生する前に一方の宛先が常に使用可能であるという条件で無限に繰り返す可能性があります。
以前のサンプルを続行すると、優先順位がログ・アーカイブ先に追加され、宛先がいつアクティブになるかを制御できます。次の例では、3つ目の遠隔同期インスタンスが追加されますが、優先順位は低いです。
LOG_ARCHIVE_DEST_2=’SERVICE=chicagoFS SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3=’SERVICE=chicagoFS1 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4=’SERVICE=chicagoFS2 ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=2’
LOG_ARCHIVE_DEST_STATE_4=ALTERNATE
この宣言結果の動作は、次のようになります。
-
プライマリは2つの優先遠隔同期インスタンスの1つ目
chicagoFS
にREDOを送信します。 -
chicagoFS
が使用不可になると、プライマリがchicagoFS1
に送信します。 -
chicagoFS
が再度使用可能になると、フェイルオーバーは発生しません。優先順位が同じためchicagoFS1
に対する代替になります。 -
chicagoFS
とchicagoFS1
の両方が使用不可になった場合、プライマリはchicagoFS2
に送信します(この場合はASYNC
REDO転送モード経由)。 -
プライマリが
chicagoFS2
に対して送信中にchicagoFS
またはchicagoFS1
のいずれかが使用可能になった場合、プライマリはその使用可能な優先ログ・アーカイブ先にフェイルバックします。
5.2.3 グループ内の複数のアクティブな宛先への送信
また、PRIORITY
属性を使用して、優先宛先に障害が発生した場合にグループを複数の宛先に送信するように構成することもできます。
単一グループ内で複数のアクティブな宛先をサポートするメカニズムでは、そのグループ内で該当する優先順位を持つアクティブな宛先に対して最も低い優先順位(PRIORITY=8
)が定義され、一般にターゲット・スタンバイ・データベースにREDOを直接に送信するために使用されます。次のログ・アーカイブ先宣言は、これをどのように構成できるかを示しています。この例では、2つのターミナル・スタンバイ・データベースにREDOを転送する遠隔同期インスタンスが1つあります。
LOG_ARCHIVE_DEST_2=’SERVICE=chicagoFS SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3=’SERVICE=boston ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=8’
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4=’SERVICE=newyork ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=8’
LOG_ARCHIVE_DEST_STATE_4=ALTERNATE
この宣言結果の動作は、次のようになります。
-
プライマリは優先遠隔同期インスタンス
chicagoFS
にREDOを送信します。 -
chicagoFS
が使用不可の場合、プライマリはboston
とnewyork
の両方のターミナル・スタンバイにASYNC
モードで直接送信します。 -
boston
とnewyork
への送信中にchicagoFS
が使用可能になった場合、プライマリはboston
とnewyork
への直接送信を停止して、かわりにchicagoFS
への送信を開始します。
5.2.4 複数のログ・アーカイブ先グループの使用
複数のログ・アーカイブ先グループは、サイト固有の高可用性の検討または大規模なカスケード(リーダー・ファーム)構成へのサービスの配布に使用できます。
次の宣言は、chicagoFS
とchicagoFS1
をグループ1、chicagoFS3
とchicagoFS4
をグループ2に含む複数のログ・アーカイブ先グループを設定します。
LOG_ARCHIVE_DEST_2=’SERVICE=chicagoFS SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3=’SERVICE=chicagoFS1 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4=’SERVICE=chicagoFS3 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=2 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_4=ENABLE
LOG_ARCHIVE_DEST_5=’SERVICE=chicagoFS4 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=2 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_5=ALTERNATE
5.2.5 ログ・アーカイブ先の可用性ステータスの判断
Oracle Data Guardでは、ログ・アーカイブ先グループ内で使用可能であるが非アクティブな宛先の現在のステータスを、定期的に構成済宛先をポーリングすることにより追跡してその可用性を判断します。
可用性を判断するために使用される情報は、プライマリ・データベースが障害がある宛先を放棄する前に、REDO転送サービスが通信を再確立してその宛先へのREDOデータを転送する連続試行回数を指定するMAX_FAILURE
属性から導出されます。MAX_FAILURE
のデフォルト値は、GROUP
およびPRIORITY
属性が使用されている場合は1です。
MAX_FAILURE
属性の動作は、Oracle Database 12cリリース1 (12.1)とOracle Database 12cリリース2 (12.2)の間で異なります。この違いを理解しておくことが重要です。
関連項目:
5.3 代替アーカイブ先の構成
遠隔同期インスタンス構成は、様々なレベルのデータ保護を提供するように設定できます。
次のトピックでは、前の項で示した例を拡張して、遠隔同期インスタンスを使用する場合にデータ保護を強化する追加の遠隔同期インスタンス構成2つの例を示します。
5.3.1 遠隔同期障害後の保護の低下
すべての遠隔同期インスタンス構成で、REDOがターミナル・スタンバイへの送信を継続し、プライマリ・データベースを引き続き保護することが重要です。
最も単純な構成では、遠隔同期通信が1つ(chicagoFS
)とターミナル・スタンバイ・データベースが1つ(boston
)あります。
遠隔同期インスタンスに障害が発生した場合、REDOはプライマリ・データベースchicago
にログ・アーカイブ先を追加することでターミナル・スタンバイに直接送信する必要があります。これにより、REDO転送がSYNC
モードのかわりにASYNC
モードになるため、保護レベルが低下します。
例5-2 単一宛先フェイルオーバーに対する構成
プライマリ・データベースchicago
LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=boston ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston GROUP=1 PRIORITY=2'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
この宣言により、遠隔同期インスタンスchicagoFS
に障害が発生した場合にプライマリ・データベースがターミナル・スタンバイに直接REDOを送信します。遠隔同期インスタンスが再度使用可能になった場合、アクティブな宛先となりREDO転送が遠隔同期インスタンスに送られます。
遠隔同期インスタンスに複数のターミナル・スタンバイがある場合、PRIORITY=8
を使用して、遠隔同期インスタンスに障害が発生した場合にそれらの宛先のすべてがプライマリ・データベースから直接REDOを受け取るようにします。
例5-3 複数スタンバイ・データベースのREDO宛先フェイルオーバーに対する構成
プライマリ・データベースchicago
以前の例にあるように、遠隔同期インスタンスに対するプライマリ・データベースのログ・アーカイブ先を変更して優先順位1のグループに追加した後、遠隔同期インスタンスが優先順位8、ASYNCモードでサポートする各スタンバイに対する新しいログ・アーカイブ先を追加します。
LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=boston ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston GROUP=1 PRIORITY=8'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4='SERVICE=newyork ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=newyork GROUP=1 PRIORITY=8'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
この宣言により、遠隔同期インスタンスchicagoFS
に障害が発生した場合にプライマリ・データベースが両方のターミナル・スタンバイ・データベースに直接REDOを送信します。遠隔同期インスタンスが再度使用可能になった場合、アクティブな宛先となりREDO転送が遠隔同期インスタンスに送られます。
5.3.2 遠隔同期インスタンスの高可用性
代替遠隔同期インスタンスを構成することで、優先遠隔同期インスタンスがなんらかの理由で失敗した場合に、構成の保護レベルが最大可用性の構成済保護レベルに維持されます。
先行するどちらの例でも、REDOがSYNC
モードで送信されなくなるため保護レベルが「最大可用性」の範囲を外れる場合があります。システム障害またはネットワーク障害からの保護を強固にするため、アクティブな遠隔同期インスタンスが高い可用性を保持するように追加の遠隔同期インスタンスを構成できます。この構成では、一方は優先アクティブ遠隔同期インスタンスであり、他方は代替遠隔同期インスタンスです。
プライマリは遠隔同期インスタンスで障害が検知されると、自動的に代替遠隔同期インスタンスへの送信を開始します。このタイプの構成では、プライマリはいつでも1つの遠隔同期インスタンスのみを使用してREDOを再配信します。
最大可用性の保護レベルを維持するには、プライマリ・データベースに近い2つの遠隔同期インスタンスを構成してお互いを保護するように設定します。その結果、アクティブな遠隔同期インスタンスが使用できなくなった場合、プライマリ・データベースは代替遠隔同期インスタンスにREDOを同期モードで送信することを自動的に開始できるため、最大可用性の高保護レベルを維持します。ただし、この場合、2つの遠隔同期インスタンスが同じ優先順位であり、一方が他方を引き継ぐと障害が発生するまではアクティブな遠隔同期インスタンスのままになります。両方の遠隔同期インスタンスに障害が発生してもREDOが引き続きスタンバイ・データベースに送信されるようにするために、ターミナル・スタンバイ・データベースは以前のようにPRIORITY=2
で構成されます。(2つ以上のターミナル・スタンバイ・データベースがある場合はPRIORITY=8
を使用します)。
高可用性遠隔同期インスタンスは、遠隔同期インスタンスの作成および構成に示されているのと同じ手順を使用して作成され、REDOをターミナル・スタンバイbostonに転送するように構成されます。
例5-4 高可用性遠隔同期インスタンスの設定に使用されるパラメータ
プライマリ・データベースchicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston)'
LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=chicagoFS1 SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS1 GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4='SERVICE=boston ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston GROUP=1 PRIORITY=2'
LOG_ARCHIVE_DEST_STATE_4=ALTERNATE
Oracle Data Guardは、遠隔同期インスタンスにREDOを同期的に送信し続けて、遠隔同期インスタンスに障害が発生しても必要なデータ消失ゼロの最大可用性保護モードを維持できるようになっています。両方の遠隔同期インスタンスに障害が発生した場合、REDOは、ASYNC
モードで、低下した保護レベルでboston
に送信されます。前述のように、障害が発生した遠隔同期インスタンスのいずれかが再度使用できるようになると、Oracle Data Guardは自動的に再同期し、プライマリがアクティブな遠隔同期インスタンスにREDOを送信した後、その遠隔同期インスタンスがターミナル・スタンバイにそのREDOを転送する元の構成に戻ります。同期が完了すると、スタンバイ(前の例ではLOG_ARCHIVE_DEST_4
)の代替宛先は再度代替として休止状態になります。
5.3.3 ロール変更後の保護の維持
これらの例では、ロールの変更後もデータ保護を維持する方法について説明します。
以前の項に記載された構成は良好に機能し、すべての遠隔同期インスタンスに障害が発生してREDOがスタンバイ・データベースに直接送信されるまでは最大可用性で構成の稼働を維持します。しかし、boston
がプライマリ・データベースになりchicago
がターミナル・スタンバイになるというロールの推移の後は適切に動作しないことが考えられます。遠隔同期インスタンスchicagoFS
とchicagoFS1
は、2つのサイト間のネットワーク待機時間がコミット・レスポンス時間に影響を及ぼすほど大きいため、boston
が同期宛先として使用するには遠すぎると考えられます。データ消失ゼロのために最大可用性の保護レベルを維持するには、将来のロールの推移イベントに備えて、2つ目の遠隔同期インスタンス構成をboston
の近くに確立する必要があります。
遠隔同期インスタンスの作成および構成で説明しているのと同じ手順を使用して、bostonFS
およびbostonFS1
という2つの遠隔同期インスタンスをスタンバイ・データベースboston
の近くに作成し、アクティブなときにREDOをASYNC
モードでchicago
に送信するようにその両方を構成します。その後、boston
がプライマリのときにREDOを遠隔同期インスタンスの1つにchicago
およびその遠隔同期インスタンスに対して構成されたすべてのフェイルオーバー機能とともにSYNC
モードで送信できるように、それらをboston
に追加します。新しいboston
遠隔同期インスタンスをboston
とchicago
の両方のLOG_ARCHIVE_CONFIG
に追加する必要があります。
例5-5 ロール変更後の保護設定に使用されるパラメータ
プライマリ・データベースboston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston, bostonFS, bostonFS1)'
LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=bostonFS1 SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS1 GROUP=1 PRIORITY=1’
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
LOG_ARCHIVE_DEST_4='SERVICE=chicago ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago GROUP=1 PRIORITY=2'
LOG_ARCHIVE_DEST_STATE_4=ALTERNATE
プライマリ・データベースchicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston, bostonFS, bostonFS1)'
これらの宣言が指定されると、遠隔同期インスタンスbostonFS
はboston
からREDOを受け取り、boston
がプライマリ・データベースである場合のみchicago
にそれを送信します。ただし、boston
がプライマリ・データベースでない場合でも、将来のロールの推移に備えて、遠隔同期インスタンスbostonFS
とbostonFS1
をマウントしたままにすることをお薦めします。
5.4 遠隔同期インスタンスでサポートされる保護モード
遠隔同期インスタンスは、最大パフォーマンス・モードまたは最大可用性モードのいずれかでサポートされます。
5.4.1 最大可用性モード構成での遠隔同期インスタンス
最大可用性モードでは、遠隔同期インスタンスはネットワーク待機時間を最小化するために比較的プライマリ・データベースに近く、プライマリは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つのスタンバイ宛先しか存在しない場合でも、遠隔同期インスタンスが役に立つ例です。
5.4.2 最大パフォーマンス・モード構成での遠隔同期インスタンス
最大パフォーマンス・モードでは、プライマリ・データベースは、ASYNC
REDO転送を使用して遠隔同期インスタンスの宛先にサービスを提供します。
宛先がASYNC
転送でサービス提供されている場合は、ネットワーク待機時間が長くてもトランザクション・スループットに影響はないため、これには、プライマリと遠隔同期インスタンスとの間の物理的距離は関係ありません。
最大パフォーマンス・モードでは、遠隔同期インスタンスは複数のリモート宛先を管理するOracle Data Guard構成に役立ちます。各ASYNC
宛先のプライマリ・データベースのパフォーマンスに与える影響はほとんどゼロですが、多くのリモート宛先が存在する場合は(リーダー・ファームを形成する複数のOracle Active Data Guardスタンバイなど)、その影響が少なからず発生することがあります。遠隔同期インスタンスが使用される場合、リモート宛先が構成に追加されることで影響が増加することはありません。さらに、REDO転送圧縮も遠隔同期インスタンスへオフロードすることができます。遠隔同期インスタンスを使用する場合、プライマリは遠隔同期インスタンスにサービスを提供するだけで、その遠隔同期インスタンスが残りの構成にサービスを提供します。宛先の数が多くなるほど、パフォーマンスは大きく向上します。