遠隔同期インスタンスの使用

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 遠隔同期インスタンスの作成および構成

遠隔同期インスタンスを作成するには、次のステップを実行します。

次の例に示すように、遠隔同期インスタンス用の制御ファイルを作成します(プライマリ・データベースは開いている必要はありませんが、マウントはされている必要があります)。
```
SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS - 
> '/arch2/chicagoFS/control01.ctl';
```
作成された制御ファイルにより、chicagoFSはプライマリ・データベースchicagoからREDOを受信する遠隔同期インスタンスとして動作することができます。示されたパスとファイル名は1つの例であり、任意のパスやファイル名を使用できます。
プライマリ・データベースで使用されるサーバー・パラメータ・ファイル(SPFILE)からパラメータ・ファイル(PFILE)を作成します。パラメータ・ファイル内の初期化パラメータ設定の大部分は遠隔同期インスタンスにも適していますが、一部変更が必要なものがあります。たとえば、遠隔同期インスタンスでは、DB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERTパラメータを設定し、遠隔同期インスタンスのDB_UNIQUE_NAMEおよび遠隔同期インスタンスの制御ファイルの場所を変更する必要があります。例5-1に、chicagoFSのDB_UNIQUE_NAMEを使用した、遠隔同期インスタンスのパラメータ・ファイル・コンテンツの例を示します。
パラメータ値の次の変更を容易にするには、編集されたパラメータ・ファイル(PFILE)からサーバー・パラメータ・ファイル(SPFILE)を作成します。SPFILEを使用しないと、遠隔同期インスタンスがOracle Data Guard Broker構成に追加されたときに、SHOW CONFIGURATION出力で警告が返されます。
オペレーティング・システムのコピー・ユーティリティを使用して、ステップ1で作成した遠隔同期インスタンス制御ファイルと、ステップ3で作成したサーバー・パラメータ・ファイル(SPFILE)を、プライマリ・システムから遠隔同期インスタンスシステムの適切な場所にコピーします。
通常のスタンバイ用に作成したのと同じ方法で、スタンバイREDOログを作成します。「スタンバイREDOログの管理」を参照してください。

LOG_FILE_NAME_CONVERTパラメータが遠隔同期インスタンスに指定されているため(例5-1を参照)、REDOデータを受信するためのプライマリ・データベースの構成で説明しているようにREDOログがプライマリで作成された場合、REDO転送がプライマリから開始するときにスタンバイREDOログが自動的に作成されます。

ノート:

遠隔同期インスタンスで使用されるスタンバイREDOログ・ファイルは他のデータベースと共有できません。そのため、スタンバイREDOログ・ファイルに関して「スタンバイ・データベースのディレクトリ構造に関する考慮事項」で検討したすべての関連する考慮事項は、遠隔同期インスタンスにも適用されます。
遠隔同期インスタンスがWindowsシステムでホストされる場合、ORADIMユーティリティを使用してWindowsサービスを作成します。次に例を示します。
```
oradim –NEW –SID ChicagoFS –STARTMODE manual
```
遠隔同期インスタンスが作成されて実行されたら、STARTMODEをautoに変更し、遠隔同期インスタンスの自動起動を有効にすることができます。

ORADIMユーティリティは、このサービスを作成する必要のあるユーザー名を自動的に決定し、そのユーザー名のパスワードを求めます(そのユーザー名がパスワードを必要とする場合)。ORADIMユーティリティの使用の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。
このステップは、オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプションです。いずれの場合でもない場合は、プライマリ・データベースのリモート・ログイン・パスワード・ファイルを遠隔同期インスタンスの適切なディレクトリにコピーします。パスワード・ファイルは、管理権限(SYSDG、SYSOPER、SYSDBAなど)を付与または解除されるたびに、あるいは管理権限を持つユーザーのパスワード変更後、コピーし直す必要があります。

Oracle Database 12cリリース2 (12.2.0.1)以降、遠隔同期インスタンスでパスワード・ファイルが手動で更新されると、プライマリ・データベースからの同じパスワード変更内容を含むREDOが、遠隔同期インスタンスからREDOを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。
遠隔同期インスタンス・サイトで、Oracle Net Managerを使用して遠隔同期インスタンスのリスナーを構成します。

リスナーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
プライマリ・システムで、Oracle Net Managerを使用して、REDO転送サービスで使用される遠隔同期インスタンス(chicagoFS)用のネットワーク・サービス名を作成します。

遠隔同期インスタンス・システムで、Oracle Net Managerを使用して、REDO転送サービスで使用されるプライマリ(chicago)およびターミナル・スタンバイ(boston)用のネットワーク・サービス名を作成します。

Oracle Netネット・サービス名は、プライマリ・データベース、遠隔同期インスタンス、およびターミナル・スタンバイ・データベースに対するリスナーの構成時に指定したものと同じプロトコル、ホスト・アドレス、ポートおよびサービスを使用する接続記述子に解決される必要があります。この接続記述子は、専用サーバーが使用されるように指定する必要もあります。

サービス名の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
マウント・モードで遠隔同期インスタンスを開始します。
遠隔同期インスタンスが適切に動作していることを確認します。

遠隔同期インスタンスの作成後の構成の検証の詳細は、「構成の検証」を参照してください。
構成の保護モードを最大可用性に引き上げます。プライマリ・データベースで、次のコマンドを実行します。
```
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
```
関連項目:
- 遠隔同期および保護モードの詳細は、「遠隔同期インスタンスでサポートされる保護モード」を参照してください
- 各種データ保護モードの構成の詳細は、「Oracle Data Guardの保護モード」を参照してください

例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つの宛先のみがアクティブになるように優先順位付けできます。その他の宛先は、アクティブな宛先が使用不可になると使用可能でアクティブになります。使用しているデータベースの可能なアーカイブ先の数を拡張するには、複数のグループを指定できます。

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転送圧縮も遠隔同期インスタンスへオフロードすることができます。遠隔同期インスタンスを使用する場合、プライマリは遠隔同期インスタンスにサービスを提供するだけで、その遠隔同期インスタンスが残りの構成にサービスを提供します。宛先の数が多くなるほど、パフォーマンスは大きく向上します。