Oracle GoldenGate (OGG) プロジェクトで12年以上の経験を持つデータ統合スペシャリストとして、ほぼすべての新規プロジェクトのキックオフで持ち上がる質問がある：「クラシックExtractと統合Extractのどちらを使用すべきか？」

これは決して「新しいものが常に優れている」という単純な選択ではありません。多くのチームは「統合は新しく、クラシックは古い」という漠然とした理解をしています。しかし、高負荷のRACクラスタソース、頻繁なDDL変更、ソースシステムのパフォーマンスに対する極端な感度など、特定のビジネスシナリオに直面した場合、明確かつ合理的な判断が極めて重要になります。間違った選択は、後々の運用上の悪夢に変わりかねません。

本記事は、これら2つのモードの内部構造を、その動作原理からパフォーマンスのボトルネックまで掘り下げ、その違いを徹底的に明らかにします。これを通じて、自信を持ってプロジェクトに最適なアーキテクチャを選択し、その「理由」を明確に説明できるようになるでしょう。

1. 動作原理：根本的な違い

正しい選択をするためには、まずデータベースのログを読み取るために、まったく異なる2つのアプローチを取っていることを理解しなければなりません。

クラシックExtract：単独動作するログリーダー

クラシックExtractは非常に直接的な方法で動作します。独立した外部プロセスとして、OracleのオンラインRedoログファイルまたはアーカイブ・ログを直接かつ順次読み取ります。

ワークフロー図： Classic Extract Workflow

このモードの利点は、そのシンプルさと独立性です。しかし、高並行性環境、特にRAC（Real Application Clusters）では、そのボトルネックが明らかになります。

  • RAC環境でのロック競合: RAC環境では、各ノードが独自のRedoスレッドを生成します。データの一貫性を確保するために、クラシックExtractは異なるノードからログを読み取り、SCN（System Change Number）でマージソートする必要があります。このプロセスは、司書が複数の窓口から同時に本を処理しようとし、元のページ番号で並べ替えなければならないようなものです。非常に非効率的であり、ノードのログを待つ間に重大なレイテンシが発生しがちです。これがRAC環境におけるクラシックモードの問題です。
  • 限定的なDDLサポート: クラシックモードのDDL（データ定義言語）サポートは不格好で、追加の構成が必要であり、サポートされるDDLタイプも限られており、取り扱いが非常に面倒です。

統合Extract：データベースの奥深くにある「内部エージェント」

クラシックモードとは異なり、統合ExtractはOracleデータベース内に仕込まれた「内部関係者」です。物理的なログファイルを直接読み取るのではなく、Logmining Serverと呼ばれるデータベースコンポーネントと深く統合されています。 例えば、司書を外で待たせる代わりに、図書館の中核であるカタログセンター（Logmining Server）に直接送り込んだようなものです。データベース自体が生成するログストリーム（Logical Change Records、LCR）はこのセンターに継続的に供給され、統合Extractはまさにそこにいて、最も効率的な方法で必要なデータを取得します。

ワークフロー図： Integrated Extract Workflow

このモデルは、クラシックモードの問題点を根本的に解決します。

  • ネイティブRACサポート: 統合Extractはデータベースの統一されたログストリームレベルで動作するため、すべてのノードからのマージされたデータを自然に参照でき、ノード間のログ読み取りやソートの問題を完全に回避します。RACのサポートはシームレスで効率的です。
  • 強力なDDLサポート: DDL操作はデータベース内部で直接LCRに変換されます。統合Extractは、複雑な追加設定なしに、DMLと同じくらい簡単にDDLをキャプチャして処理できます。
  • ソースに優しい: 圧縮や暗号化などの高度な機能をよりうまく処理し、内部データベースコンポーネントとして、そのリソーススケジューリングと管理はよりインテリジェントです。

2. コア差異：パフォーマンス、機能、実践におけるコード

理論上の利点と欠点は、最終的にはパフォーマンスと機能における具体的な差異として現れます。OGG 19c/21cにおける具体的なコード例を通じて、これらの違いを確認してみましょう。

実践におけるコード：パラメータファイルと登録

クラシックExtractパラメータファイル (cext.prm) これは非常に伝統的な設定で、Extractにログをどこから読み取るかを明示的に指示する必要があります。

-- クラシックExtractプロセス cext
EXTRACT cext
-- ID、従来のユーザー/パスワードを使用
USERIDALIAS ogg_admin_alias
-- Redoログスレッドとアーカイブ・ログの場所を直接指定
TRANLOGOPTIONS DBLOGREADER
-- ローカルのTrailファイルに書き込み
EXTTRAIL ./dirdat/lt
-- 抽出対象のテーブル
TABLE hr.*;

