SharePlex 11.4 - 管理者ガイド

Oracleフェールオーバー後のレプリケーションのリカバリ

この章では、高可用性環境でのフェイルオーバーの際に、Oracleレプリケーションをデータベースおよびアプリケーションと共にリカバリする方法を説明します。これらの手順をサポートするには、高可用性をサポートするようにSharePlexを適切に設定する必要があります。「高可用性を維持するためのレプリケーションの設定」を参照してください。

内容

プライマリシステムに障害が発生した場合のレプリケーションのリカバリ

プライマリ（ソース）マシンに計画外の障害が発生した場合、そのシステム上のSharePlexキューに残っている複製データは、バッファリングの結果として、またキューが破損している可能性があるためリカバリ不可能となります。高可用性環境では、データの可用性を維持するために、データベースユーザと共にセカンダリ（ターゲット）マシンにレプリケーションを移動させることができます。プライマリシステムがリストアされると、セカンダリインスタンスのホットバックアップを使用して、最小限のダウンタイムでユーザとレプリケーションをそのシステムに戻すことができます。

この手順では、設定ファイルをアクティベーションし、reconcileコマンドを使用してコピーされたインスタンスをリカバリした後に、バックアップの結果と進行中の複製されたユーザの変更を同期させます。

サポート対象データベース

UnixまたはLinux上のOracleデータベース

要件

• 高可用性をサポートするためにSharePlexを正しく設定する必要があります。詳細については、高可用性を維持するためのレプリケーションの設定を参照してください。
• SharePlexのレプリケーション環境のバックアップが必要です。
• SharePlex実行方法がわかっていなければなりません。詳細については、SharePlexの実行を参照してください。
• activate config、reconcile、およびdelete queueコマンドを理解している必要があります。『SharePlexリファレンスガイド』を参照してください。

手順1: レプリケーションをセカンダリシステムに移動する

プライマリシステムに予期せぬ障害が発生した場合に、レプリケーションをセカンダリシステムに移行するには:

1. セカンダリシステムで、Exportが停止していることを確認します。

   sp_ctrl> stop export

2. postキューを表示するには、qstatusコマンドを使用し、バックログされたメッセージの数が0になるまで、このコマンドを発行し続けます。注意: 実際のメッセージの数が0になるまで待たないでください。一部のトランザクションのコミットを受信する前にプライマリシステムに障害が発生した場合、これらの部分的なトランザクションのメッセージは、この手順の後半でクリアされるまでキューに残ります。

   sp_ctrl> qstatus

3. セカンダリシステム上のすべてのユーザにINSERT、UPDATE、およびDELETEのアクセス権を付与するスクリプトを実行します。
4. ユーザがこのシステムの使用を開始するときにセカンダリシステムでトリガと制約を有効にするスクリプトを実行します。
5. アプリケーションの起動を含め、ユーザをセカンダリシステムに移転するためのフェイルオーバー手順を実装します。
6. セカンダリシステムにユーザを移動して作業を再開させますが、Exportは開始しないでください。これらのトランザクションは、ソースデータベースの復元を待つ間、exportキューに蓄積されます。

注意: Exportを開始すると、プライマリシステムへの接続が繰り返し試行され、システムリソースを浪費します。

7. 「手順2: 復元したプライマリシステムにレプリケーションを移動する」に進みます。

手順2: 復元したプライマリシステムにレプリケーションを移動する

この手順では、プライマリマシンが計画外の障害からリカバリした後、ユーザをプライマリマシンに戻します。提示された順序で各セグメントに従います。

プライマリシステムのレプリケーション環境のリストア

プライマリシステムのレプリケーション環境をリストアするには:

1. プライマリシステムで、バックアップとアーカイブからSharePlexのディレクトリ、システムファイル、Oracleファイルをリカバリします。

2. プライマリシステムで、-sオプションを使用してsp_copを起動し、SharePlexのプロセス（Capture、Read、Export、Import、Post）が起動しないようにします。

   $ /productdir/bin/sp_cop -s &

3. プライマリシステムでsp_ctrlを起動します。

4. プライマリシステムで設定ファイルを非アクティベーションします。アーカイブされたSharePlex変数データディレクトリをプライマリシステムにコピーしたときに、システムの障害発生前にアクティブだった設定をコピーしました。これにより、Captureプロセスは、プライマリシステムからのレプリケーション再開時にトランザクション番号を「1」に設定します。

   sp_ctrl> deactivate config filename

