Chat now with support
Chat with Support

SharePlex 8.6.6 - 管理ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex の概要 SharePlex の実行 複数の SharePlex インスタンスの実行 sp_ctrl でのコマンドの実行 SharePlex パラメータ 複製のための Oracle 環境の準備 設定ファイルの作成 オープンターゲットのターゲットへの複製の設定 複製方法の設定 分割レプリケーションの設定 名前付きキューの設定 変更履歴ターゲットを維持するための SharePlex の設定 Oracle DDL の複製 エラー処理のセットアップ データの変換 SharePlex セキュリティ機能の設定 実稼動環境での複製のアクティベート SharePlex の監視 複製上の問題の防止および解決方法 非同期データの修復 Oracle の高可用性を維持するための手順 アクティブな複製環境の変更 Oracle アプリケーションのパッチまたはアップグレードの適用 ソースまたはターゲット上の Oracle データのバックアップ Capture プロセスのチューニング Post プロセスのチューニング 付録 A:ピアトゥピアの説明図 付録 B:SharePlex 環境変数

Oracle の高可用性を維持するための手順

高可用性を維持するための手順

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

コンテンツ

プライマリシステムに障害が発生した場合の複製の復旧

Oracle の高可用性を維持するための手順 > プライマリシステムに障害が発生した場合の複製の復旧

「プライマリ」(ソース)マシンに障害が発生した場合、SharePlex キューに残っている複製されたデータは、バッファ上の問題やキューが破損している可能性があることから、回復不可能となります。高可用性環境では、複製をデータベースユーザーとともにセカンダリ(ターゲット)マシンに移動して、データの可用性を維持することができます。プライマリシステムが回復されたら、セカンダリインスタンスのホットバックアップを使用して、最小限のダウンタイムでユーザーおよび複製を元のプライマリシステムに移動することができます。

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

サポートされるデータベース

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

必要条件

  • 高可用性をサポートするように SharePlex が適切に設定されている必要があります。「高可用性を維持するための複製の設定」を参照してください。
  • SharePlex 複製環境のバックアップを作成している必要があります。
  • SharePlex の実行方法を理解している必要があります。「SharePlex の実行」を参照してください。
  • activate configreconcile、および delete queue コマンドを理解している必要があります。『 SharePlex リファレンスガイド』を参照してください。

手順 1:複製をセカンダリシステムに移動する

この手順では、プライマリシステムに予期せずに障害が発生した後に複製をセカンダリシステムに移動します。

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

    sp_ctrl> stop export

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

    sp_ctrl> qstatus

  3. INSERT、UPDATE、DELETE のアクセスをセカンダリシステムのすべてのユーザーに許可するスクリプトを実行します。
  4. ユーザーがセカンダリシステムを使い始めるときにトリガと制約をこのシステムで有効にするスクリプトを実行します。
  5. アプリケーションの起動など、ユーザーをセカンダリシステムに移動するフェイルオーバー手順を実装します。
  6. セカンダリシステムにユーザーを移動し、ユーザーが仕事を再開できるようにします。ただし、Export は開始しないでください。この時点より、ユーザーのトランザクションは export queue に蓄積され、ソースデータベースの回復待ちの状態となります。注:もし開始された場合、Export が繰り返しプライマリシステムに接続しようとし、システムリソースの無駄になります。
  7. 手順 2:回復されたプライマリシステムに複製を移動する」に進みます。

手順 2:回復されたプライマリシステムに複製を移動する

この手順では、予期せずに発生した障害からプライマリマシンが復旧された後に、ユーザーを元のプライマリマシンに移動します。ここに示されている順序に従って各セグメントを実行してください。

プライマリシステムでの複製環境の回復

  1. プライマリシステムで、バックアップとアーカイブから SharePlex ディレクトリ、システムファイル、Oracle ファイルを復旧します。
  2. プライマリシステムで、sp_cop-s オプション付きで開始して、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 queue datasource:C

    例:sp_ctrl> delete queue o.oraA:C

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

    sp_ctrl> delete queue queuename:X

    例:sp_ctrl> delete queue sysA:X

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

    sp_ctrl> delete queue queuename:P for datasource-datadest

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

    注:

    • プライマリシステムで delete queue コマンドを発行するのは、アーカイブされた SharePlex ディレクトリを回復したことで、古い capture キューと export キューが回復されたためです。
    • また、セカンダリシステムで delete queue コマンドを発行するのは、post キューに残っているデータを post できないからです。プライマリシステムの障害は、Post が残りのトランザクションに対する COMMIT を受信する前に発生しています。設定を再アクティベートし、2 つのシステムが reconcile されると、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 コマンドを発行します。named post queues を使用している場合、各キューに対してコマンドを発行します。キューの名前が分からない場合は、最初に 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. プライマリシステムで、SharePlex Oracle ユーザーとして 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 オプションにキーワード「objcache」を指定した show log コマンドを発行します。

    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 プロセスが必要な object-cache ファイルです。named post queues を使用している場合は、複数のエラーメッセージがあり、それぞれ異なる object-cache ファイルを参照し、同一の番号で終わります(下記の例では「.18」)。

  4. エラーメッセージに示されている Post object-cache ファイルの完全なパス名を記録します。パスは、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 object-cache ファイルを見つけます。このファイルは、次の例にある名前と同じような名前を持ちます。

    o.quest-objcache_sp_ocap.18

    重要! もし、これらのファイルが複数ある場合は、ファイル名末端の番号が一番最近のものを使用します。この番号は、Post object-cache ファイルの末端に該当します(例: 「.18」)。

  7. Capture object-cache ファイルをプライマリシステムにコピーし、前の手順で記録した Post object-cache ファイルの完全なパス名に名前を変更します。
  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

