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