「OGGのExtractプロセスが午前3時にクラッシュした場合、どうすればよいでしょうか？」

これは、顧客トレーニングでほぼ毎回受ける質問です。私の答えは常にシンプルです：「何もしないで、ただSTARTするだけです。」この自信は根拠のないものではありません—Oracle GoldenGateの高信頼性の基盤であるチェックポイントメカニズムへの深い理解に基づいています。

ほぼすべてのOGGユーザーは、異常発生後に「ブレークポイントから再開」できることを知っています。しかし、この「ブレークポイント」とは具体的に何でしょうか？どこに存在するのでしょうか？数万レコードを含む大規模トランザクションが途中で中断された場合、OGGは再起動後、重複も漏れもなく、正確に処理を継続することをどのように保証しているのでしょうか？

この内部メカニズムの「ブラックボックス」理解が、ユーザーの不安の根本原因となることがよくあります。今日は、チェックポイントメカニズムを徹底的に分析し、いくつかの小さなファイルを通じて破壊不可能なデータ保護システムを構築する方法をお見せします。この記事を読んだ後、あなたは心の底からOGGを信頼し、より安全な運用判断を下すことができるようになるでしょう。

1. チェックポイントの「三銃士」：CPE、CPR、CPTファイル

チェックポイントを理解するには、まずそれを記録する責任を持つ3つのコアファイルを認識する必要があります。これらは通常、OGGインストールディレクトリのdirchkサブディレクトリに配置され、プロセス名に.cpe、.cpr、.cptという拡張子を付けた名前で保存されます。

  • .cpe（Extract Checkpoint File）: Extractプロセスの専用「ナビゲーションログ」。
    • 目的: Extractが正常に処理し、Trail Fileに書き込んだ最後のデータレコードの位置を記録します。この位置情報は非常に精密です—Oracleソースの場合、Redoログファイルのシーケンス番号とRBA（Relative Byte Address）を記録します；その他のデータベースの場合、対応するログシーケンス番号（PostgreSQLのLSNなど）を記録します。
    • 動作: Extractは完全なトランザクションをTrail Fileに正常に書き込むたびに.cpeファイルを更新します。Extractプロセスが再起動する際、まずこのファイルを読み取り、前回記録された「ナビゲーション座標」を見つけ、その後データベースに「この座標の後の位置から新しいログ情報をください」と伝えます。
  • .cpr（Replicat Checkpoint File）: Replicatプロセスの「作業台帳」。
    • 目的: これはReplicatのチェックポイントファイルで、Trail Fileから読み取った最後のトランザクションの位置を記録し、ターゲットデータベースに正常に適用されました。
    • 動作: ReplicatはTrail Fileからデータを読み取り、ターゲット側でトランザクションを正常にCOMMITした後、.cprファイルを更新し、このトランザクションのTrail File内での位置を記録します。Replicatがクラッシュした場合、再起動後に.cprファイルを読み取り、Trail Fileのどの位置から読み取りを再開すべきかを知るため、既にコミットされたトランザクションの再適用を避けることができます。
  • .cpt（Checkpoint Table）: トランザクション状態の「バッファ」。（注：これは通常Replicatのチェックポイントテーブルを指しますが、ファイルシステム内のトランザクション状態ファイルを指す場合もあります）。
    • 目的: これは「重複なし、欠落なし」を実現する本質です。複数のTrail Fileにまたがる長いトランザクションや大量の操作を含むトランザクションに対して、Replicatは処理中に現在のトランザクションの内部処理進捗（適用されたレコード数など）やその他の状態情報をこの「バッファ」に定期的に永続化します。
    • 動作: 10,000のINSERT文を含む大規模トランザクションを想像してください。Replicatは5,000番目のレコードを適用中にクラッシュします。.cptがない場合、再起動後はこのトランザクションの最初から再適用するしかなく、5,000の重複レコードが発生します。しかし.cptがあれば、Replicatは再起動後にまずこのバッファをチェックし、「あ、この大規模トランザクションの半分は既に処理済みだ」と発見するため、5,001番目のレコードから直接適用を開始し、トランザクション内での精密なブレークポイント復旧を実現します。

チェックポイントメカニズムワークフロー図 Checkpoint Mechanism Workflow

2. コード実践：チェックポイントの観察と操作

理論は退屈なので、GGSCIのコマンドを使用してチェックポイントがどのように動作するかを直接見てみましょう。

チェックポイント情報の表示

INFOコマンドを使用して、各プロセスによって記録されたチェックポイント情報を明確に確認できます。

Extractのチェックポイント表示:

-- GGSCIで実行
INFO EXTRACT extora, DETAIL

以下のような出力が表示され、これは.cpeファイルから読み取られた情報です：