キューのパージ

キューをパージするには:

1. プライマリシステムとセカンダリシステムでsp_ctrlを実行します。

2. プライマリシステムでcaptureキューを削除します。

   sp_ctrl> delete capture queue for datasrc [on host]

   例: sp_ctrl> delete capture queue for o.oraA

3. プライマリシステムでexportキューを削除します。

   sp_ctrl> delete export queue quename [on host]

   例: sp_ctrl> delete export queue sysA

4. セカンダリシステムでpostキューを削除します。

   sp_ctrl> delete post queue quename for datasrc-datadst [cleartrans] [on host]

   例: sp_ctrl> delete post queue sysA for o.oraA-o.oraB

   メモ: プライマリシステムでdelete queueコマンドを発行しているのは、アーカイブされたSharePlexのディレクトリを復元する際に古いcaptureキューとexportキューを復元したためです。 セカンダリシステムでdelete queueコマンドを発行しているのは、postキューに残っているデータをポストできないためです。Postが残りのトランザクションのCOMMITを受け取る前に、プライマリシステムに障害が発生しました。設定を再アクティベーションして2つのシステムを照合すると、SharePlexはキューを再構築します。

セカンダリシステムからプライマリシステムへのレプリケーションの開始

セカンダリシステムからプライマリシステムへのレプリケーションを開始するには:

1. プライマリシステムで、SharePlexのすべてのプロセスがすべて停止していることを確認します。

   sp_ctrl> status

2. プライマリシステムでPostを停止します。

   sp_ctrl> stop post

3. セカンダリシステムでExportを開始します。これにより、プライマリシステムとセカンダリシステム間の通信が確立されます。

   sp_ctrl> start export

ソースデータとターゲットデータの同期

ソースデータとターゲットデータを同期させるには:

1. セカンダリシステムでOracleホットバックアップを実行します。

2. ホットバックアップが終了したら、セカンダリシステムでログファイルを切り替え、アーカイブログの最大のシーケンス番号を書き留めておきます。

3. プライマリシステムで、RECOVER句のUNTIL CANCELオプションを使用してバックアップからプライマリデータベースをリカバリし、記録した番号のログを完全に適用した後でリカバリをキャンセルします。

4. RESETLOGSオプションを使用してデータベースを開きます。

   注意: この結果、起動時にプライマリシステムのシーケンスがキャッシュの先頭にリセットされます。

5. プライマリシステムで、前に書き留めたログのシーケンス番号を使用してreconcileコマンドを実行します。名前付きpostキューを使用している場合は、それぞれについてコマンドを実行します。キュー名がわからない場合は、最初にqstatusコマンドを実行します。

   sp_ctrl> qstatus

   sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number

   例: reconcile queue SysB for o.oraA-o.oraA seq 1234

6. プライマリシステムで、テーブルのトリガを無効にするかsp_add_trigger.sqlユーティリティスクリプトを実行して、トリガがSharePlexユーザを無視するようにします。
7. プライマリシステムで、チェック制約、およびDMLを実行するスケジュール済みジョブを無効にします。
8. プライマリシステムで、SharePlexOracleユーザとしてSQL*Plusにログオンし、SharePlexの製品ディレクトリのbinサブディレクトリからcleanup.sqlユーティリティを実行します。これによりSharePlexのテーブルがトランケートされ、SHAREPLEX_ACTIDテーブルが更新されます。
9. セカンダリシステムで、SHAREPLEX_TRANSテーブルをトランケートします。このテーブルには、プライマリシステムに障害が発生する前にPostプロセスが使用していたトランザクション情報が含まれています。テーブルをトランケートすると、2つのシステム間でトランザクションの一貫性が回復します。

プライマリシステムでのレプリケーションのアクティベーション

プライマリシステムでレプリケーションをアクティベーションするには:

1. プライマリシステムで設定ファイルをアクティベーションします。

   sp_ctrl> activate config filename

2. プライマリシステムでPostを開始します。

   sp_ctrl> start post

オブジェクトキャッシュの復元

オブジェクトキャッシュを復元するには:

1. プライマリシステムでSharePlexのプロセスのステータスを表示します。

   sp_ctrl> status

   注意: このコマンドは、オブジェクトキャッシュがないために発生したエラーによりPostが停止したことを示します。

