実践Oracle GoldenGate：15年のゼロダウンタイム移行とアップグレードの実績

皆さんこんにちは、Shaneです。私はIT業界に約20年間携わってきましたが、そのうち15年間はOracle GoldenGate（以下、OGGと呼びます）と深く関わってきました。OGGは私にとって、命の恩人であり、同時に挑戦的なパートナーでもあります。初期の小規模サーバーでのデータ同期から、現在ではテラバイト規模のコアシステムを様々なプラットフォームやバージョンでゼロダウンタイムで移行するまで、OGGは私にとって強力で複雑なツールです。今日は、私がOGGのゼロダウンタイムデータ移行とアップグレードプロジェクトを管理してきた15年の間に学んだ「舞台裏の詳細」と「教訓」を共有したいと思います。

導入：「ダウンタイム」が耐えられない負担になるとき

「来四半期にデータベースプラットフォームのアップグレードを完了する必要がありますが、コアビジネスは一秒たりとも中断することが許されません！」―この文は、多くのDBAやプロジェクトマネージャーを悩ませるおなじみの句であると思います。現代は、24時間365日無停止サービスが求められる時代です。従来の保守管理ウィンドウは負担できないコストになってしまいました。Oracle GoldenGateの登場は間違いなく、「ゼロダウンタイム」あるいは「ほぼゼロに近いダウンタイム」の移行やアップグレードを実現する「金の鍵」を提供しました。
とはいえ、この鍵を手に入れたからといって、誰もが簡単に使いこなせるわけではありません。成功には、綿密な計画、細部にわたる注意力、そして潜在的リスクへの深い理解と備えが不可欠です。この15年間で、私はOGGが数々の「不可能な任務」を達成するのを目にしてきましたが、些細な詳細を見落とすことによる「真夜中に冷や汗をかくようなトラブル」に発展したことも何度か経験しました。

成功への設計図：戦略的計画が勝負の半分

成功するOGGゼロダウンタイム移行またはアップグレードプロジェクトは、綿密な事前計画にかかっています。これは単にソフトウェアをインストールして、いくつかのパラメータを調整するだけではありません。

現状の把握と目標の明確化

まず、ソースデータベースの「資産」を包括的に把握する必要があります。例えば：バージョン、パッチレベル、文字セット、オペレーティングシステム、ストレージタイプ、ネットワークトポロジー、データ量（特に非常に大きなテーブルやLOBオブジェクト）、およびトランザクション負荷（TPS、リドログ生成率）。同様のことがターゲット環境にも適用され、バージョンの違いから生じる互換性の問題に注意を払う必要があります。私はかつて、AIX上のOracle 11gからLinux上の19cへ、異なる文字セットで移行するプロジェクトに携わったことがあります。事前の互換性検証に多大な工数を要しました。

OGGは万能薬ではありません。プロジェクトの初期段階では、公式ドキュメントを綺密に参照し、サポートされていない、または制限されているデータ型（特定のユーザー定義型やXMLTypeの特定のストレージ方法など）やデータベース機能（特定の暗号化方法など）を特定することが重要です。これらを早期に発見することで、適切な代替ソリューション（例えば、事前変換やカスタム処理）をタイムリーに提供し、最終段階での混乱を避けることができます。

「ゼロダウンタイム」は相対的な概念です。これはユーザーに完全に気づかれないことを意味するのでしょうか？それとも、アプリケーション層での短い読み取り専用期間や接続切り替えを許容するのでしょうか？これはその後の切り替え戦略に直接影響します。ビジネス関係者と完全にコミュニケーションを取り、コンセンサスを得ることが不可欠です。

初期ロード戦略：千里の旅の最初の一歩

初期ロードとは、その名前が示す通り、既存のデータをソースデータベースからターゲットに「移動」するプロセスで、その後の増分同期の基準となります。

一般的な方法は以下の通りです：

• OGG直接ロード（Replicat経由）： 小規模なデータ量と単純なテーブル構造のシナリオに適しています。利点はOGGのネイティブサポートですが、比較的効率が悪く、ターゲット側で大量のリソースを消費します。
• データベースネイティブツール + SCN/タイムスタンプ同期ポイント（例：Data Pump、RMAN）： これは私がほとんどのプロジェクトで好む方法です。Data Pumpエクスポート/インポートやRMAN異機種リストアを活用することで、非常に効率的で信頼性が高くなります。重要なのは、エクスポート/リストア完了時にSCN（System Change Number）またはタイムスタンプを正確に記録することで、そこからOGG Extractプロセスが増分データをキャプチャします。ここでの「落とし穴」はSCNの正確な取得と適用にあり、わずかなミスがデータの損失や重複につながる可能性があります。
• ファイルからReplicatへ： 中間的なアプローチで、まずデータをファイルにエクスポートし、その後OGG Replicatを介してロードします。

考慮すべき要因には、データ量、ネットワーク帯域、許可された初期ロードウィンドウ、およびソースシステムの負荷が含まれます。

