※ 本記事は、Michael Papioによる”GoldenGate Best Practices: A Blueprint for Stability, Integrity and Scale“を翻訳したものです。

2026年3月5日

はじめに
OCI GoldenGateサービスへの移行にあたって、「フルマネージド」を「一度設定したらあとは放っておける」ことだとみなしたくなる危険な誘惑があります。デプロイメントのコンピュート、パッチ適用およびスケーリングはOracleが管理しますが、データ・パイプラインの論理構成はユーザーの責任のままです。レプリケーション・ストリームは、何カ月も「正常」に機能しているように見えても、特定の負荷の急増や長時間実行されるトランザクションが突然その安定性を打ち砕き、基盤に潜む亀裂を露呈させることがあります。

最近、ミッションクリティカルなOCI GoldenGateデプロイメントに対する重点的なアーキテクチャおよび構成レビューを実施し、構成の健全性、パフォーマンスの適合、運用レジリエンスにわたってベストプラクティスに基づく複数の改善機会を特定しました。これは一般的なヘルス・チェックではなく、サービス・レベル構成、ExtractおよびReplicatのパラメータ・ファイル、レポート・ファイル(.rpt)およびエラー・ログ(ggserr.log)に重点を置いたOCI GoldenGate Microservices Architecture (GGMA)デプロイメントのフォレンジック形式のレビューでした。

その目的は、システムを単なる機能状態から最適化されたベスト・プラクティス・アーキテクチャに移行することでした。デプロイメント環境は非常に変動しますが、この分析では、GoldenGate環境での構成管理、リソースのチューニングおよびデータの整合性の維持に関するいくつかの主要なベスト・プラクティスが特定されました。

この投稿では、安定性、パフォーマンス、長期的なメンテナンス性のためにOCI GoldenGate実装を最適化する方法について、これらの重要な教訓について説明します。

1. 構成の健全性: ミニマリズムの芸術

長年にわたる環境で最も一般的な問題の1つは、「パラメータの肥大化」です。これは、レガシー設定、冗長パラメータ、または長い間忘れられてきたチューニング試行を含む構成です。このレビューでは、よく意図されたオーバーライドが実際にはデフォルトの動作をハードコーディングし、値なしでノイズを追加しているパラメータファイルを観察しました。

ゴールデン・ルール: GoldenGateのデフォルト・パラメータ値は、各リリース、リリース更新(RU)またはパッチで定期的に拡張されるため、パフォーマンスと信頼性が向上することがよくあります。可能な場合は常に、最新のベスト・プラクティスと製品の最適化が反映されるため、現在のデフォルト設定を利用します。パラメータの追加は、その理由が文書化された特定の場合にのみ行います。

  • デフォルト・パラメータ値の埋込み: GoldenGateパラメータには通常、一般的なユース・ケース用にすでに最適化されているデフォルト設定があることに注意してください。このレビューでは、構成に明示的に定義されているLOGALLSUPCOLSやUPDATERECORDFORMAT COMPACTなどのパラメータを特定しました。統合Extractはデフォルトですべてのサプリメンタル列を取得し、圧縮形式を自動的に使用するため、それらをハードコーディングすると不要な混乱が発生します。
    • ベスト・プラクティス: 構成ファイルを無駄にしないでください。よりクリーンなファイルは、読み取り、デバッグ、およびアップグレードが容易です。デフォルトの動作は、ほとんどの環境のワークロード要件にすぐに対応するように設計されていることを信頼してください。
  • キー・パラメータのオーダー・マター: GoldenGate構文には柔軟性がありますが、特定のキー・パラメータは、正しく機能するために構成ファイルに特定の順序が必要です。
    • キーの例 (暗号化): ENCRYPTTRAILは、暗号化するEXTTRAILパラメータの直前に宣言する必要があります。
    • 技術要件: GoldenGateは、パラメータを順番に処理します。証跡定義の前にENCRYPTTRAILを配置すると、証跡ファイルが初期化される正確な時点で暗号化ルールがアクティブになります。
    • ベスト・プラクティス: 連続するブロックに依存するパラメータを定義します。将来の更新で論理的な断片化を防ぐため、ENCRYPTTRAILとEXTTRAILの間に無関係な設定を置かないでください。
  • パラメータへのコメント: デフォルト以外のパラメータ設定を構成する場合は、日付およびサポート・チケット(SR)やバグ番号など、簡単な説明または参照情報を含めます。組織のセキュリティ・ポリシーで許可されている場合は、作成者の名前またはイニシャルを含めることができます。それ以外の場合は、セキュリティのベスト・プラクティスに厳密に準拠し、パラメータ・ファイルに個人識別可能情報(PII)が記録されないようにします。
    • リアルワールドの例: CHUNK_SIZE設定が10GBであることが確認されました。特定のユース・ケースで有効ですが、このようなデフォルト以外の値には、将来の管理者に設計意図が明確になるようにドキュメントが必要です。
    • ベスト・プラクティス: アプリケーション・コードと同じ厳密な構成ファイルを処理します。特定のチケット番号または技術的な理由を参照するコメントを追加して、将来の管理者がその意図を理解できるようにします。

