OGG BATCHSQL解説：SQL配列実行からパフォーマンスチューニングまでの基盤ロジック

ある典型的なパフォーマンスチューニング事例を経験しました：大手小売企業の基幹取引システムがデータ分析プラットフォームに同期されるケースです。Extract側には全く負荷がかかっていないのに、Replicat側の遅延が数分から数時間に増大していました。監視を担当するDBAチームは焦りながらもなすすべがありませんでした。ターゲットデータベースのハードウェア、インデックス、ネットワークをすべて確認しましたが異常はなく、Replicatだけがなぜか「速く動かない」状態でした。

これは典型的なReplicatのパフォーマンスボトルネックで、根本原因はデータベースが「遅い」のではなく、OGGとデータベース間の「対話」が非効率的であることにあります。

このような無力感に直面したとき、BATCHSQLパラメータを投入する必要があるかもしれません。しかし、多くの人はその存在を知っていても、その基盤となるロジックや潜在的な問題を理解していないため、安易に使用することをためらいます。

今日、BATCHSQLを徹底的に解説します。その動作原理を深掘りし、安全に使いこなす方法を学び、どのシナリオで威力を発揮できるかを明らかにします。この記事を読み終えれば、Replicatのパフォーマンス問題を解決するための強力な武器として自信を持って使えるようになるでしょう。

1. Replicatが遅いの根本原因

BATCHSQLを深く理解する前に、まずReplicatのデフォルトの動作モードがなぜボトルネックを生むのかを理解しなければなりません。

デフォルトでは、ReplicatはTrailファイルからDML操作（UPDATEなど）を読み取り、ターゲットデータベースにSQLリクエストを送信します。そして次に次の操作を読み取り、また別のリクエストを送信します。　このプロセス全体で発生するのは：

100回のネットワーク往復（Round-trips）: 各リクエストはネットワークを介してデータベースに到達し、結果が返される必要があります。
100回のSQL解析（SQL Parsing）: データベースは、これら100件のほぼ同一のUPDATE文に対して、実行計画を100回繰り返し解析する必要があります。
100回の個別コミット（Commits）: これらの操作が異なるトランザクションに属している場合。

ソース側のTPS（1秒あたりのトランザクション数）が急増すると、このモデルはReplicatとデータベース間のインタラクション回数の爆発的な増加を引き起こし、真のパフォーマンスキラーとなります。

動作原理の比較図 BATCHSQL vs Default Workflow

2. 配列実行の魔力

BATCHSQLの登場により、この非効率な対話方法は一変させます。

BATCHSQLを有効にすると、Replicatは「賢く」なります。もはやSQLを1つずつ送信するのではなく、ツアーガイドのように、まず目的地と操作タイプが同じ旅行者（DML操作）のグループを集め、100人分の情報が記載されたリストを渡すのです。

これがデータベースの基盤技術である配列実行（Array BindingまたはBulk Operations）です。BATCHSQLは複数の独立したDML操作をメモリ内で「パッケージ化」し、単一のAPI呼び出しを通じて配列全体をデータベースに送信して実行させます。

利点：

ネットワーク往復の激減: かつて100回だったネットワークインタラクションが、今や1回になります。
SQL解析の大幅な削減: データベースはこの配列バインディングされたSQL文を一度だけ解析すればよく、その後100回のデータ挿入/更新をループで実行するだけです。
データベースI/Oの最適化: データベースはバルク操作を処理する際、I/Oリソースをより効率的に利用できます。

この方法により、BATCHSQLはReplicatプロセスとターゲットデータベースのCPU消費を大幅に削減し、パフォーマンスを桁違いに向上させます。「10倍の高速化」あるいはそれ以上の効果を実現することは決して大げさではありません。

3. BATCHSQLを使いこなす：主要パラメータとチューニング戦略

BATCHSQLは優れていますが、独立したスイッチではありません。その効果はOGGの内部バッファリングメカニズムや他のパフォーマンスパラメータに影響されます。

BATCHSQLの有効化

まず、BATCHSQLの有効化は簡単です。Replicatパラメータファイルにこのパラメータを追加するだけです。

-- Replicatパラメータファイル (rep.prm)
REPLICAT rep_dw
USERIDALIAS ogg_tgt_alias DOMAIN OracleGoldenGate
-- BATCHSQLモードを直接有効化
BATCHSQL
MAP source.orders, TARGET dw.orders;

明確にしておくべきことは、OGGにはバッチのメモリサイズを直接制御するためのBATCHSIZE <bytes>というパラメータは提供されていないということです。バッチのサイズはOGGの内部バッファリングメカニズム、トランザクションの境界、操作タイプによって決まり、メモリは自動的に管理されます。

協調チューニング：`GROUPTRANSOPS`で効果を増幅

パフォーマンスを最大化するために、通常BATCHSQLをもう一つの強力なパフォーマンスパラメータであるGROUPTRANSOPSと組み合わせます。