2. プライマリシステムで、filterオプションを使用してshow logコマンドを発行し、キーワード「objcache」でフィルタリングします。

   sp_ctrl> show log filter=objcache

3. 以下の例に類似した名前を持つファイルを参照するPostエラーメッセージを探します。

   0x0a0100c5+PP+sys4+sp_opst_mt+o.quest-o.ov-objcache_sp_opst_mt.18

   「objcache_sp_opst_mt」という文字列の後に数字が続く文字列を探しています。これは、Postプロセスが必要とするオブジェクトキャッシュファイルです。名前付きpostキューを使用している場合、それぞれが異なるオブジェクトキャッシュファイルを参照しているが同じ番号で終わる（例では「.18」）複数のエラーメッセージが表示されます。

4. エラーメッセージに記載されているPostオブジェクトキャッシュファイルのフルパス名を書き留めます。パスは、以下のようにSharePlexの変数データディレクトリ内のstateディレクトリになります。

   splex_vardir/state/0x0a0100c5+PP+sys4+sp_opst_mt+o.quest-o.ov-objcache_sp_opst_mt.18

5. セカンダリシステムでSharePlexをシャットダウンします。

   sp_ctrl> shutdown

6. セカンダリシステムで、SharePlexの変数データディレクトリのstateサブディレクトリにディレクトリを変更し、Captureオブジェクトキャッシュファイルを探します。このファイルは以下の例のような名前になります。

   o.quest-objcache_sp_ocap.18

   重要!: これらのファイルが複数ある場合は、その末尾に最新の番号が付いたものを使用してください。この番号は、例の.18のように、Postオブジェクトキャッシュファイルの末尾の番号と一致している必要があります。

7. Captureオブジェクトキャッシュファイルをプライマリシステムにコピーし、前述のPostオブジェクトキャッシュファイルのフルパス名に変更します。

8. プライマリシステムでPostを開始します。

   sp_ctrl> start post

ユーザをプライマリシステムに戻す

ユーザをプライマリシステムに戻すには:

1. セカンダリシステムで、データベースへのユーザアクセスを停止します。

2. プライマリシステムで、postキューを表示し、メッセージ数が0になるまでコマンドを発行し続けます。

   sp_ctrl> qstatus

3. セカンダリシステムでOracleインスタンスをシャットダウンします。

   svrmgr1> shutdown

4. セカンダリシステムでOracleインスタンスを起動します。

   svrmgr1> startup

   注意: この結果、セカンダリシステムのシーケンスがキャッシュの先頭にリセットされ、プライマリシステムと同期されます。

5. プライマリシステムで、無効になっていたデータベースオブジェクトを有効にします。
6. セカンダリシステムでSharePlexを起動します。

7. セカンダリシステムでPostを停止します。

   sp_ctrl> stop post

8. セカンダリシステムで、テーブルのトリガを無効にするかsp_add_trigger.sqlユーティリティスクリプトを実行して、トリガがSharePlexユーザを無視するようにします。
9. セカンダリシステムで、チェック制約、およびDMLを実行するスケジュール済みジョブを無効にします。

10. セカンダリシステムでPostを開始します。

    sp_ctrl> start post

11. プライマリシステムで、postキューのメッセージ数を表示し、メッセージ数が0になるまでチェックし続けます。

    sp_ctrl> qstatus

12. メッセージ数が0になったら、ユーザをプライマリシステムに戻します。

13. セカンダリシステムで行われた偶発的な変更がプライマリシステムに複製されるのを防ぐため、セカンダリシステムでExportを停止します。

    sp_ctrl> stop export

セカンダリOracleインスタンスに障害が発生した場合のレプリケーションのリカバリ

セカンダリ（ターゲット）Oracleインスタンスで予期しない障害が発生した場合、そのシステムからプライマリシステムへのレプリケーション環境が破損します。この手順により、プライマリシステムのデータベースユーザに影響を与えることなく、またプライマリシステムの設定ファイルを再度アクティベーションすることなく、レプリケーション設定を復元することができます。影響を受けるのはセカンダリ設定のみです。

この手順では、SharePlexのキューを一掃し、ソースシステムからのホットバックアップによってターゲットインスタンスを復元します。reconcileコマンドを使用して、コピーされたインスタンスをリカバリした後に、バックアップの結果と進行中の複製されたユーザの変更を同期します。