増分同期設計：リアルタイムデータパイプラインの構築

補足ロギングはOGGの「目」です。複製されるすべてのテーブルに対して、ソース上で十分な補足ロギングを有効にする必要があり、OGGがリドログから変更されたデータ（主キー、一意インデックス列、すべての列など）に必要なすべての情報をキャプチャできるようにします。補足ロギングの構成が不適切で、データの欠落によりReplicatが頻繁にABEND（異常終了）するケースを見たことがあります。

Extractプロセス、データキャプチャのソース：

• クラシックキャプチャ vs. 統合キャプチャ（IC）： Oracle 11.2.0.4以降、ICが主流になりました。これはデータベースログストリーミングサービスから直接読み取り、特にRAC環境では、より良いパフォーマンスとソースへの影響が少ないという利点があります。しかし、古いバージョンや特定のシナリオでは、クラシックキャプチャにもまだ場所があります。
• Pumpプロセスは、データ送信の「宅配便」で、通常ソース上で構成され、ローカルトレイルファイルをネットワーク経由でターゲットに送信し、障害耐性と柔軟性を向上させます。

Replicatプロセス、データ適用の実行者：

• クラシックReplicat vs. 統合Replicat（IR） vs. 並列Replicat（PR）： IRはデータベースの内部并列処理メカニズムを活用し、より良いパフォーマンスを提供します。PRはユーザー定義の并列化を可能にし、特に多くの独立したテーブルを処理する場合により多くの柔軟性を提供します。選択はターゲットデータベースのバージョン、データの特性、およびパフォーマンス要件に依存します。

トレイルファイルはOGGの生命線です。これらのファイルはソースからキャプチャされたデータ変更を格納し、ExtractとReplicatの間の通信橋として機能します。それらの管理（サイズ、数、定期的なクリーンアップ）は非常に重要です。

重要なパラメータと設定：細部に潜む悪魔

OGGには何百ものパラメータがありますが、いくつかの重要な設定がプロジェクトの成否を左右することが少なくありません。ここでは、これまでの経験の中で特に注意を払ってきた「重要パラメータ」とその設定のヒントをご紹介します。

Extract側パラメータ

• FETCHOPTIONS USEMAPPEDTZ, FETCHBEFOREUPDATE: タイムゾーン変換の処理や更新の事前イメージの取得に不可欠で、異機種プラットフォームや複雑なデータ型にとって重要です。かつて、クロスタイムゾーンプロジェクトでUSEMAPPEDTZが誤設定され、タイムスタンプデータの不一致を引き起こしたトラブルシューティングに長時間費やしたことがあります。
• TRANLOGOPTIONS: 例えば、MANAGESECONDARYTRUNCATIONPOINT（Active Data Guard環境でのログ切捨ポイントを管理）、EXCLUDEUSER、EXCLUDETAG（特定のユーザーからの、または特定のタグが付いたDML操作を除外します。例えば、OGG Replicat自身からのループバックを防ぐため）。
• BR BROPTIONlevelname（境界復旧）: Extractのチェックポイント復旧動作を制御し、障害復旧時間に影響を与えます。
• WARNLONGTRANS: 長時間実行されるコミットされていないトランザクションを監視します。これらはしばしば、潜在的なパフォーマンスのボトルネックやExtractの遅延の原因となります。

Replicat側パラメータ

• BATCHSQL: これはReplicatのパフォーマンスを向上させる、まさに「核兵器」のようなパラメータです。複数のDML操作を単一のバッチでコミットするようにグループ化し、データベースとのやり取りのオーバーヘッドを大幅に削減します。しかし、使用には注意が必要です。過度な使用は個々のトランザクションのサイズを増大させ、エラー発生時の切り分けやリカバリ対応が難しくなる可能性があります。通常、私はターゲットデータベースの負荷とトランザクションの特性に基づいて小さな調整から始め、最適なバランスを見つけます。
• GROUPTRANSOPS: ソーストランザクションを単一のターゲットトランザクションにいくつ統合するかを制御し、BATCHSQLと連携して使用されます。設定値が高すぎると、ターゲット上で過度に大きなトランザクションが発生し、ロックの競合が増加する可能性があります。
• DBOPTIONS SUPPRESSTRIGGERS, DISABLECONSTRAINTS: 初期ロード中や特定のデータ修復フェーズ中にターゲットテーブル上のトリガーと制約を一時的に無効化することで、効率を向上させます。しかし、データの整合性を維持するために後で再び有効化することを確認する必要があります。私は制約を再有効化することを忘れてしまったことで、データ品質問題を引き起こしたという「痛い教訓」を得たことがあります。
• HANDLECOLLISIONS / REPERROR: エラー処理メカニズム。HANDLECOLLISIONSはターゲット上にデータが既に存在する場合に自動上書きを許可します（通常、初期ロード後の軽微な不一致を修正するために使用され、長期使用には推奨されません）。REPERRORはエラー発生時の動作（ABEND、DISCARD、OVERWRITE）を定義します。洗練されたエラー処理戦略は、安定したデータ同期を確保するための鍵です。
• DDLレプリケーション（DDLOPTIONS REPORTなど）: DDLレプリケーションはOGGの比較的複雑な部分です。その制限（すべてのDDL操作が完全に複製されるわけではない）を理解するには、徹底的なテストが不可欠です。DDLOPTIONS REPORTはDDL操作をレポートファイルに記録し、追跡とデバッグを支援します。一般的に、重要なDDL変更は依然として両端で手動かつ同期的に実行し、OGGは補助として機能させることをお勧めします。