2. パフォーマンス・チューニング: ターゲットの適切なサイズ設定
Oracle Cloud Infrastructure (OCI)を利用する場合、容量はOCPUで測定されます。Oracle CloudのOCPUは、ハイパースレッドが使用可能なプロセッサの1物理コアに相当するCPU性能として定義されます。ターゲット・データベース・サービスの特定の容量制限を考慮することが重要です。Replicat構成は、最適な安定したパフォーマンスを確保するために、ターゲット・データベース・サービスで使用可能な実際のコンピュートおよびリソース容量と連携する必要があります。

  • 並列度の最適化: データ駆動型のアプローチ 初期デプロイメント時のCPU数のみに基づいて高い並列度値を任意に設定することは避けてください。
    • ベスト・プラクティス・ワークフロー:
      • デフォルトで開始: パフォーマンス・ベースラインを確立するには、デフォルトの並列度設定から開始します。
      • 測定および調整: Replicatがトランザクション・ボリュームに対応できない場合(ラグの増加)は、最初にターゲット・データベース、ネットワークまたはストレージがパフォーマンス制限要因であるかどうかを調査します。これらのリソースを決定した後にのみ、スループットを最適化するために並列度を増大させるとボトルネックになりません。
      • 戦略の選択:
        • 固定並列性: これは、ワークロードが厳密に予測可能で既知である場合にのみ使用します。これによりリソース使用率は安定しますが、柔軟性に欠けます。トランザクション・ボリュームを変更する場合は、APPLY_PARALLELISM値を手動で調整するプロセスを停止する必要があります。
        • 動的パラレル化(ほとんどのワークロードで推奨): Replicatが自己チューニングできるように、特定の範囲(MIN_APPLY_PARALLELISM 2、MAX_APPLY_PARALLELISM 8など)を設定します。これにより、ワークロード・パターンの変動に伴って反復的な手動チューニング(停止/起動)が不要になります(パラメータの詳細は、Oracle GoldenGateのドキュメント: https://docs.oracle.com/en/middleware/goldengate/core/23/reference/apply_parallelism.html を参照してください)。
  • BATCHSQL構成の標準化 高スループット・レプリケーションのBATCHSQLを有効にします。これは、ほとんどのワークロードで推奨される標準です。
    • 例外: ワークロードで頻繁な一意制約違反またはデータ競合が発生する場合は、BATCHSQLを無効にする必要があります。これらのシナリオでは、Replicatはバッチをロールバックし、トランザクションを個別に再試行する必要があるため、BATCHSQLは標準モードより低速で実行されます。
    • セカンダリ・プロセスへの影響 セカンダリまたはメンテナンスに重点を置いたプロセス(一括削除操作を処理するプロセスなど)でも、この最適化が必要です。これらのプロセスをバッチ処理せずにシングルスレッド・モードで実行すると、多くの場合、データベース・コンテキストのスイッチおよびネットワーク・ラウンドトリップの増加により、大きなレイテンシが発生します。
    • ベスト・プラクティス 特定の技術的除外が適用されないかぎり、すべてのReplicatプロセスでBATCHSQLが有効になっていることを確認します。

3. データ整合性: 「厳密整合性」標準
ミッションクリティカルな財務システムの場合、データの整合性は可用性よりも優先されます。構成では、異常を調査するためにプロセスを停止する必要がある場合でも、ターゲット・データがソースの正確なトランザクション・レプリカであることを確認する必要があります。

  • ソース整合性: スナップショットベースの抽出 トランザクションの一貫性を保証するために、Extractプロセスは、現在の行バージョンをフェッチするのではなく、特定のSCN (システム変更番号)時点のデータ状態を再構築する必要があります。
    • リスク: 過去のトランザクションの現在のデータをフェッチすると、将来のデータ(元のトランザクションの後にコミットされた更新)が発生し、トランザクションの整合性が損なわれる可能性があります。
    • 構成: ソース・データベースのUNDOセグメントを使用して読取り一貫性イメージを作成するようExtractに指示するには、FETCHOPTIONS USESNAPSHOTを使用します。
      • USESNAPSHOT: ソース・データベースのUNDOセグメントを使用して読取り一貫性イメージを構築するようにExtractに指示します。
      • NOUSELATESTVERSION: スナップショットの再構築が失敗した場合(特に、保存制限のために必要なUNDO情報が上書きされた場合)は、Extractが現在の行バージョンを明示的にフェッチしないようにします。
      • MISSINGROW ABEND: 一貫性のある行イメージ(特定のSCN)を再構築できない場合、Extractを強制的に終了します。このパラメータを使用しない場合、プロセスはデフォルトで操作をスキップし(警告のみをロギング)、サイレント・データの相違が発生する可能性があります。
    • 前提条件: ソース・データベースUNDO_RETENTIONがレプリケーション・ラグに対応するようにサイズ設定されていることを確認し、RETENTION GUARANTEEが有効になっていることを確認します。
  • ターゲットの整合性: 「データが見つかりません」の処理 ターゲットにデータを適用する場合、ORA-1403 (データが見つかりません)の処理は重要な決定ポイントです。
    • 厳格な整合性: REPERROR (1403, IGNORE)またはDISCARDを使用しないでください。これらの設定により、欠落しているレコードをサイレントにスキップすることでデータの相違が可能になります。
    • ベスト・プラクティス: REPERROR (DEFAULT, ABEND)を構成します。これにより、データの不一致が発生するとReplicatがただちに停止し、問題が複雑化するのを防ぎます。
    • 解決策: 管理者は、プロセスを再起動する前に、欠落しているレコードを手動で調査して整合性を回復する必要があります。

4. 運用の健全性: 可観測性とライフサイクル管理
長期的な安定性を確保するには、監視、メンテナンスおよびアーキテクチャ標準に対する積極的なアプローチが必要です。

  • ライフサイクル管理: パッチ適用とアップグレード OCI GoldenGateはマネージド・サービスですが、アップグレードのタイミングは、アプリケーションの互換性を確保するお客様の責任となります。運用上のセキュリティと安定性は、サポートされているソフトウェア・ベースラインの維持に依存します。
    • 定期的なパッチ適用: クリティカルなバグ修正とセキュリティ・パッチを取り込むために、四半期ごとのマイナー・バージョン更新をスケジュールすること。
    • メジャー・アップグレード: 非推奨のコード・パスで実行されないように、メジャー・バージョン・アップグレード(たとえば、19cから23ai)を「Sustaining Support」期限の直前に計画します。
  • ハートビート監視: ラグ・ビジュアライゼーション 標準の「チェックポイントでのラグ」メトリックは、トランザクション量が少ない期間に誤解を招く可能性があります。正確な可観測性を確保するには:
    • ハートビートの有効化: ネイティブのADD HEARTBEATTABLE機能を活用します。これにより、定期的なダミー・トランザクションが生成され、アイドル期間中でもチェックポイントが強制的に進められます。
    • 利点: これにより、真のエンドツーエンド・レイテンシ・メトリックが提供され、チェックポイントを更新するための新しいデータが到着していないため、ラグが急増しているように見える偽陽性が回避されます。LAG REPLICATコマンドと直接統合され、自動履歴パージが処理されます。
  • プロセスの表示: スループット・メトリック ハートビート表はレイテンシを測定しますが、スループット・ボリュームを理解することは、容量計画にとって重要です。
    • ベスト・プラクティス: ExtractおよびReplicatのパラメータ・ファイルでREPORTCOUNTを構成し、処理統計をレポート・ファイル(.rpt)に直接出力します。
    • 構成: RATEオプションを使用して処理速度を計算します。
      • 例: REPORTCOUNT EVERY 15 MINUTES, RATE.
    • 重要な理由: これにより、処理スパイクの不変レコードが作成され、管理者はボリューム・サージとシステム・リソース消費を関連付けることができます。
  • アーキテクチャ標準: ハイブリッド・トポロジのMAAモデル ハイブリッド・トポロジおよびマルチクラウド・トポロジ(AWSソースからOCIターゲットなど)では、GoldenGate Hub (GGHub)の物理的な配置が、パフォーマンスにとって最も重要な唯一の要素です。OCI GoldenGateはサード・パーティ・クラウド内でローカルに取得できないため、ソース・データベースが存在する同じリージョンまたはデータセンターにGGHubをデプロイする必要があります。これにより、取得プロセスまたは配信プロセスが、必要な低レイテンシしきい値内で動作することが保証されます。
    • 「リモート配信」アンチパターン: ワイド・エリア・ネットワーク(WAN)間でトランザクションを適用するようにReplicatを構成しないでください。
      • リスク: Replicatプロセスは、ネットワーク・レイテンシに非常に敏感です。Oracle MAA標準によると、ラウンドトリップ・レイテンシが4ミリ秒以下になるように、プライマリまたはアクティブなGGHubはターゲット・データベースと同じデータ・センターに存在する必要があります。この制限を超えると、プロセスが各バッチでSQLNET確認を待機するため、パフォーマンスが低下します。
    • MAA標準: Split-Hubアーキテクチャ リージョン間またはマルチクラウド・レプリケーションの場合、レイテンシがしきい値を超えると、Split-Hub設計(ソースGGHub +ターゲットOCI GGSデプロイメント)が堅牢な標準となります。
      • しきい値の抽出: リモートExtract (単一ハブ)は、レイテンシが90ミリ秒未満の場合は技術的にサポートされますが、パイプラインはWANの変動に対して脆弱になります。
      • Decouplingの利点: 特定のGoldenGateハブをソース・クラウド/リージョンに配置することで、Extractがローカルで動作している(待機時間が4ミリ秒未満)ことを確認し、クロスクラウド・ネットワークからキャプチャ・パフォーマンスを完全に切り離します。
      • 分散パス: その後、データはDistribution Serverを介して非同期に転送されます。Distribution Serverは高いネットワーク・ジッターに対する自己回復性のために最適化されます。

        計画のガイドラインの詳細は、Oracle MAAのドキュメントを参照: Planning GGHub Placement in the Platinum MAA Architecture.

まとめ
OCI GoldenGate実装を機能状態から最適化された標準に変換するには、構成のベスト・プラクティスに規律的に焦点を当てる必要があります。

  • 構成の健全性: パラメータbloatを削除し、最適化されたデフォルトに依存します。
  • パフォーマンス: ターゲット・データベースの容量に基づいて並列性をチューニングし、BATCHSQLを使用します。
  • データ整合性: スナップショットベースの抽出および明示的なABEND処理を使用して、厳密な一貫性を強制します。
  • アーキテクチャ: CaptureをDeliveryから分離するためにMAA Split-Hub標準を採用し、Source Hubがソースの90ms内に存在することを確認し、Target Hubはターゲットの4ms内に存在してパフォーマンスの低下を防ぎます。

これらの柱を標準化することで、デプロイメントはベースライン構成から回復力のあるエンタープライズ・グレードのアーキテクチャへと進化します。