>> はじめに

前回までは、主に複製の機能自体に関する確認をしてきました。SharePlexを使用していて、動作上問題なければそのまま運用を継続することが可能ですが、ソース側とターゲット側でテーブルの内容が同期していない状態になると、様々な問題を引き起こす可能性があります。

SharePlex自体は、そのような非同期状態が発生しないように、様々な仕組みを持っていますが、それ自体も例えば、ターゲット側で間違ってデータを更新してしまうなどの、人的ミスによる問題は避けられません。そこで今回は、SharePlexの持つデータを比較し、さらには間違いがあればそれを修復できる機能について、確認してみましょう。

>> 同期状態になっていない行の比較と修復を確認しよう

まずは、非同期状態を確認する前に、同期状態での確認を行ってみます。これまでのテストと同様に、ソース側はSPLEX.DEMO_SRCというテーブルを使用し、ターゲット側はSPLEX.DEMO_DESTとして複製されたテーブルを使用します。

ソース側で、件数を確認しておきます。


SQL> select count(*) from demo_src; COUNT(*) ---------- 200001

同様に、ターゲット側でも件数を確認しておきます。


SQL> select count(*) from demo_dest; COUNT(*) ---------- 200001

また、sp_ctrlのコンソールからqstatusコマンドにより、現在溜まっているキューがないことも確認しておきます。


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 27 mb) Backlog (messages): 0 (Age 0 min)

ソース側の確認が終わったら、ターゲット側でも確認しておきます。


sp_ctrl (rhel5spotrg1:2100)> qstatus Queues Statistics for rhel5spotrg1 Name: rhel5sposrc1 (o.src1-o.trg1) (MTPost queue) Number of messages: 0 (Age 0 min; Size 1 mb) Backlog (messages): 0 (Age 0 min)

データの比較にはcompareコマンドを使用します。指定方法はいくつかあるのですが、ここでは特定のテーブルのみを指定する方法を使用し、ソース側からSPLEX.DEMO_SRCテーブルを指定しています。ターゲット側は異なるテーブル名ですが、その関連は現在アクティブな定義ファイルにより確認されますので、ターゲット側としてはSPLEX.DEMO_DESTが使用されます。


sp_ctrl (rhel5sposrc1:2100)> compare splex.demo_src comparing 1 of 1 objects compare started; job id 1

コマンド実行後は、compare statusを使用してステータスを確認します。


sp_ctrl (rhel5sposrc1:2100)> compare status Job ID : 1 PID : 5227 Host : rhel5sposrc1 Started : 26-JUL-12 13:47:16 Job Type : Compare Status : Processing ID Tablename Status Time Total Rows %Comp Total Time ------ ------------------------------------ ---------- ---------- ---------- ----- ---------- 1 "SPLEX"."DEMO_SRC" WaitMarker 0:08 200001 0:09

コマンドを実行して間もない際には、statusの詳細が"WaitMarker"等まだ、compareが完了していないことを示すステータスの場合もあります。多少時間をおいてから確認するとstatusが"In Sync"ということで、同期状態であることが確認できました。


sp_ctrl (rhel5sposrc1:2100)> compare status Job ID : 1 PID : 5227 Host : rhel5sposrc1 Started : 26-JUL-12 13:47:16 Job Type : Compare Status : Done ID Tablename Status Time Total Rows %Comp Total Time ------ ------------------------------------ ---------- ---------- ---------- ----- ---------- 1 "SPLEX"."DEMO_SRC" In Sync N/A 200001 100 0:50

 

>> 非同期状態を作り出して確認してみよう

非同期の状態として可能性があるのは、ターゲット側を間違って更新してしまった場合も考えられます。ここでは、ターゲット側のデータを故意に変更して、確認してみます。

更新はなんでもよいのですが、以前使用したdemo.sqlスクリプトはNAME列を連番で更新しますので、その値を使用して更新してみます。たくさんの行がありますので、その中から3行だけ表示して、更新の目星をつけます。