サポート対象データベース

UnixまたはLinux上のOracleデータベース

要件

• 高可用性をサポートするためにSharePlexを正しく設定する必要があります。詳細については、高可用性を維持するためのレプリケーションの設定を参照してください。
• SharePlex実行方法がわかっていなければなりません。詳細については、SharePlexの実行を参照してください。
• activate config、reconcile、およびdelete queueコマンドを理解している必要があります。『SharePlexリファレンスガイド』を参照してください。
• この手順は、セカンダリシステム自体が稼働しており、システム上のSharePlexとやり取りできることを前提としています。

手順

この手順は論理的なセグメントに分かれています。提示された順番に従ってください。

キューのパージ

キューをパージするには:

1. セカンダリシステムでPostを停止します。

   sp_ctrl> stop post

2. セカンダリシステムで設定ファイルを非アクティベーションします。

   sp_ctrl> deactivate config filename

   注意: 非アクティベーションにより、イベントログにエラー「Error in sp_cnc.（sp_cncのエラー）」が表示されます。無視して手続きを続けることもできます。

3. プライマリシステムでsp_ctrlを実行します。

4. プライマリシステムでpostキューを削除します。

   sp_ctrl> delete post queue quename for datasrc-datadst [cleartrans] [on host]

   例: sp_ctrl> delete queue sysB:P for o.oraA-o.oraB

   注意: プライマリシステムのキューを削除しているのは、セカンダリインスタンスで障害が発生する前にセカンダリインスタンスから送信されたコミットされていないトランザクションのメッセージが残っている可能性があるためです。

5. プライマリシステムで、SharePlexスキーマのSHAREPLEX_TRANSの内部テーブルをトランケートします。このテーブルには、セカンダリインスタンスに障害が発生する前にそのシステムのPostプロセスが使用していたトランザクション情報が含まれているため、その情報は古いものとなっています。テーブルをトランケートすると、トランザクションの一貫性が回復します。
6. セカンダリシステムでsp_ctrlを実行します。

7. セカンダリシステムでcaptureキューを削除します。

   sp_ctrl> delete capture queue for datasrc [on host]

   例: sp_ctrl> delete queue o.oraB:C

8. セカンダリシステムでexportキューを削除します。

   sp_ctrl> delete export queue quename [on host]

   例: sp_ctrl> delete queue sysB:X

   注意: セカンダリシステム上のキューを削除するのは、そのシステム上のcaptureキューとexportキューが、既に処理されたトランザクションの記録をまだ保持しているためです。

データの同期

データを同期させるには:

1. プライマリシステムで、プライマリOracleインスタンスのホットバックアップを開始します。

2. プライマリシステムでログファイルを切り替えます。

   オンプレミスのデータベース:

   svrmgr1> alter system switch logfile;

   Amazon RDSデータベース:

   Amazon RDSプロシージャrdsadmin.rdsadmin_util.switch_logfileを使用します。

3. アーカイブログの最も大きいシーケンス番号を書き留めておきます。
4. セカンダリシステムで、RECOVER句でUNTIL CANCELオプションを使用し、ホットバックアップからセカンダリデータベースをリカバリします。Oracleが前のステップのログを完全に適用した後、リカバリをキャンセルします。
5. セカンダリシステムで、RESETLOGSオプションを指定してセカンダリデータベースを開きます。この結果、起動時にセカンダリシステムのシーケンスがキャッシュの先頭にリセットされます。
6. セカンダリシステムで、SharePlexのデータベースユーザとしてSQL*Plusを実行します。

7. SQL*Plusで、SharePlexの製品ディレクトリのbinサブディレクトリからcleanup.sqlスクリプトを実行します。

8. セカンダリシステムで、前に書き留めたログのシーケンス番号を使用してreconcileコマンドを実行します。名前付きpostキューを使用している場合は、それぞれについてコマンドを実行します。キュー名がわからない場合は、最初にqstatusコマンドを実行します。

   sp_ctrl> qstatus

   sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number

   例: reconcile queue SysA for o.oraA-o.oraA seq 1234

9. セカンダリシステムで、テーブルのトリガを無効にするかsp_add_trigger.sqlユーティリティスクリプトを実行して、トリガがSharePlexユーザを無視するようにします。
10. セカンダリシステムで、チェック制約、およびDMLを実行するスケジュール済みジョブを無効にします。