グローバル設定のベストプラクティス

• ハートビートテーブル： これは私が強く推奨する「ベストプラクティス」です。ソース上のハートビートテーブルを定期的に更新し、ターゲット上でその更新時間を監視することで、エンドツーエンドのレプリケーション遅延を直感的に理解できます。これはOGGの健全性を示す最も直接的な指標です。
• パラメータファイル管理： OBEYファイルを使用してパラメータを整理し、機能ごとにモジュール化して読みやすさと保守性を高めます。パラメータファイルをバージョン管理し、すべての変更の記録を保持します。
• モニタリングとアラート： OGGの組み込みggsciコマンド、ログファイル、およびエンタープライズモニタリングツール（OEMのOGGプラグインやカスタムスクリプトなど）を活用して、Extract/Replicatプロセスのステータス、遅延時間、エラーなどのリアルタイムモニタリングとアラートを行います。問題が早期に発見されるほど、解決は容易になります。

切り替え戦略と検証：最終キックの技術

すべての準備が整ったら、後は切り替えだけです。これはプロジェクトの中で最も難易度が高く、そして最も興奮する部分であり、チームワークと適応能力の究極のテストでもあります。

最終切り替え前の準備

• 繰り返しの訓練： テスト環境で複数の完全な切り替え訓練を実施し、チームが各ステップに慣れるようにし、各ステップにかかる時間を記録します。
• データ整合性検証スクリプト/ツール： OGG Veridataなどのツールや、行数やコアテーブルの主要フィールドのSUM/AVGを比較するカスタムSQLスクリプトを準備します。これは信頼性を構築するために非常に重要です。
• アプリケーション層の連携： アプリケーションチームと緊密に連携し、アプリケーションを停止/読み取り専用に設定するタイミングと、切り替え後にアプリケーションを新しいデータベースに向けるための方法（接続文字列の変更、DNS切り替えなど）を正確に決定します。
• 遅延の最小化： 切り替えウィンドウの前にOGGの遅延を最小化し、理想的にはゼロにします。これは一時的にReplicatの並列性を高めたり、ネットワークを最適化したりすることで達成できます。

切り替えの実行

1. ソースシステムでのアプリケーションによる書き込みを停止し、すべてのトランザクションが完了していることを確認します。
2. OGG Extractをモニタリングし、すべてのリドログがキャプチャされたことを確認します。
3. OGG Replicatをモニタリングし、すべてのトレイルファイルが適用されたこと（遅延がゼロ）を確認します。
4. 最終的なデータ整合性チェックを実行します。これは決定的なステップです。検証中に軽微な不一致が発見され、切り替えを緊急停止して原因調査を行わなければならなくなったシナリオに遇ったことがあります。
5. アプリケーションの接続を新しいデータベースに切り替えます。
6. アプリケーションを開いて、ビジネス機能の検証を行います。

ロールバック計画

計画に最大限の自信があっても、包括的なロールバック計画は不可欠です。これは切り替え後に発生し、迅速に解決できない深刻な問題に対する緊急対策であり、ビジネス運用を素早くソースシステムに戻すことを可能にします。重要なポイントには、新しいデータベースから古いデータベースへ増分データを迅速に同期する方法（逆方向のOGGリンクを事前に構成する必要があるかもしれません）や、新しいデータベースを完全に放棄してアプリケーションを元のデータベースに戻す方法などが含まれます。ロールバック計画も訓練が必要です！

結論： OGGの旅 - 完全を求める探求

OGGとの15年間を経て、私は深く理解しました。すべてのゼロダウンタイム移行プロジェクトの成功の裏には、技術への敬意、細部へのこだわり、そしてシームレスなチームワークがあります。Oracle GoldenGateは強力なツールですが、それはより一つの「工芸」のようなもので、経験の経纏と絶え間ない改良を必要とします。最初のソースの探索と綺密な計画の反復から、パラメータの微調整、そして切り替えの締めくくりまで、すべてのステップが私たちのプロ意識と忍耐力を試します。これらの積み重ねてきた経験が、今まさにOGGに取り組んでいる、あるいはこれからその道を歩もうとしている皆さんにとって、少しでも参考や励みになれば幸いです。OGGの世界は広大で、課題にも可能性にも満ちあふれています。私たち全員がこの道を着実に歩み、さらなる前進し続けられることを願っています。