LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ShaneSheninGOODWAYS株式会社

クラシック vs. 統合Extract：Oracle GoldenGateの詳細な比較

Posted at

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

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

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

1. 動作の仕組み：根本的な違い

正しい選択をするためには、まず、これらがデータベースログを読み取るために2つのまったく異なるパスをたどることを理解する必要があります。

クラシックExtract：孤独なログリーダー

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

それは、図書館の外にしか立つことができず、固定された窓から渡される本（Redo/Archiveログ）を1冊ずつ読む、勤勉だが孤独な司書のようなものだと考えることができます。

ワークフロー図：
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は、歴史の舞台における互換性ソリューションとして存在するに過ぎません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?