Oracle Golden Gateを使ってみた　基本編(3)

Oracle Golden Gateを使ってみた　基本編の第3回です。

今回はソースDBへの更新が宛先DBに実際に反映されるのか、どの位の時間がかかるかを見ていきます。

bismarc256.hateblo.jp

【最大2000円クーポン|SS】ヤマモリおすすめタイカレー 5種類×2の食べ比べ 10個セット | レトルトカレーカレーグリーンカレーレトルト辛口常温保存在宅応援ヤマモリ公式電子レンジ対応あす楽父の日

価格: 3560 円
楽天で詳細を見る

手始めに1件だけ、インサートしてみます。ggsがレプリケーション元DB,ggdがレプリケーション先DBです。

ggs

[2022-05-12 14:19:42.007] SQL> insert into tab1 values(1,'test',systimestamp);
[2022-05-12 14:20:15.304]
[2022-05-12 14:20:15.304] 1 row created.
[2022-05-12 14:20:15.304]
[2022-05-12 14:20:15.304] SQL> commit;
[2022-05-12 14:20:18.945]
[2022-05-12 14:20:18.945] Commit complete.
[2022-05-12 14:20:18.945]
[2022-05-12 14:20:18.945] SQL> select count(*) from tab1;
[2022-05-12 14:20:26.179]
[2022-05-12 14:20:26.179] COUNT(*)
[2022-05-12 14:20:26.179] ----------
[2022-05-12 14:20:26.179] 1

無事、反映されていますね。

ggd

[2022-05-12 14:20:20.414] SQL> select count(*) from tab1;
[2022-05-12 14:20:30.320]
[2022-05-12 14:20:30.320] COUNT(*)
[2022-05-12 14:20:30.320] ----------
[2022-05-12 14:20:30.320] 1

さらにもう1件。

ggs

[2022-05-12 14:20:26.179] SQL> insert into tab1 values(2,'test',systimestamp);
[2022-05-12 14:20:40.585]
[2022-05-12 14:20:40.585] 1 row created.
[2022-05-12 14:20:40.585]
[2022-05-12 14:20:40.585] SQL> select count(*) from tab1;
[2022-05-12 14:20:47.070]
[2022-05-12 14:20:47.070] COUNT(*)
[2022-05-12 14:20:47.070] ----------
[2022-05-12 14:20:47.070] 2
[2022-05-12 14:20:47.070]
[2022-05-12 14:20:47.070] SQL> commit;
[2022-05-12 14:20:55.648]
[2022-05-12 14:20:55.648] Commit complete.

Commit completeが14:20:55.648なので、14:20:48.976に発行したselectの結果は当然ながら1件のままです。

14:20:56.804の時点ではまだ反映されていませんが、14:21:00.122に発行したselectの結果、更新が反映されています。

ggd

[2022-05-12 14:20:48.976] SQL> select count(*) from tab1;
[2022-05-12 14:20:56.804]
[2022-05-12 14:20:56.804] COUNT(*)
[2022-05-12 14:20:56.804] ----------
[2022-05-12 14:20:56.804] 1
[2022-05-12 14:20:56.804]
[2022-05-12 14:20:56.804] SQL> select count(*) from tab1;
[2022-05-12 14:21:00.121]
[2022-05-12 14:21:00.121] COUNT(*)
[2022-05-12 14:21:00.121] ----------
[2022-05-12 14:21:00.121] 1
[2022-05-12 14:21:00.121]
[2022-05-12 14:21:00.122] SQL> select count(*) from tab1;
[2022-05-12 14:21:02.171]
[2022-05-12 14:21:02.171] COUNT(*)
[2022-05-12 14:21:02.171] ----------
[2022-05-12 14:21:02.171] 2

更新件数を増やしてみます。

ggs

[2022-05-12 14:22:20.664] SQL> begin
[2022-05-12 14:23:16.906] 2 for i in 1..50000 loop
[2022-05-12 14:23:32.914] 3 insert into tab1 values(i,'test',systimestamp);
[2022-05-12 14:23:36.788] 4 end loop;
[2022-05-12 14:23:40.882] 5 end;
[2022-05-12 14:23:44.539] 6
[2022-05-12 14:23:53.976] 7 /
[2022-05-12 14:23:59.038]
[2022-05-12 14:23:59.038] PL/SQL procedure successfully completed.
[2022-05-12 14:23:59.038]
[2022-05-12 14:23:59.038] SQL> commit;
[2022-05-12 14:24:00.132]
[2022-05-12 14:24:00.132] Commit complete.
[2022-05-12 14:24:00.132]
[2022-05-12 14:24:00.132] SQL> select count(*) from tab1;
[2022-05-12 14:24:20.711]
[2022-05-12 14:24:20.711] COUNT(*)
[2022-05-12 14:24:20.711] ----------
[2022-05-12 14:24:20.711] 50000