統合Extractパラメータファイル (iext.prm) と登録 物理的なログの場所を気にする必要がないため、設定はよりクリーンに見えます。

-- 統合Extractプロセス iext
EXTRACT iext
-- ID、DBLOGIN必須、データベース認証を使用
USERIDALIAS ogg_admin_alias 
-- 競合検出をサポートするために、すべての列のサプリメンタルロギングを宣言
LOGALLSUPCOLS
-- ローカルのTrailファイルに書き込み
EXTTRAIL ./dirdat/li
-- 抽出対象のテーブル
TABLE hr.*;

重要なステップは、統合Extractをデータベースに「登録」し、「データストリームの準備を開始（iext）」と伝えることです。

-- データベースにログイン
DBLOGIN USERIDALIAS ogg_admin_alias
-- Extractプロセスを登録
REGISTER EXTRACT iext DATABASE

運用監視：ステータスとラグの確認

監視は日常業務の中核であり、2つのモードの監視方法は異なります。

共通のラグチェックコマンド このコマンドは両方のモードに適用され、ラグを確認する最も直接的な方法です。

-- GGSCIで実行
LAG EXTRACT iext

統合Extract固有のステータス問い合わせ 統合Extractはデータベースの一部であるため、DBAビューを通じてそのより詳細な内部ステータスを表示できますが、これはクラシックモードでは不可能です。

-- DBAユーザーで問い合わせ
SELECT
    capture_name,
    state,
    total_messages_captured,
    total_messages_enqueued
FROM
    v$goldengate_capture;

このビューを通じて、Extractプロセスの状態（例：CAPTURING CHANGES）やキャプチャされたLCRの数を確認でき、詳細なトラブルシューティングに非常に役立ちます。

3. 選択ガイド：どちらを選ぶべきか？？

すべての原則とコードを議論した後、最初の質問に戻りましょう：どちらを選ぶべきか？？私の意見では、この判断プロセスは実は非常に明確です。

意思決定ツリーガイド： OGG Extract Decision Tree

ここに、簡単な決定チェックリストを用意しました。

  1. データベースのバージョンが最初のハードル
    • Oracleデータベースのバージョンが11.2.0.4未満の場合：残念ながら、クラシックExtractを使用するしかありません。統合モードが正式に利用可能になったのはこのバージョンからです。
    • データベースのバージョンが >= 11.2.0.4（特に12c以上）の場合：特別な理由がない限り、直接統合Extractを選択してください。
  2. ソースはRAC環境か？
    • はい：間違いなく統合Extractを選択してください。RACでクラシックモードを実行するのは問題の種をまくようなもので、後でパフォーマンスと遅延の問題に対処するために多くの時間を費やすことになります。
    • いいえ（シングルインスタンス）：機能とソースシステムへの優しさの点でクラシックモードを上回るため、統合Extractが依然として最良の選択です。
  3. DDL同期の強いニーズはあるか？
    • 頻繁なDDL変更を同期する必要がある：統合ExtractのネイティブDDLサポートは、多くの頭痛の種を減らしてくれます。
    • DDLの変更がほとんどない：クラシックモードでも対応できますが、それが統合モードを選択しない理由にはなりません。

では、クラシックモードにまだ出番はあるのか？

確かにあるですけど、適用可能なシナリオは非常に限られています。想定される主なケースは以下の通りです。

  • レガシーシステムとの互換性：クラシックモードのみをサポートする古いシステムやツールと連携する必要がある場合。
  • 特定のログ読み取りニーズ：非常に稀なケースで、稼働していないデータベースインスタンスからデータを抽出する必要がある場合。非常に稀なケースとして、

まとめ

より直感的なレビューを提供するために、主要な差異を表にまとめました。

特徴 クラシックExtract 統合Extract
動作原理 外部プロセス、Redo/Archiveを直接読み取り 内部コンポーネント、Logmining Server経由
RACサポート パフォーマンスボトルネックやロック競合の問題あり ネイティブサポートでシームレスな動作
DDLサポート 制限あり（複雑な設定が必要） 強力なネイティブサポート
データ型 新規データ型のサポートに遅延が生じる可能 全データ型を完全サポート
ソースへの負荷 比較的高い（RAC環境で顕著） 低負荷（インテリジェントなリソース管理）
設定の複雑さ シンプルで直接的 やや複雑（登録作業必要）だが高機能
対応バージョン 全バージョン対応 11.2.0.4以降

最終的な選択原則は実はシンプルです。現代的なOracleデータベース環境（12c以降）では、統合Extractがデフォルトかつ唯一推奨される選択肢です。 これは、データベースとのより高度で効率的、かつ緊密に統合された設計思想を表しています。またクラシックExtractは、歴史の舞台における互換性ソリューションです。