SQL> select * from demo_dest where rownum<=3; NAME ------------------------------ ADDRESS PHONE# ------------------------------------------------------------ ------------ 00000125 WP3FEHWOFAMWWI9FH9SVIKSUY2SED9 KV39NF0C0EEC 00000126 GUQ24M7GZO0R6VSVTRQHJIJACWV9TV L9Q9MXG5JR2D 00000127 1QQW5H7RTKXXNTRMCYHTPPXNPN0CMW 5R7AFORKOOTQ

次の例では、NAME列が'00000125'であるところに対して、PHONE#およびADDRESS列をすべて0に設定しています。該当する行が2つあったので、それらに対して更新されたはずです。


SQL> update demo_dest set PHONE#='000000000000',
ADDRESS='000000000000000000000000000000' where NAME='00000125'; 2行が更新されました。 SQL> commit; コミットが完了しました。

念のため、更新状況を確認しておきます。


SQL> select * from demo_dest where NAME='00000125'; NAME ------------------------------ ADDRESS PHONE# ------------------------------------------------------------ ------------ 00000125 000000000000000000000000000000 000000000000 00000125 000000000000000000000000000000 000000000000

今度は、同じ条件の行について、ソース側を確認すると、当然ながらPHONE#およびADDRESS列が異なっていますので、これにより非同期状態となっています。


SQL> select * from demo_src where NAME='00000125'; NAME ------------------------------ ADDRESS PHONE# ------------------------------------------------------------ ------------ 00000125 WP3FEHWOFAMWWI9FH9SVIKSUY2SED9 KV39NF0C0EEC 00000125 WP3FEHWOFAMWWI9FH9SVIKSUY2SED9 KV39NF0C0EEC

 

>> 非同期状態を確認してみよう

先ほどと同様にcompareコマンドを使用することで、非同期状態の確認が可能です。


sp_ctrl (rhel5sposrc1:2100)> compare splex.demo_src comparing 1 of 1 objects compare started; job id 3

compareコマンド実行後しばらく時間がたつと、compare statusによりstatus列がOut Syncであることが確認できました。


sp_ctrl (rhel5sposrc1:2100)> compare status Job ID : 3 PID : 14289 Host : rhel5sposrc1 Started : 26-JUL-12 14:09:33 Job Type : Compare Status : Done ID Tablename Status Time Total Rows %Comp Total Time ------ ------------------------------------ ---------- ---------- ---------- ----- ---------- 1 "SPLEX"."DEMO_SRC" Out Sync N/A 200001 100 0:29

非同期な状態になった場合には、その詳細がターゲット側のvardir以下のlogディレクトリ内に記録されます。decltという文字列が入ったログは、compare機能により生成されたものになります。


[splex@rhel5spotrg1 ~]$ cd vardir/log/ [splex@rhel5spotrg1 log]$ ls -al 合計 76 drwxrwxr-x 2 splex spadmin 4096 7月 26 14:10 . drwxrwxr-x 11 splex spadmin 4096 3月 28 19:25 .. -rw-rw-r-- 1 splex spadmin 13456 7月 26 14:10 event_log -rw-rw-r-- 1 splex spadmin 1213 7月 26 14:10 trg1_SPLEX-DEMO_DEST-14289-14237.sql -rw-rw-r-- 1 splex spadmin 517 7月 26 13:48 trg1_SPLEX-DEMO_DEST-5227-5199.sql -rw-rw-r-- 1 splex spadmin 4458 7月 26 14:10 trg1_declt-SPLEX-DEMO_DEST-14289-14237.log -rw-rw-r-- 1 splex spadmin 4452 7月 26 13:48 trg1_declt-SPLEX-DEMO_DEST-5227-5199.log -rw-rw-r-- 1 splex spadmin 4288 7月 26 14:04 trg1_declt-SPLEX-DEMO_DEST-6452-6201.log -rw-rw-r-- 1 splex spadmin 12537 7月 26 13:47 trg1_rhel5sposrc1_opo01.log -rw-rw-r-- 1 splex spadmin 629 7月 26 12:45 trg1_rhel5sposrc1_opo_ddl_01.log