11. セカンダリシステムで、sp_ctrlプロンプトが戻った後にExport を停止します。これにより、セカンダリシステムで設定をアクティベーションする際に、誤ってプライマリシステムに複製されなくなります。

    sp_ctrl> stop export

セカンダリシステムでのレプリケーションの開始

セカンダリシステムでレプリケーションを開始するには:

1. セカンダリシステムで設定ファイルをアクティベーションします。

   sp_ctrl> activate config filename

2. セカンダリシステムでPostを開始します。

   sp_ctrl> start post

3. statusコマンドを使用して、SharePlexの他のプロセスのステータスがStopped due to Error（エラーにより停止）であるかどうかを確認し、これらを開始します。

   sp_ctrl> status

   sp_ctrl> start process

注意: これで、セカンダリシステムは将来のフェイルオーバーに備えることができます。

計画されたフェールオーバーとフェールバック時のレプリケーションの移動

計画されたフェイルオーバーとフェールバック時のレプリケーションの移動

セカンダリOracleインスタンスへのデータベースアクティビティの計画的なフェイルオーバーでは、SharePlexをセカンダリシステムに迅速に移動できます。ユーザがそのシステムでトランザクションを続けている間、プライマリシステムがオンラインに戻り、アクティビティがそのシステムに戻されるまで、SharePlexはユーザの変更をキャプチャして保存します。

サポート対象データベース

UnixまたはLinux上のOracleデータベース

要件

• 高可用性をサポートするためにSharePlexを正しく設定する必要があります。詳細については、高可用性を維持するためのレプリケーションの設定を参照してください。
• セカンダリシステムのキューが存在する場所には、ユーザがそのシステムで作業している間に蓄積されるデータを格納するのに十分なディスク容量がなければなりません。
• SharePlex実行方法がわかっていなければなりません。詳細については、SharePlexの実行を参照してください。
• SharePlexのflushコマンドを理解する必要があります詳細については、『SharePlexリファレンスガイド』を参照してください。

手順

この手順は論理的なセグメントに分かれています。提示された順番に従ってください。手順でプロンプトが表示されるまで、プライマリインスタンスをシャットダウンしないでください。

セカンダリシステムへのユーザの切り替え

セカンダリシステムにユーザを切り替えるには:

1. プライマリシステムで、プライマリインスタンスへのユーザアクセスを停止します。

2. プライマリシステムで、キュー内のデータをセカンダリシステムにフラッシュします。このコマンドは、セカンダリシステムのPostを停止し、プライマリデータとセカンダリデータの同期ポイントを確立するためにデータストリームにマーカーを置きます。

   sp_ctrl> flush datasource

   ここで、datasourceは、プライマリOracleインスタンスのデータソースの指定です（o.OraAなど）。

3. セカンダリシステムで、Postが停止したことを確認します（Postが停止したと表示されるまで、このコマンドを発行し続ける）。

   sp_ctrl> status

4. プライマリシステムで、captureキューとexportキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。

   sp_ctrl> qstatus

5. セカンダリシステムで、postキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。

   sp_ctrl> qstatus

6. プライマリシステムでSharePlexをシャットダウンします。

7. プライマリシステムで、abortオプションを使用してOracleインスタンスをシャットダウンします。immediateオプションは使用しないでください。

   svrmgr1> shutdown abort

   注意: これにより、データベース起動時にプライマリシステムのシーケンスがキャッシュの先頭にリセットされます。

8. セカンダリシステムで、Exportが停止していることを確認します。これにより、プライマリシステムがオンラインに復帰し、SharePlexで変更を受け取る準備が整うまで、ユーザの変更がプライマリシステムに複製されなくなります。必要に応じてExportを停止します。

   sp_ctrl> status

   sp_ctrl> stop export

9. セカンダリシステムで、すべてのユーザにINSERT、UPDATE、およびDELETEのアクセス権を付与するスクリプトを実行します。
10. セカンダリシステムで、セカンダリインスタンスのトリガと制約を有効にするスクリプトを実行します。
11. プライマリシステムで実行されていたアプリケーションの起動やジョブの開始など、ユーザをセカンダリシステムに移動するためのフェイルオーバー手順を実行します。
12. セカンダリシステムにユーザを移動して作業を再開させますが、Exportプロセスは開始しないでください。