GROUPTRANSOPS <number> (Group Transaction Operations)
- 機能: このパラメータは、Replicatに複数のソーストランザクションを単一のより大きなターゲットトランザクションにマージするよう指示します。例えば、GROUPTRANSOPS 100と設定すると、Replicatは100個のソース側トランザクションを累積し、ターゲット側で単一のCOMMITでそれらをコミットします。
- BATCHSQLとの関係:
  - BATCHSQLはトランザクション内部のDML実行効率を最適化します（SQLインタラクションの削減）。
  - GROUPTRANSOPSはトランザクション間のコミット効率を最適化します（COMMIT回数の削減）。
- 相乗効果: これらを一緒に使用すると、二重の最適化が実現します。Replicatはまず複数のトランザクションを集約し、その大きな「スーパートランザクション」の内部で、BATCHSQLを使用してすべてのDML操作を効率的に実行します。これは、大量の小規模トランザクションを処理するシナリオで非常に効果的です。

例：協調チューニングされた設定

-- 協調チューニングされたReplicat設定
REPLICAT rep_dw
USERIDALIAS ogg_tgt_alias DOMAIN OracleGoldenGate

-- 最大1000件のソース・トランザクションを1つのターゲット・トランザクションにマージ
GROUPTRANSOPS 1000

-- マージされた大きなトランザクションの内部で、BATCHSQLを使用してDMLを効率的に実行
BATCHSQL

MAP source.orders, TARGET dw.orders;

公式ドキュメントの参照

パラメータのより詳細な研究と利用可能なすべてのオプションを理解するために、Oracleの公式ドキュメントを参照することを強くお勧めします。以下はOGG 19c Replicatパラメータリファレンスへのリンクです：

Oracle GoldenGate 19c Reference - Replicat Parameters

このページでBATCHSQLとGROUPTRANSOPSを検索すると、より詳細な説明を見つけることができます。

4. 副作用と適用シナリオ

BATCHSQLの強力なパフォーマンス向上は、「バッチ処理」によって得られます。これがその主な「副作用」をもたらします：

初回バイト遅延（First-byte Latency）の増加: Replicatは内部バッファに十分な操作が蓄積されるか、GROUPTRANSOPSが十分なトランザクションを蓄積するのを待ってから、実際にデータをターゲットデータベースに適用するためです。これは、特定のレコードがターゲット側で見えるようになるまでの時間が、非BATCHSQLモードよりも遅くなることを意味します。

これを理解すれば、その適用シナリオが明確になります：

最適な適用シナリオ：

大量の小規模トランザクション同期: これはBATCHSQLとGROUPTRANSOPSの組み合わせの本領発揮の場です。例えば、OLTPシステムの取引データをデータウェアハウスやデータマートにリアルタイムで同期する場合などです。これらのシナリオでは、単一トランザクションの遅延よりもスループットがはるかに重要です。
データ初期化/ロード: 初期データロード時にはパフォーマンスが最優先です。BATCHSQLはロード時間を大幅に短縮できます。
主キーまたユニークキーのないテーブル: このようなテーブルに対するUPDATEおよびDELETE操作では、データベースはフルテーブルスキャンを実行する必要があり、パフォーマンスが極端に悪くなります。BATCHSQLは複数のフルテーブルスキャンを統合し、パフォーマンスを大幅に向上させることができます。

慎重に使用または使用を避けるべきシナリオ：

単一トランザクションの遅延に非常に敏感なシステム: 例えば、2つの取引システム間でリアルタイムの双方向同期を行い、取引ステータスがサブ秒単位で同期される必要がある場合などです。このようなシナリオでは、BATCHSQLによって生じる追加の遅延は許容できません。
ターゲットのリソースが極端に制限されている場合: ターゲットデータベースのメモリやCPUがすでに限界に達している場合、過度に積極的なバッチ処理とトランザクションのグループ化はデータベースを圧倒する可能性があります。

まとめ

BATCHSQLは間違いなくOGG Replicatのパフォーマンスチューニングの中で最も強力な武器の一つですが、使用者はその原理と代償を理解する必要があります。

今日の核心的な内容を振り返ってみましょう：

核心要点	説明
問題の根源	デフォルトモードでは、Replicatはデータベースと1レコードずつ対話するため、ネットワークと解析のオーバーヘッドが膨大になる。
核心原理	配列実行を通じて、大量のDML操作を単一のリクエストに「パッケージ化」し、インタラクションのオーバーヘッドを指数関数的に削減する。
協調パラメータ	通常、`GROUPTRANSOPS`と組み合わせて使用される。前者はDML実行を最適化し、後者はトランザクションのコミットを最適化する。
主な代償	初回バイト遅延が増加し、バッチ処理の待機時間と引き換えに全体のスループットを向上させる。
最適なシナリオ	データウェアハウス同期やバルクローディングなど、高スループット・低レイテンシーが求められるシナリオ。