Commit completeが14:24:00.132。

14:24:04.976と14:24:05.539に発行したselectでは結果が反映されず、14:24:10.679発行分で反映されています。

つまり、5万件で10秒くらいかかってますね。

ggd

[2022-05-12 14:24:04.976] SQL> /
[2022-05-12 14:24:05.539]
[2022-05-12 14:24:05.539] COUNT(*)
[2022-05-12 14:24:05.539] ----------
[2022-05-12 14:24:05.539] 0
[2022-05-12 14:24:05.539]
[2022-05-12 14:24:05.539] SQL> /
[2022-05-12 14:24:10.679]
[2022-05-12 14:24:10.679] COUNT(*)
[2022-05-12 14:24:10.679] ----------
[2022-05-12 14:24:10.679] 0
[2022-05-12 14:24:10.679]
[2022-05-12 14:24:10.679] SQL> /
[2022-05-12 14:24:11.413]
[2022-05-12 14:24:11.413] COUNT(*)
[2022-05-12 14:24:11.413] ----------
[2022-05-12 14:24:11.413] 50000

更に転送されるデータ量を増やしてみます。

5万件×約4K＝約200MBです。

ggs

[2022-05-12 14:34:06.242] SQL> update tab1 set col4=rpad(col4,4000,'x');
[2022-05-12 14:35:13.209]
[2022-05-12 14:35:13.209] 50000 rows updated.
[2022-05-12 14:35:13.209]
[2022-05-12 14:35:13.209] SQL> commit;
[2022-05-12 14:35:18.617]
[2022-05-12 14:35:18.617] Commit complete.
[2022-05-12 14:35:18.617]
[2022-05-12 14:35:18.617] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:35:20.429]
[2022-05-12 14:35:20.429] COUNT(*)
[2022-05-12 14:35:20.429] ----------
[2022-05-12 14:35:20.429] 50000

Commit completeは14:35:18.617。

14:35:57.381発行のselectで結果が反映されました。

約39秒ですね。と言っても、その直前に確認したのが14:35:42.428なので、14:35:43あたりで反映されていた可能性もありますが、それだと25秒です。

ggd

[2022-05-12 14:35:20.851] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:35:23.914]
[2022-05-12 14:35:23.914] COUNT(*)
[2022-05-12 14:35:23.914] ----------
[2022-05-12 14:35:23.914] 0
[2022-05-12 14:35:23.914]
[2022-05-12 14:35:23.914] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:35:29.476]
[2022-05-12 14:35:29.476] COUNT(*)
[2022-05-12 14:35:29.476] ----------
[2022-05-12 14:35:29.476] 0
[2022-05-12 14:35:29.476]
[2022-05-12 14:35:29.476] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:35:42.428]
[2022-05-12 14:35:42.428] COUNT(*)
[2022-05-12 14:35:42.428] ----------
[2022-05-12 14:35:42.428] 0
[2022-05-12 14:35:42.428]
[2022-05-12 14:35:42.428] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:35:57.381]
[2022-05-12 14:35:57.381] COUNT(*)
[2022-05-12 14:35:57.381] ----------
[2022-05-12 14:35:57.381] 0
[2022-05-12 14:35:57.381]
[2022-05-12 14:35:57.381] SQL> select count(*) from tab1 where col4 like '%x%';
[2022-05-12 14:36:06.914]
[2022-05-12 14:36:06.914] COUNT(*)
[2022-05-12 14:36:06.914] ----------
[2022-05-12 14:36:06.914] 50000

尚、大量データを送信するようなシステムでは、TCPBUFSIZEサイズを大きくする事でターゲット・システムにより大きなパケットを送信できます。（実際のバッファ・サイズは、TCPスタックの実装およびネットワークによって決定されます）

Oracle社のテストでは、初期ロードにTCPBUFSIZEを使用すると、使用しないで実行した場合よりも3倍速いスループットが生成されることが示されているそうです。

また、FLUSHSECSまたはFLUSHCSECSパラメータでは、Extractバッファをフラッシュする間隔が設定可能で、デフォルトでは1秒です。

FLUSHSECSで指定した時間が経過するか、Extractバッファがいっぱいになればフラッシュされます。

つまり、更新量が少なくてもデフォルトでは1秒くらいのタイムラグはある訳ですね。

次回からは応用編で双方向レプリケーションを検証する予定です。

おらくるのいる生活

OracleのDBAとしての、障害対応やらパフォーマンス・チューニングやらの日々を綴っています

Oracle Golden Gateを使ってみた　基本編(3)