注: これで、以下の状態になり、セカンダリシステムをフェイルオーバーする準備ができました。

  • ユーザーがいない
  • アクティブ設定
  • トリガ、制約、およびスケジュールされたジョブが無効になっているか変更されている
  • Export プロセスが停止している

セカンダリ Oracle インスタンスに障害が発生した場合の複製の復旧

Oracle の高可用性を維持するための手順 > セカンダリ Oracle インスタンスに障害が発生した場合の複製の復旧

セカンダリ(ターゲット)Oracle インスタンスで予期せずに障害が発生した場合、そのシステムからプライマリシステムへの複製環境は破損しています。この手順を実行すると、プライマリシステムのデータベースユーザーに影響を与えることなく、およびプライマリシステム上で設定ファイル再アクティベートする必要なく、複製設定を復元できます。影響を受けるのはセカンダリ設定のみです。

この手順では、SharePlex キューを空にし、ソースシステムのホットバックアップを使用してターゲットインスタンスを復元します。ここでは、コピーされたインスタンスが復旧された後、reconcile コマンドを使用してバックアップの結果を現行の複製されたユーザー変更と同期させます。

サポートされるデータベース

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

必要条件

  • 高可用性をサポートするように SharePlex が適切に設定されている必要があります。「高可用性を維持するための複製の設定」を参照してください。
  • SharePlex の実行方法を理解している必要があります。「SharePlex の実行」を参照してください。
  • activate configreconcile、および delete queue コマンドを理解している必要があります。『 SharePlex リファレンスガイド』を参照してください。
  • この手順では、セカンダリシステム自体が動作していて、このシステム上の SharePlex と対話できることを想定しています。

手順

この手順は、いくつかの論理セグメントに分けられます。ここに示されている順序に従ってください。

キューの消去

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

    sp_ctrl> stop post

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

    sp_ctrl> deactivate config filename

    注: ディアクティベートすると、エラー「Error in sp_cnc」がイベントログに記録されます。これは、無視して手順を続けてください。

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

    sp_ctrl> delete queue queuename:P for datasource-datadest

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

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

  5. プライマリシステムで、SharePlex スキーマの SHAREPLEX_TRANS 内部テーブルを切り捨てます。このテーブルには、セカンダリシステムが障害を起こす前に Post プロセスによって使用されていたトランザクション情報が含まれています。したがってこの情報は陳腐です。テーブルを切り詰めることで、トランザクションの一貫性を回復することができます。
  6. セカンダリシステムで、sp_ctrl を実行します。
  7. セカンダリシステムで、capture キューを削除します。

    sp_ctrl> delete queue datasource:C

    例:sp_ctrl> delete queue o.oraB:C

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

    sp_ctrl> delete queue queuename:X

    例:sp_ctrl> delete queue sysB:X

    注: セカンダリシステムでキューを削除するのは、このシステムの capture キューと export キューにすでに処理が完了しているトランザクションの記録が保持されている可能性があるからです。

データの同期化

  1. プライマリシステムで、プライマリ Oracle インスタンスのホットバックアップを開始します。
  2. プライマリシステムで、ログファイルを切り替えます。

    svrmgr1> alter system switch logfile;

  3. アーカイブログの最大シーケンス番号を書き留めておきます。
  4. セカンダリシステムで、RECOVER 句の UNTIL CANCEL オプションを使用してホットバックアップからセカンダリデータベースを復旧します。Oracle によって前の手順のログが完全に適用されたら、復旧をキャンセルします。
  5. セカンダリシステムで、RESETLOGS オプションでセカンダリデータベースを開きます。これにより、起動時にセカンダリシステムのシーケンスがキャッシュの最高位にリセットされます。
  6. セカンダリシステムで、SQL*Plus を SharePlex データベースユーザーとして実行します。
  7. SQL*Plus で、SharePlex 製品ディレクトリの bin サブディレクトリから cleanup.sql スクリプトを実行します。

  8. セカンダリシステムで、前の手順で記録したログのシーケンス番号を使用して reconcile コマンドを発行します。named post queues を使用している場合、各キューに対してコマンドを発行します。キューの名前が分からない場合は、最初に 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 コマンドを使用して「Stopped due to Error」ステータスである他の SharePlex プロセスがあるかどうかを確認した後、それらのプロセスを起動します。

    sp_ctrl> status

    sp_ctrl> start process

注: これで、将来のフェイルオーバーに対するセカンダリシステムの準備が完了しました。

計画的フェイルオーバーおよびフェイルバック時の複製の移動

Oracle の高可用性を維持するための手順 > 計画的フェイルオーバーおよびフェイルバック時の複製の移動

セカンダリ 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. セカンダリシステムで、SharePlex が蓄積された複製されたデータをプライマリシステムに送信するように、Export を起動します。

    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 つのデータベースが同期されます。これで、将来フェイルオーバーが必要となる場合のための準備が完了しました。

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating