これまで手掛けた数多くのOGGプロジェクトの中で、今でも記憶に残っているケースがあります。コストをかけたクロスプラットフォームデータセンター移行プロジェクトが、最終データ同期段階で完全に停滞してしまったのです。ソース側のExtractプロセス（IBM Powerサーバー上）は順調に動作しており、トレイルファイルも継続的に生成されていました。しかし、ターゲット側のReplicat（x86 Linuxクラスター上）は全面的に失敗し、ログには様々な解析不能なエラーが記録されていました。チームは2晩徹夜で対応しましたが、進展はまったく見られませんでした。
最終的な原因は、誰もが「ブラックボックス」として当然視していたものの内部にある、些細でありながら致命的な詳細、つまりOGGトレイルファイルでした。
多くのOGGユーザーにとって、トレイルファイルはExtractとReplicatを接続する単なるパイプラインです。その存在は知っていても、実際に深く理解している人はほとんどいません。私たちの知識の盲点は、通常のシナリオでは無害かもしれませんが、複雑な移行やアップグレードプロジェクトでは、大きな問題を引き起こす可能性があります。本日はlogdumpの出力を用いながら、OGGのトレイルファイルを徹底的に解明していきます。
1. 「ブラックボックス」への深堀り：LOGDUMPでトレイルファイルを解析する
まず、よくある誤解を正しましょう：トレイルファイルは混沌としたバイナリデータの塊ではありません。そこには洗練された、明確に定義された内部構造が存在しています。
OGG には、トレイルファイルの内部を解析するための強力な診断ツールLOGDUMPが用意されています。では、先ほどの例のlogdump を使って、レコードごとにその内容を読み解いていきましょう。
トレイルファイルの論理構造
第1ステップ：ファイルヘッダー（FileHeader）
2025/07/05 13:41:24.857.026 FileHeader Len 1370 RBA 0
Name: *FileHeader*
...
uri:ole810::acfsogg:oggp:EXT_PG6
...
これはすべてのトレイルファイルの冒頭部分です。logdumpは、ファイルの先頭（RBA 0、相対バイトアドレス）に、長さ1370バイトのFileHeaderレコードがあることを示しています。これは本の著作権ページのようなもので、ファイルの「出所」を記録しており、以下を含みますがこれに限定されません：
-
生成情報:
uri:ole810::acfsogg:oggp:EXT_PG6は、このファイルがホストole810の/acfsogg/oggpにあるOGGインスタンスのExtractプロセスEXT_PGによって生成されたことを明確に示しています。 - OGGバージョン: 直接表示されていませんが、バージョン情報はバイナリデータにエンコードされています。
- エンディアン: 同様に内部にエンコードされており、後続のマルチバイトデータがどのように解釈されるかを決定します。
第2ステップ：メタデータレコード
データ操作の前に、OGGは後続のデータ解析のための「コンテキスト」を提供するために、いくつかのメタデータレコードを書き込みます。
データベースレベルのメタデータ：
2025/07/05 14:53:15.399.670 Metadata Len 90 RBA 1439
Database type: POSTGRESQL
Character set ID: UTF-8
TimeZone: GMT+08:00
このレコードは、データソースがPOSTGRESQLデータベースであり、文字セットがUTF-8、タイムゾーンがGMT+08:00であることを示しています。この情報は、異なるプラットフォームや文字セット間でデータを正しく解析するために不可欠です。
テーブル定義レコード（TDR）：
2025/07/05 14:53:15.399.671 Metadata Len 261 RBA 1580
Table Name: source_schema.source_table
...
Columns: 4
id 134 23 0 0 0 0 0 8 8 ...
name 64 300 11 0 0 1 0 300 300 ...
...
これはトレイルファイルの非常に重要な部分です。OGGは各テーブルの構造定義（テーブル名、列数、列名、データ型、長さなど）をトレイルファイルに書き込みます。Replicatプロセスがデータを適用する際、まず対応するTDRを検索し、この「マップ」を使用して後続のデータレコードを解析します。これが、ソースとターゲットのテーブル構造が同一でなくても、OGGがCOLMAPを使用してデータをマッピングできる理由です。
第3ステップ：DMLレコード
これはトレイルファイルの中核となる内容で、実際のデータ変更を記録しています。
2025/07/05 14:53:15.309.792 Insert Len 114 RBA 1918
Name: source_schema.source_table (TDR Index: 1)
After Image: Partition x0c G b
...
GGS tokens:
7401 0000 ... 4c00 1100 ... 3030 ... 2f30 4335 3832 3844 3836
このレコードを詳しく分析しましょう：
-
操作タイプ:
Insert、これは挿入操作です。 -
レコード長と位置:
Len 114 RBA 1918、長さは114バイト、位置1918から始まります。 -
関連テーブル:
Name: source_schema.source_table、そして(TDR Index: 1)を介して以前に定義されたTDRを指しています。 -
イメージ:
After Image、INSERT操作なので、変更後のデータイメージのみが含まれます。 -
GGS Tokens: このセクションには、PostgreSQLのLSN（Log Sequence Number）
0/C5828D86などの豊富なトランザクション情報が含まれており、これがリカバリチェックポイントの実装とデータ一貫性の確保の鍵となります。 -
列データ:
logdumpはnew_user_1など、各列の値を便利に解析してくれます。
logdumpを使うことで、トレイルファイルは見通しの良い状態になりました。
2. バージョン互換性：「タイムマシン」の正しい使い方
「19cのExtractで生成されたトレイルファイルは、12cのReplicatで読み取れますか？」
これは、バージョンアップグレードのコンサルティングで頻繁に尋ねられる質問です。
答えは：おそらく可能ですが、OGGにそうするように指示する必要があります。
OGGが進化するにつれて、トレイルファイルのフォーマットも新しいデータ型、圧縮アルゴリズム、または機能をサポートするために進化します。デフォルトでは、新しいバージョンのOGGは新しいフォーマットのトレイルファイルを生成し、古いReplicatはそれを認識できない可能性があります。
これを解決するために、OGGは「タイムマシン」パラメータを提供しています：FORMAT RELEASE。これをExtractまたはData Pumpのパラメータファイルで指定することで、プロセスに下位互換性のある古いフォーマットのトレイルファイルを生成させることができます。
-- ExtractまたはPumpのパラメータファイルに追加
-- OGG 12.3と互換性のあるトレイルファイルフォーマットの生成を強制
EXTRACT epump
USERIDALIAS ogg_admin_alias DOMAIN OracleGoldenGate
RMTHOST target_server, MGRPORT 7809
-- ここでのFORMAT RELEASEが鍵
RMTTRAIL /u01/app/ogg/dirdat/rt, FORMAT RELEASE 12.3
TABLE hr.*;
アドバイス：混合バージョンのOGG展開では、データフローの方向（ExtractからReplicatへ）において、FORMAT RELEASEのバージョン番号をチェーン内の最も低いバージョンのOGGコンポーネントに設定することです。これにより、スムーズなデータフローが保証され、フォーマットの非互換性によるプロセスの失敗を防ぎます。
3. クロスプラットフォーム移行の「隠れたキラー」：エンディアン
さて、記事の冒頭で述べた移行プロジェクトの失敗の謎を解き明かしましょう—エンディアンです。
コンピュータアーキテクチャにおけるこの基本的な概念は、多くのエンジニアにとって盲点です。簡単に言うと、マルチバイトのデータ（4バイトの整数など）がメモリにどのように格納されるかを決定します：
- ビッグエンディアン: 最も重要なバイトが最も低いメモリアドレスに格納されます。これは人間の読み方の習慣と一致します。例としては、IBM PowerやSPARCサーバーがあります。
- リトルエンディアン: 最も重要でないバイトが最も低いメモリアドレスに格納されます。例としては、Intel x86やAMD64アーキテクチャのサーバー（私たちが日常的に使用するPCやほとんどのLinux/Windowsサーバー）があります。
ビッグエンディアンのマシン（OGGトレイルファイルなど）で生成されたバイナリファイルを、リトルエンディアンのマシンに直接コピーして読み取ると、すべてのマルチバイトデータが誤って解釈され、「宇宙人の文字」のように見える意味不明なものになります。
落とし穴を避ける方法
scpやftpのようなファイルコピー方法を使って、バイトオーダーの異なるプラットフォーム間でトレイルファイルを手動で転送してはなりません！
正しいアプローチは、常にOGGのData Pumpプロセスを使用してこの転送を処理することです。Pumpはこの問題を念頭に置いて設計されています。PumpがリモートのManagerプロセスに接続すると、それらは「ハンドシェイク」してプラットフォーム情報を交換します。Pumpがソースとターゲットのバイトオーダーが異なると検出した場合、ネットワーク伝送中に自動的かつ透過的にバイトオーダー変換を実行します。
このプロセスはユーザーにはシームレスに見えますが、実はクロスプラットフォームデータ同期を成功させるための重要なメカニズムなのです。記事の冒頭で紹介したプロジェクトが失敗した理由は、この仕組みをショートカットしてscpで直接トレイルファイルをコピーしたため、まさにこの落とし穴にはまってしまったからです。
4. 混沌から秩序へ：トレイルファイル運用のベストプラクティス
内部メカニズムを理解するだけでは不十分です。OGGシステムの安定した運用を保証するためには、一連の効果的な管理プラクティスも必要です。
-
ディスクの「爆発」を避けるための自動クリーンアップ
トレイルファイルは継続的に生成されます。管理しないと、最終的にディスクをいっぱにしてしまいます。OGGは自動クリーンアップのためにPURGEOLDEXTRACTSコマンドを提供しています。これをManagerのパラメータファイルに設定し、グローバルな自動ガーディアンタスクにすることを強くお勧めします。
-- mgr.prmに追加
-- 毎日自動的にチェックしてパージし、最後の72時間のトレイルファイルを保持
-- USECHECKPOINTSはReplicatによって処理されたログのみがパージされることを保証
PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 72
-
合理的なストレージ計画（NFS）
RAC環境では、トレイルファイルを高性能なNFS共有ストレージまたはASMディスクグループから切り出されたACFSファイルシステムに配置することは、非常に一般的なベストプラクティスです。利点は、RACノードがフェイルオーバーしたときに、Extractプロセスが新しいノードでシームレスに引き継ぎ、中断したところからトレイルファイルへの書き込みを続けることができるため、フェイルオーバーの複雑さが簡素化されることです。ただし、NFSのパフォーマンスとマウントパラメータ（rsize、wsizeなど）はOGGのパフォーマンスにとって重要であることに注意してください。 -
ファイルサイズとローテーションの制御
ExtractパラメータファイルのMEGABYTESオプションを使用すると、個々のトレイルファイルのサイズを制御できます。指定されたサイズに達すると、自動的に次のファイルに切り替わります。これは、後続のファイル管理とトラブルシューティングに役立ちます。
まとめ
私たちはlogdumpを用いて、OGG のトレイルファイルを徹底的に解析しました。ここで、重要なポイントを簡単に振り返ってみましょう。
-
構造化されている: トレイルファイルは明確な「ファイルヘッダー -> メタデータ -> データレコード」構造を持っています。
LOGDUMPは、その内部を探り、バイナリデータを読み取り可能な情報に変えるための必須ツールです。 -
バージョン: OGGのバージョンが異なれば、使用するトレイルファイルのフォーマットも異なる場合があります。混合環境では、互換性を確保するために常に
FORMAT RELEASEパラメータを使用してください。 - プラットフォームに: エンディアンはクロスプラットフォーム移行の「隠れたキラー」です。バイトオーダーの異なるプラットフォーム間でデータを転送するには、必ずData Pumpを使用しなければなりません。
-
管理が鍵: 自動クリーンアップ（
PURGEOLDEXTRACTS）と適切なストレージ計画は、システムの長期的な安定性の基礎です。
OGGトレイルファイルは、データ同期プロセス全体の生命線です。それを理解し、尊重し、科学的に管理することは、OGGの「ユーザー」から「エキスパート」へと成長する旅の重要な一歩です。