また、同ディレクトリ内に、拡張子が".sql"になっているスクリプトが新規に生成されます。これは、compare実行時のソース側とターゲット側の差分内容になっており、このSQLスクリプトを適用することで、同期状態にすることも可能です。その他詳細が記録されていますので、同期状態の確認には、便利に使用が可能です。


[splex@rhel5spotrg1 log]$ cat trg1_SPLEX-DEMO_DEST-14289-14237.sql /* * Compare Report * * Session ID : 14289 * Schema : SPLEX * Table : DEMO_DEST * Repair : Off * Target Route: rhel5spotrg1@trg1 * Key Compare : Off * Select Hint : * Log File : /home/splex/vardir/log/trg1_SPLEX-DEMO_DEST-14289-14237.sql * Date : Thu Jul 26 14:10:03 2012 * */ delete from "SPLEX"."DEMO_DEST" where rowid = 'AAAS+vAAEAAAAIjAAA'; delete from "SPLEX"."DEMO_DEST" where rowid = 'AAAS+vAAEAAAAWeAB8'; /* source rowid='AAASyyAAEAAAAI0AAA' */ insert into "SPLEX"."DEMO_DEST" ("NAME","ADDRESS","PHONE#") values ( '00000125', 'WP3FEHWOFAMWWI9FH9SVIKSUY2SED9', 'KV39NF0C0EEC'); /* source rowid='AAASyyAAEAAAAf/AAA' */ insert into "SPLEX"."DEMO_DEST" ("NAME","ADDRESS","PHONE#") values ( '00000125', 'WP3FEHWOFAMWWI9FH9SVIKSUY2SED9', 'KV39NF0C0EEC'); /* * Compare Results * * 200001 source and 200001 target rows compared successfully. * 4 out-of-sync row(s) found in this table. * The SQL statements above are needed to bring this * table back in sync. * * To bring this table back in sync, run the compare * command again with the repair option. * See SharePlex documentation for more details. * * Inserts : 2 * Updates : 0 * Deletes : 2 * */

 

>> repairコマンドにより非同期状態を修復

非同期状態を修復するには、repair機能を使用し、ソース側で対象となるテーブルを選択します。


sp_ctrl (rhel5sposrc1:2100)> repair splex.demo_src repairing 1 of 1 objects repair started; job id 4

正常に完了した場合には、statusとしてrepairedとなります。


sp_ctrl (rhel5sposrc1:2100)> repair status Job ID : 4 PID : 14413 Host : rhel5sposrc1 Started : 26-JUL-12 14:16:51 Job Type : Repair Status : Processing ID Tablename Status Time Total Rows %Comp Total Time ------ ------------------------------------ ---------- ---------- ---------- ----- ---------- 1 "SPLEX"."DEMO_SRC" Repaired 0:10 200001 100 0:39

念のためターゲット側で、前回確認したNAME列の値を使用して確認すると、確かに値が0ではなく、設定した値になっていることが確認できます。


SQL> select * from demo_dest where NAME='00000125'; NAME ------------------------------ ADDRESS PHONE# ------------------------------------------------------------ ------------ 00000125 WP3FEHWOFAMWWI9FH9SVIKSUY2SED9 KV39NF0C0EEC 00000125 WP3FEHWOFAMWWI9FH9SVIKSUY2SED9 KV39NF0C0EEC

 

>> まとめ

SharePlexが持つcompareおよびrepair機能を中心に、簡単な動作の流れを確認していただきました。DDLの複製を除いて、基本的な動作確認は以上になります。

次回はSharePlexが持つ機能について少し整理させていただく予定です。