第08回 SharePlexを使っていろいろなテストをやってみよう (その1)

>> はじめに

インストールし、簡単な設定を行うだけで、1つのテーブルを指定したレプリケーションができるようになりました。今回からしばらくは、こちらのテーブルを使用して、SharePlexのインストールガイドに記載されている「基本デモンストレーション」の内容に沿って、いろいろな動作を見ていきたいと思います。

>> 大量のデータの複製とその状況を見てみよう

前回は、たった1件のINSERTの実行のみでしたが、さすがにそれではテストとしても少なすぎると思います。ということで、今回は大量のデータの複製とその状況の確認を行ってみます。

■ターゲット側の状況を確認するperf_mon.shを使用しよう

データを転送する先では、postという処理により複製されたトランザクションがSQL文によってターゲット側に反映されます。その処理数の状況を確認するためにSharePlexでは、perf_mon.shというスクリプトを用意しています。

このスクリプトは、製品ディレクトリのutil以下に存在します。これをターゲット側のサーバで動作させます。引数なしで実行すると以下のようなエラーが表示されることがあります。


[splex@rhel5spotrg1 ~]$ cd $HOME/splex/util
[splex@rhel5spotrg1 util]$ ./perf_mon.sh
cat: /var/adm/.splex/Shareplex.mark: そのようなファイルやディレクトリはありません
 ERROR:

     SP_SYS_BINDIR is not set and can not be read from the markerfile
     please set the environment variable SP_SYS_BINDIR and rerun perf_mon.sh

その際には、環境変数SP_SYS_BINDIRにSharePlex製品ディレクトリであるパスを設定してください。実行して、使い方が表示されれば問題ありません。


[splex@rhel5spotrg1 ~]$ $SP_SYS_BINDIR/util/perf_mon.sh
Binary data in /home/splex/splex
Variable directory is /home/splex/vardir
Must include a sample amount.

Usage : perf_mon.sh SAMPLES INTERVAL [QUEUE] \n SAMPLES = 
Number of samples to take. (Must be > 2)\n INTERVAL = 
Number of seconds to sleep between polls.\n QUEUE = 
(optional) if using multiple post queues this is the \n 
name of the post queue to poll.

perf_mon.shは、次のような構文で使用することになっています。


perf_mon.sh [ポーリング回数] [ポーリング間隔]

ソース側でトランザクションを発行させる前に実行して、トランザクション実行後までの経過を見てみたいと思いますので、いつでも実行できる準備をしておきます。

■ソース側で大量のトランザクションを発生させるPL/SQLスクリプト

次に、ソース側で前回も使用したdemo_srcテーブルに対してたくさんのトランザクションを発生させます。と言っても、すべて手入力という訳にはいきませんので、簡単なPL/SQLを用意して、それでINSERTしてみましょう。

以下の内容のスクリプトをdemo.sqlとして保存しておきます。
【ご注意】本スクリプトは製品には含まれておりません。また、無保証になります。


declare
    nNAME       VARCHAR2(30);
    nADDRESS    VARCHAR2(60);
    nPHONE      VARCHAR2(12);
 begin
   dbms_random.seed(uid);
   for i in 1..100000
   loop
           nNAME := to_char(i, 'FM00000000');
           nAdDRESS := dbms_random.string('x', 30);
           nPHONE := dbms_random.string('x', 12);
           insert into demo_src (NAME, ADDRESS, PHONE#) values (nNAME, nADDRESS, nPHONE);
           if (mod(i, 100) = 0) then
                   commit;
           end if;
   end loop;
   commit;
end;
/

■トランザクションを発生させて、状況を確認してみる

スクリプトの準備ができたら、先にターゲット側でperf_mon.shの実行を行っておきます。標準的にはおそらく5分くらいで実行されると思いますので、30秒間隔で10回程度に設定してみます (環境によって変更してください)。トランザクションが発生していない状態では、メッセージの件数等は"0"になっています。


[splex@rhel5spotrg1 util]$ ./perf_mon.sh 10 30
Binary data in /home/splex/splex
Variable directory is /home/splex/vardir

Memory Info

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      8 1587780 121216 1901564    0    0    14    36  447  422  1  0 99  0  0
\n\nDate:2012年  5月 31日 木曜日 13:29:41 JST
Queue rhel5sposrc1 for o.src1-o.trg1
TPS for posting is 0 messages per second.
TPS for posting inserts is 0 messages per second.
TPS for posting updates is 0 messages per second.
TPS for posting deletes is 0 messages per second.
 messages backlog
SharePlex is commiting 0 times per second.

その後に、作成しておいたPL/SQLのスクリプトをソース側で実行します。PL/SQL自体は比較的すぐに終了し、件数が増えていることが確認できるはずです (このスクリプトでは、10万件のトランザクションを発生します)。


[oracle@rhel5sposrc1 ~]$ sqlplus SPLEX/SPLEX

SQL> @demo.sql

PL/SQLプロシージャが正常に完了しました。

SQL> select count(*) from demo_src;

  COUNT(*)
----------
    100001

ターゲット側のperf_mon.shの実行結果を確認すると、TPS (Transaction per sec) の値を確認することができます。Insertの1/100の数分だけcommitが行われているというのもよく分かります。


Memory Info

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      8 1594120 121248 1901560    0    0    14    36  447  422  1  0 99  0  0
\n\nDate:2012年  5月 31日 木曜日 13:30:11 JST
Queue rhel5sposrc1 for o.src1-o.trg1
TPS for posting is 3366.66 messages per second.
TPS for posting inserts is 3333.33 messages per second.
TPS for posting updates is 0 messages per second.
TPS for posting deletes is 0 messages per second.
 messages backlog
SharePlex is commiting 33.33 times per second.

ターゲット側で複製されたテーブルの件数を確認してみても、ソース側と一緒であることが確認できました。


SQL> select count(*) from demo_dest;

  COUNT(*)
----------
    100001

>> まとめ

大量のトランザクションが発生しても、簡単にレプリケーションが実行できていることが確認できました。また、その状況を確認するperf_mon.shを使用して、メッセージの処理件数等をご覧いただきました。

次回は、状態の変化に対応するSharePlexの動作について、確認してみたいと思います。