ユーザをプライマリシステムに戻す

ユーザをプライマリシステムに戻すには:

1. プライマリシステムでOracleインスタンスを開きます。これで、このシステムのシーケンスがキャッシュの先頭に来るはずです。
2. プライマリシステムで、テーブルのトリガを無効にするかsp_add_trigger.sqlユーティリティスクリプトを実行して、トリガがSharePlexユーザを無視するようにします。
3. プライマリシステムで、チェック制約、およびDMLを実行するスケジュール済みジョブを無効にします。
4. プライマリシステムでSharePlexを起動します。

5. セカンダリシステムでExportを開始し、蓄積された複製済みのデータをSharePlexがプライマリシステムに送信するようにします。

   sp_ctrl> start export

   注意: Exportの開始時に、SharePlexはセカンダリシステムからプライマリシステムにすべてのシーケンスの更新を戻します。

6. プライマリシステムでExportを停止します。

   sp_ctrl> stop export

7. プライマリシステムで、プライマリシステムから送信されたメッセージのバックログをPostで処理できるようにします。

8. セカンダリシステムで、Oracleインスタンスへのユーザアクセスを停止します。

9. セカンダリシステムで、キューのデータをプライマリシステムにフラッシュします。

   sp_ctrl> flush datasource

   ここで、datasourceは、セカンダリOracleインスタンスのデータソース指定です（o.OraBなど）。

10. プライマリシステムで、Postが停止したことを確認します（Postが停止したと表示されるまで、このコマンドを発行し続ける）。

    sp_ctrl> status

11. セカンダリシステムで、captureキューとexportキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。

    sp_ctrl> qstatus

12. プライマリシステムで、postキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。

    sp_ctrl> qstatus

13. セカンダリシステムでSharePlexをシャットダウンします。

    sp_ctrl> shutdown

14. セカンダリシステムで、abortオプションを使用してOracleインスタンスをシャットダウンします。immediateオプションは使用しないでください。

    svrmgr1> shutdown abort

    注意: これにより、データベース起動時にセカンダリシステムのシーケンスがキャッシュの先頭にリセットされます。

15. セカンダリシステムでOracleインスタンスを起動します。

    svrmgr1> startup

    注意: これで、セカンダリシステムのシーケンスがキャッシュの先頭になりました。プライマリシステムで次の値が選択されると、新しいキャッシュが取得され、セカンダリシステムに複製されます。これで、プライマリシステムがキャッシュの先頭に、セカンダリシステムがキャッシュの最上部になりました。

16. プライマリシステムで、すべてのユーザにINSERT、UPDATE、DELETEのアクセス権を付与するスクリプトを実行します。
17. プライマリシステムで、ユーザがプライマリシステムの使用を開始するときに、プライマリシステムのトリガと制約を有効にするスクリプトを実行します。
18. セカンダリシステムで実行されていたアプリケーションの起動やジョブの開始など、ユーザをプライマリシステムに戻すためのフェイルオーバー手順を実行します。
19. ユーザをプライマリシステムに切り替えて作業を再開しますが、Exportプロセスは開始しないでください。これにより、SharePlexで受け取りの準備が整うまで、複製されたデータがセカンダリシステムに送信されなくなります。

セカンダリインスタンスを維持するためのレプリケーションの再開

セカンダリインスタンスを維持するためにレプリケーションを再開するには:

1. セカンダリシステムで、テーブルのトリガを無効にするかsp_add_trigger.sqlユーティリティスクリプトを実行して、トリガがSharePlexユーザを無視するようにします。
2. セカンダリシステムで、チェック制約、およびDMLを実行するスケジュール済みジョブを無効にします。
3. セカンダリシステムでSharePlexを起動します。

4. セカンダリシステムでExportを停止します。これにより、そのシステムで誤ってDMLを実行した場合、プライマリシステムに複製されるのを防ぐことができます。

   sp_ctrl> stop export

5. プライマリシステムでExportを開始します。

   sp_ctrl> start export

6. セカンダリシステムでPostを開始します。

   sp_ctrl> start post

   プライマリインスタンスからセカンダリインスタンスへのレプリケーションがアクティブになり、2つのデータベースの同期が維持されて、必要に応じた将来のフェイルオーバーに対応できるようになりました。