>> はじめに

前回は大量のトランザクション発生時の動作を確認しましたが、今回は、同じくガイドに従った続きとして、「ターゲットが利用できない時の動作」について確認していきましょう。

>> 現在の状況を確認して、ターゲットをシャットダウンしてみるとどうなるか?

最初に、sp_ctrlコマンドのコンソールから、ソースとターゲットのそれぞれのマシン上でstatusを確認しておきます。

ソース側では、capture, read, export等のプロセスが上がっているのが確認できます。


sp_ctrl (rhel5sposrc1:2100)> status Brief Status for rhel5sposrc1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 3873 26-Jun-12 17:25:57 Capture Running 3874 26-Jun-12 17:25:57 Export Running 3876 26-Jun-12 17:25:57 Read Running 3875 26-Jun-12 17:25:57 Cmd & Ctrl Running 4770 26-Jun-12 17:47:00 System is used as a source machine There is 1 active configuration file

ターゲット側では、それをimportしてpostにより処理するプロセスが確認できます。


sp_ctrl (rhel5spotrg1:2100)> status Brief Status for rhel5spotrg1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 3845 26-Jun-12 17:25:50 Import Running 3867 26-Jun-12 17:25:58 MTPost Running 3846 26-Jun-12 17:25:50 Cmd & Ctrl Running 4682 26-Jun-12 17:46:24 There are no active configuration files

この状態で、ターゲットをshutdownコマンドによりシャットダウンします。
シャットダウンすると、sp_copの親プロセス自体が起動していない状態になりますので、SharePlexのstatus等による確認もできない状態になります。


sp_ctrl (rhel5spotrg1:2100)> shutdown

ターゲット側がシャットダウンしている状態で、ソース側から前回作成したdemo.sqlのスクリプトを実行します。スクリプトの詳細については、前回の講座を参考にするようにしてください。


[oracle@rhel5sposrc1 ~]$ sqlplus SPLEX/SPLEX SQL> @demo.sql PL/SQLプロシージャが正常に完了しました。

この状態で、ソース側のstatusを確認すると、captureやreadといった、変更内容をキューに格納するプロセスは動作していますが、ターゲット側にキューを転送する役割を持つexportがidleとなって停止していることが確認できます。


sp_ctrl (rhel5sposrc1:2100)> status Brief Status for rhel5sposrc1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 3873 26-Jun-12 17:25:57 Capture Running 3874 26-Jun-12 17:25:57 Export Idle Read Running 3875 26-Jun-12 17:25:57 Cmd & Ctrl Running 4862 26-Jun-12 17:49:21 System is used as a source machine There is 1 active configuration file

sp_ctrlのコンソールから、キューの状態を確認するqstatusコマンドを実行すると、demo.sqlによって生成されたトランザクションがキューとなって格納されている状態が確認できます。

messagesという数が実際のトランザクションの数よりも大幅に少ないのは、SharePlexは同じようなトランザクションが連続した場合に、それを1件づつmessagesとして処理するのではなく、効率よく処理ができるようにまとめる機能があるためです。


sp_ctrl (rhel5sposrc1:2100)> qstatus Queues Statistics for rhel5sposrc1 Name: rhel5sposrc1 (Export queue) Number of messages: 4016 (Age 0 min; Size 69 mb) Backlog (messages): 4016 (Age 0 min) Name: o.src1 (Capture queue) Number of messages: 0 (Age 0 min; Size 0 mb) Backlog (messages): 0 (Age 0 min)

ソース側のdemo_srcのテーブルの件数を確認すると、前回の講座で100001になった件数がさらに10万件増えていることが確認できます。


[oracle@rhel5sposrc1 ~]$ sqlplus SPLEX/SPLEX SQL> select count(*) from demo_src; COUNT(*) ---------- 200001

しかし、SharePlexがシャットダウンされているターゲット側の件数を確認すると、未だに10万件程度なことがわかります。


[oracle@rhel5spotrg1 ~]$ sqlplus SPLEX/SPLEX SQL> select count(*) from demo_dest; COUNT(*) ---------- 100001

 

>> ターゲットでsp_copを起動して、処理を再開させてみよう

差分の更新内容は、ターゲット側のsp_copが起動していない状態では、ソース側のキュー用ディスクに格納されています。そこで、ターゲット側でsp_copを再起動して、動作の継続を確認してみましょう。

sp_copの起動方法は、インストール後にSharePlexを起動した際とまったく同じになります。


[splex@rhel5spotrg1 ~]$ cd $SP_BIN [splex@rhel5spotrg1 bin]$ ./sp_cop & [1] 4851 [splex@rhel5spotrg1 bin]$ ******************************************************* * SharePlex for Oracle Startup * ゥ 2010 Quest Software, Inc. * ALL RIGHTS RESERVED. * Protected by U.S. Patents: 7,461,103 and 7,065,538 * Version: 7.6.2.59-m64-oracle110 * VarDir : /home/splex/vardir * Port : 2100 *******************************************************

再度、statusを確認すると、キューを受け取るべきimportがソース側のexportと通信をして、受け取れる状態になるまで、少し時間がかかることもあります。そのような状態ではimportだけidleになっていますが少し待ってみてください。


sp_ctrl (rhel5spotrg1:2100)> status Brief Status for rhel5spotrg1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 4851 26-Jun-12 17:54:55 Import Idle MTPost Running 4852 26-Jun-12 17:54:55 Cmd & Ctrl Running 4876 26-Jun-12 17:55:01 There are no active configuration files

ソース側とターゲット側が正しく通信ができる準備が整ったら、すべてstateがrunningの状態になります。以下はターゲット側の状態ですが、ソース側も準備が整っていますので確認してみてください。


sp_ctrl (rhel5spotrg1:2100)> status Brief Status for rhel5spotrg1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 4851 26-Jun-12 17:54:55 Import Running 4915 26-Jun-12 17:59:33 MTPost Running 4852 26-Jun-12 17:54:55 Cmd & Ctrl Running 4876 26-Jun-12 17:55:01 There are no active configuration files

再度qstatusで状況を確認するとNumber of messagesの件数が減っていることが確認できます (もしくは、状況によっては減っている最中かもしれません)。


sp_ctrl (rhel5sposrc1:2100)> qstatus Queues Statistics for rhel5sposrc1 Name: rhel5sposrc1 (Export queue) Number of messages: 0 (Age 0 min; Size 32 mb) Backlog (messages): 0 (Age 0 min) Name: o.src1 (Capture queue) Number of messages: 0 (Age 0 min; Size 3 mb) Backlog (messages): 0 (Age 0 min)

最終的にターゲット側のdemo_destテーブルには、ソース側で発生したトランザクションの内容がすべて反映されていることが確認できるはずです。


[splex@rhel5spotrg1 ~]$ sqlplus SPLEX/SPLEX SQL> select count(*) from demo_dest; COUNT(*) ---------- 200001

 

>> まとめ

これで、sp_copのプロセス自体がシャットダウンされても、再起動ができればキューの処理が正しく継続されることが確認できました。

次回も更にテストを継続し、SharePlexの動作を確認していきます。