EXTRACT    EXTORA    Last Started 2025-06-19 12:29   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:07 ago)
Process ID           4467
Log Read Checkpoint  Oracle Integrated Redo Logs
                     2025-07-09 10:20:11
                     SCN 0.10607098 (10607098)

ここで、SCN 0.10607098がExtractの「ナビゲーション座標」です。

Replicatのチェックポイント表示:

-- GGSCIで実行
INFO REPLICAT repmysql, DETAIL

出力には、Replicatが読み取りを開始するTrail File内の位置（RBA）が表示され、この情報は.cprファイルから来ています。

REPLICAT   REPMYSQL  Last Started 2025-06-19 13:37   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:02 ago)
Process ID           4673
Log Read Checkpoint  File ./dirdat/my000000000
                     2025-06-19 12:30:11.979107  RBA 4539575

手動チェックポイント操作（高リスク、注意して使用！）

特定の特殊な運用シナリオ（データ初期化後など）では、プロセスの開始位置を手動で設定する必要がある場合があります。この時、あなたはチェックポイントファイルを操作しています。

-- 警告：これは危険な操作で、以前のすべてのデータをスキップします！
-- Extractを現在の最新Redoログから抽出開始するよう強制
ALTER EXTRACT extora, BEGIN NOW

-- Replicatを指定されたTrail Fileから読み取り開始するよう強制
ALTER REPLICAT repmysql, EXTTRAIL ./dirdat/my, EXTSEQNO 1, EXTRBA 0

これらのコマンドを実行する際、OGGはバックグラウンドで対応する.cpeまたは.cprファイルを書き換え、新しい開始位置を「公式記録」として設定します。これが運用リスクがチェックポイントの無知から生じる理由です。この操作の結果を理解していない場合、データ損失や重複を簡単に引き起こす可能性があります。

3. 原理に基づく運用ガイダンス：安全な運用ルール

チェックポイントメカニズムを理解した後、日常運用を導くいくつかのルールをまとめることができます。

  1. プロセスを信頼し、手動コピーを避ける: dirchkディレクトリを手動でコピーしてOGGプロセスを「復旧」または「移行」しようとしないでください。チェックポイントファイルには大量の環境関連情報が含まれており、直接コピーするとほぼ確実に問題が発生します。正しいアプローチは、OGGの標準プロセス（ALTERコマンドなど）を使用してプロセス位置を管理することです。

  2. チェーン整合性: チェックポイントはExtract -> Pump -> Replicatチェーンに沿って伝播します。下流プロセス（Replicatが消費する位置）のチェックポイントは、上流プロセス（PumpとExtract）に逆方向に通知し、どのTrail Fileが「安全にクリーンアップできる」かを伝えます。これがPURGEOLDEXTRACTSコマンドのUSECHECKPOINTSパラメータの原理です。したがって、問題のトラブルシューティングを行う際は、常にデータチェーンを全体として扱ってください。

  3. リセット操作の確認: ALTER ... BEGIN ...やALTER ... EXTSEQNO ...などのコマンドを実行する前に、自分に3つの質問をしてください：

    • この操作によってどのデータがスキップされるかを明確に知っていますか？
    • ターゲットデータの状態は既に設定したい新しい開始点と一致していますか？
    • ロールバック計画はありますか？ チェックポイントへの深い理解は、これら3つの質問に自信を持って答えるための基盤です。

まとめ

本記事は、OGGの高信頼性の核心—チェックポイントメカニズムを徹底的に分析しました。これは単一の「ポイント」ではなく、複数のファイルとプロセス間の精密な協調システムです。

その核心概念を振り返りましょう：

ファイル/メカニズム 役割 解決する問題
.cpeファイル Extractのナビゲーションログ ログ読み取りの精密位置を記録し、Extractが再起動後に再読み取りや読み取り漏れを避けることを保証します。
.cprファイル Replicatの作業台帳 Trail File内の適用済みトランザクションの位置を記録し、Replicatが再起動後に再適用することを防ぎます。
.cptメカニズム 長いトランザクションのバッファ 大規模トランザクション内の処理進捗を記録し、トランザクションレベルでの精密なブレークポイント復旧を実現し、これが「重複なし、欠落なし」の本質です。

このシステムにより、OGGプロセスは単純な「読み書きプログラム」から、強力なメモリと復旧機能を持つ「インテリジェントエージェント」に進化します。状態を正確に記録し復旧するこの能力により、OGGは様々な異常事態下でもデータ同期の使命を確実に果たすことができます。

今、もし「OGGプロセスがクラッシュした場合どうすればよいか」と質問された時、あなたは自信を持って「再起動するだけで大丈夫」と答えるだけでなく、その背後にある強力な技術原理を明確に説明することもできるでしょう。