はじめに

Oracle GoldenGate Veridata 23c を試すシリーズの補足第2弾として、簡易性能検証についての報告です。ただし、性能については比較する表の件数、カラムの数、それらのデータ型とサイズなどが影響するために曖昧な数値を提示する事はできません。ここでのデータはあくまで特定の環境で行った値であり、責任を持てるものではない事を了承下さい。ただし、公式に示している情報(ブログ)のあるので、そちらもご参照下さい。
How to size Oracle GoldenGate Veridata?

環境について

環境は「GoldenGate Veridata23cを試す(3) 接続からレポートまで」で構築した環境を再利用します。この環境のSource および Target である Oracle Database 内に比較用の表を作成し、表の件数、カラム数、カラムのデータ型などを変動要素として何パターンかを簡易的に計測してみます。パフォーマンス向上のためにはCPU性能やソートのためのメモリ領域など様々ありますが、十分に試しきれない点はご勘弁下さい。

ノード名	役割	スペック	メモ
ServerS	source DB	12core/16GB	DB EE 19c 19.26	Xeon(R)E5-2697 v2 2.70GHz
ServerT	target DB	12core/16GB	DB EE 19c 19.26	Xeon(R)E5-2697 v2 2.70GHz
ServerVDT	VERIDATA Server(Java Agent 含む)	12core/16GB	Veridata 23c	Xeon(R) CPU E5540 2.53GHz

実装の手順および実行

サンプル表の準備
サンプル表を作成します。過去DWH系のテスト目的で作成した個人使用の表で、下記の構成となっています。

SQL> desc tblc
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CSEQ                                      NOT NULL NUMBER
 CDATA                                              VARCHAR2(256)
 C5M                                                NUMBER
 C1M                                                NUMBER
 C500K                                              NUMBER
 C250K                                              NUMBER
 C100K                                              NUMBER
 C40K                                               NUMBER
 C10K                                               NUMBER
 C1K                                                NUMBER
 C100                                               NUMBER
 C25                                                NUMBER
 C10                                                NUMBER
 C5                                                 NUMBER
 C4                                                 NUMBER
 C2                                                 NUMBER

カラム名はデータのカージナリティとなっていて、PL/SQLにより乱数を発生させ各カラムごとにデータが重複するようデータを生成・投入していきます。比較的大きな変動要素である件数調整は PL/SQLで都度調整する形を取りました。以下は投入後のイメージです。これを Source / Target の双方で準備し比較します。
(実表のイメージは以下)

様々な件数で試してみる – 操作イメージとともに
上記の表に対し、件数を変更しながら比較ジョブを実行します。以下が結果となりました。データは数回実施した平均値となります。

件数	データサイズ	時間	備考
1000件		3秒
10万件		5秒
1000万件	約800MB	70秒程度
1憶件	約8GB	11分程度	設定により改善(※)

※ 初期比較・フェッチバッチ・サイズ(※) 1000⇨10,000で1分程度改善

LOB データ (CLOB, BLOB) を追加して試してみる
「はじめに」のセクションで紹介したブログにも LOB型の比較で影響が出やすいとの記載もあり、CLOB および BLOB データの追加と性能の劣化傾向を確認します。ここでもリソースに加え、特に I/O性能に依存する事になると思われるので、あくまで特定環境における参考値として扱って下さい。
サンプル表にCLOB型カラムとBLOB型カラムを３つづつ、計6つのLOBを追加します。

SQL> desc tblc
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CSEQ                                      NOT NULL NUMBER
 CDATA                                              VARCHAR2(256)
 C5M                                                NUMBER
 C1M                                                NUMBER
 C500K                                              NUMBER
 C250K                                              NUMBER
 C100K                                              NUMBER
 C40K                                               NUMBER
 C10K                                               NUMBER
 C1K                                                NUMBER
 C100                                               NUMBER
 C25                                                NUMBER
 C10                                                NUMBER
 C5                                                 NUMBER
 C4                                                 NUMBER
 C2                                                 NUMBER
 CLOB1                                              CLOB
 CLOB2                                              CLOB
 CLOB3                                              CLOB
 BLOB1                                              BLOB
 BLOB2                                              BLOB
 BLOB3                                              BLOB

全てのLOBカラムが空の状態で実施するプレテストを含めCLOB1から　BLOB3まで順にLOBデータをセットしていき、計６つのLOB型カラムが比較対象になる7パターンのジョブを実行した結果が以下になります。LOBデータとして格納したデータ内容は全て同じものとしました。以下が結果です。

	要件:100万件	データ量(表領域)	1回目	2回目	3回目
1	CLOB/BLOBは空で比較	90MB	00:00:11	00:00:11	00:00:11
2	CLOB1にデータ投入	1170MB	00:00:48	00:00:43	00:00:44
3	CLOB2にデータ投入	2002MB	00:01:19	00:01:17	00:01:16
4	CLOB3にデータ投入	3026MB	00:01:57	00:01:51	00:01:49
5	BLOB1にデータ投入	3968MB	00:08:57	00:08:52	00:08:57
6	BLOB2にデータ投入	-	00:15:07	00:15:19	00:15:17
7	BLOB3にデータ投入	-	00:21:40	00:21:49	00:21:38

想定どおり、LOBデータの追加に伴い、比較処理に費やす時間が長くなる事が確認できます。加えてCLOBとBLOBを比較するとBLOBデータを持ったカラムが増える程、比較ジョブの長期化傾向が明らかになりました。

最後に

Oracle GoldenGate Veridata 23c を試すシリーズの補足として、少しムチャではありますが性能傾向を知りたかったので測定をしてみました。サイジングについては「はじめに」で紹介したブログを起点に検討を始めるのが適切だと思いますが、比較対象の件数やデータ型およびそのカラム数など限定的ではありますが見えてきた傾向が参考になればと思います。