1. 高可用性概要およびベスト・プラクティス
  2. MAA PlatinumおよびOracle GoldenGateのベスト・プラクティス
  3. オンプレミス: Oracle GoldenGate Hubの構成
  4. タスク4: Oracle GoldenGate環境の構成

タスク4: Oracle GoldenGate環境の構成

このタスクを完了するには、次のステップを実行します。

  • ステップ4.1 - データベース資格証明の作成
  • ステップ4.2 - スキーマのサプリメンタル・ロギングの設定
  • ステップ4.3 - 自動起動プロファイルの作成
  • ステップ4.3 - Oracle GoldenGateプロセスの構成

ステップ4.1 - データベース資格証明の作成

Oracle GoldenGateデプロイメントを作成したら、Oracle GoldenGate管理サービスのホーム・ページを使用して、前述のTNS別名を使用してデータベース資格証明を作成します。

oggadminユーザーとして、データベース資格証明を作成します。

  1. 管理サービスにログインします: https://gghub.example.com:443/deployment_name/adminsrvr
  2. 「管理サービス」の「構成」をクリックします。
  3. 「データベース」タブの「資格証明の追加」のプラス(+)をクリックします。
  4. ソースおよびターゲットのCDBとPDBに必要な情報を追加します。
    データ・センター コンテナ ドメイン 別名 ユーザーID
    DC 1 CDB GoldenGate DC1_CDB c##ggadmin@<tns_alias>
    DC 1 PDB GoldenGate DC1_PDB ggadmin@<tns_alias>
    DC 2 CDB GoldenGate DC2_CDB c##ggadmin@<tns_alias>
    DC 2 PDB GoldenGate DC2_PDB ggadmin@<tns_alias>

ステップ4.2 - スキーマのサプリメンタル・ロギングの設定

  • Oracle GoldenGate管理サーバーにログインします
  • 「管理サービス」の「構成」をクリックします。
  • 「ソース・データベース」(Reg_CDB)の「アクション」の下の「データベースに接続」ボタンをクリックします。
  • 「スキーマ」または「表」のプラス・ボタン(TRANDATAの追加)をクリックしてTRANDATAを追加します。

ステップ4.3 - 自動起動プロファイルの作成

Oracle GoldenGate Administration Serverの起動時にExtractプロセスとReplicatプロセスを自動的に起動する、新しいプロファイルを作成します。その後、ExtractプロセスまたはReplicatプロセスが中止された場合は再起動します。GoldenGate Microservicesでは、自動起動と再起動はプロファイルによって管理されます。

Oracle GoldenGate Administration Server GUIを使用して、各Oracle GoldenGateプロセスに割り当てることができる新しいプロファイルを作成します。

  1. ソースおよびターゲットGoldenGateで、管理サービスにログインします。
  2. 「管理サービス」の「プロファイル」をクリックします。
  3. 「管理対象プロセスの設定」で「プロファイル」の横にあるプラス(+)記号をクリックします。
  4. 次に示すように詳細を入力します。
    • プロファイル名: Start_Default
    • 説明: デフォルトの自動起動/再起動プロファイル
    • デフォルト・プロファイル: はい
    • 自動開始: はい
    • 自動開始オプション
      • 開始の遅延: 1分
      • 自動再起動: はい
    • 自動再起動オプション
      • 最大再試行回数: 5
      • 再試行の遅延: 30秒
      • 再試行期間: 30分
      • 失敗時にのみ再起動: はい
      • 試行回数に達したらタスクを無効化: はい
  5. 「発行」をクリックします

ステップ4.4 - Oracle GoldenGateプロセスの構成

Oracle GoldenGate Microservices ArchitectureによるExtract、分散パスおよびReplicatプロセスの作成時に、GGHubノード間で共有する必要があるすべてのファイルは、すでに共有ファイル・システムに格納されているデプロイメント・ファイルによって共有されています。

Extract、分散パスおよびReplicatプロセスのためにGGHubでOracle GoldenGate Microservicesを実行する際にお薦めする基本的な構成の詳細を次に示します。

次のサブステップを実行して、このステップを完了します。

  • ステップ4.4.1 - Extractの構成
  • ステップ4.4.2 - Replicatの構成
  • ステップ4.4.3 - 分散パスの構成
  • ステップ4.4.4 - タイム・ラグをモニターするためのハートビート表の設定

主な目的は、GoldenGateレプリカとそれらに関連するスタンバイ・データベースとでデータに相違がないようにすることです。この項では、GoldenGate Extractがスタンバイ・データベースの先を行かないように(それによりデータの相違が発生する可能性がある) Extractを構成することに焦点を当てています。

GoldenGateパラメータ 説明 推奨事項
TRANLOGOPTIONS HANDLEDLFAILOVER

これは、Oracle GoldenGateを含むData Guard構成での、スタンバイ・データベースに受信されていないデータがGoldenGate Extractで抽出されないようにするための必須の設定です。HANDLEDLFAILOVERは、Data GuardフェイルオーバーのハンドルDATA LOSSを表します。トランザクションが失われないようにし、データ損失があるData Guardフェイルオーバー・イベントの後に論理データの不整合が発生しないようにするために、Extractプロセス・パラメータ・ファイルに次のパラメータを追加する必要があります。このパラメータが指定されていると、2つのプライマリで調整が試みられたときに、新しいプライマリ(古いスタンバイ)が想定どおりに遅れた状態でなくなると、すべてのトランザクションを調整できます。

Extractによってソース・データベースからREDOデータが抽出されることや、Oracle Data Guardスタンバイ・データベースにまだ適用されていないデータが証跡ファイルに書き込まれることを防ぎます。このパラメータが指定されていないと、データ損失があるフェイルオーバーの後に、ソース・データベース内に存在しないデータがターゲット・データベース内に保持される可能性があります。それにより、データの相違と論理データの不整合が発生します。

 最大可用性または最大パフォーマンス・モードのData Guardを使用するようにソース・データベースが構成されている場合は必須です。
TRANLOGOPTIONS FAILOVERTARGETDESTID n

複数のスタンバイ構成がある場合や、Data Guardファスト・スタート・フェイルオーバーが有効になっていない場合は、FAILOVERTARGETDESTIDを、LOG_ARCHIV_DESTによって区別されているスタンバイに設定して、ターゲット・スタンバイ・データベースに受信されていないデータがGoldenGate Extractで抽出されないようにします。FAILOVERTARGETDESTIDの適切な値を判断するには、ソース・スタンバイ・データベースへのREDOの送信に使用されるGoldenGateソース・データベースのLOG_ARCHIVE_DEST_Nパラメータを使用します。たとえば、LOG_ARCHIVE_DEST_2がスタンバイ・データベースを指している場合は2の値を使用します。

ソース・データベースでData Guardファスト・スタート・フェイルオーバー(FSFO)を使用していない場合、このパラメータでは、Oracle Data Guardスタンバイ・データベースにまだ適用されていないREDOデータを抽出しないようにするためにExtractプロセスがどのスタンバイ・データベースの後ろにとどまる必要があるかを特定します。

ソース・データベースでFSFOを使用しない場合は必須です。

FAILOVERTARGETDESTIDの適切な値を判断するには、ソース・スタンバイ・データベースへのREDOの送信に使用されるGoldenGateソース・データベースのLOG_ARCHIVE_DEST_Nパラメータを使用します。たとえば、LOG_ARCHIVE_DEST_2がスタンバイ・データベースを指している場合は2の値を使用します。
TRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_WARNING value ソース・データベースのスタンバイ適用の進行状況を問い合せることができないためExtractが止まっている場合に、警告メッセージがExtractレポート・ファイルに書き込まれるまでの時間。これは、古いプライマリ・データベースを現在使用できないときに、Data Guardフェイルオーバーの後に発生する可能性があります。デフォルトは60秒です。

オプション: 警告メッセージがExtractレポート・ファイルに書き込まれるタイミングを調整する必要がある場合。

STANDBY_WARNING <value>をTRANLOGOPTIONS HANDLEDLFAILOVERパラメータに追加します。
TRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_ABEND value スタンバイ適用の進行状況を問い合せることができないためExtractが止まっている場合に、Extractが異常終了するまでの時間。デフォルトは30分です。

オプション: HANDLEDLFAILOVERパラメータを強制適用するためにソース・データベースのスタンバイにアクセスできないときの、Extractが異常終了するまでの時間を調整する必要がある場合。

STANDBY_ABEND <value>をTRANLOGOPTIONS HANDLEDLFAILOVERパラメータに追加します。
TRANLOGOPTIONS DLFAILOVER_TIMEOUT value

Data Guardロール・トランジションの後、スタンバイ・データベースのステータスがチェックされる前の、新しいソース・プライマリ・データベースでExtractが実行される時間。DLFAILOVER_TIMEOUTの後にスタンバイ・データベースを使用できない場合、Extractは異常終了します。デフォルトは300秒です。

ノート: ソースOracle Data Guard構成の通常の処理の間にスタンバイ・データベースが使用不可になった場合、Extractでは、HANDLEDLFAILOVERパラメータに起因するGoldenGateターゲット・データベースとのデータ相違の可能性をなくすために、ソース・データベースからのデータの抽出が停止されます。DLFAILOVER_TIMEOUTパラメータは、Data Guardフェイルオーバーが発生しておらずExtractレポート・ファイルに出力されるメッセージがないときは効果がありません。

 オプション: ロール・トランジションの後の、TRANLOGOPTIONS HANDLEDLFAILOVERパラメータを適用するためにスタンバイをまだ使用できないときの、新しいプライマリ・ソース・データベースでExtractを実行可能な時間を調整する必要がある場合。

ExtractのTRANLOGOPTIONSパラメータの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

Oracle GoldenGate管理サービスのGUIを使用してExtractを作成するときは、Trail SubDirectoryパラメータを空白のままにして、証跡ファイルが、共有ファイル・システムに格納されているデプロイメント・ディレクトリに自動的に作成されるようにします。証跡ファイルのデフォルトの場所は、/<デプロイメント・ディレクトリ>/var/lib/dataディレクトリです。

ノート:

マルチテナント・データベースから取得するには、c##アカウントを使用してルート・レベルで構成したExtractを使用する必要があります。マルチテナント・データベースにデータを適用するには、PDBごとに個別のReplicatが必要になります。これは、ReplicatはPDBレベルで接続して、そのPDB以外のオブジェクトにアクセスできないためです。

ステップ4.4.1 - Extractの構成

  1. Oracle GoldenGate管理サーバーにログインします
  2. 「管理サービス」の「概要」をクリックします
  3. 「Extractの追加」のプラス(+)・ボタンをクリックします。
  4. 「統合Extract」を選択します
  5. 次のように必要な情報を追加します。
    • プロセス名: EXT_1
    • 説明: DC 1 CDBのExtract
    • 目的: 一方向
    • 開始: 今すぐ
    • トレイル名: aa
    • 資格証明ドメイン: GoldenGate
    • 資格証明別名: DC1_CDB
    • PDBに登録: PDB名
  6. 「次」をクリックし、次のようにパラメータを設定します。
    EXTRACT ext_1
USERIDALIAS DC1_CDB DOMAIN GoldenGate
EXTTRAIL aa
TRANLOGOPTIONS HANDLEDLFAILOVER
TRANLOGOPTIONS FAILOVERTARGETDESTID 2
SOURCECATALOG <PDB_NAME>
TABLE <OWNER>.*;
  7. 「次」をクリックします。
  8. PDBからのCDBルート取得を使用する場合は、PDB名を指定してSOURCECATALOGパラメータを追加します。
  9. Oracle Data Guard構成の場合は、このステップでの前の説明に従って、必要に応じてTRANLOGOPTIONSパラメータを追加します。
    • パラメータTRANLOGOPTIONS HANDLEDLFAILOVERを追加します
    • Oracle Data Guardファスト・スタート・フェイルオーバー(FSFO)を使用中でない場合のみ、パラメータTRANLOGOPTIONS FAILOVERTARGETDESTID <log_archive_dest_numer>を追加します。
  10. 「Create and Run」をクリックします

詳細は、Oracle GoldenGate Extractの障害またはエラー条件に関する考慮事項を参照してください。

ステップ4.4.2 - Replicatの構成

通常は、GGHubがターゲットOracle GoldenGateデータベースと同じリージョンにあるときはほとんどのワークロードについて適用パフォーマンスが優れている、統合パラレルReplicatの使用をお薦めします。

GGHubとターゲット・データベースの間のネットワーク待機時間が最小限であるときに、最良の適用パフォーマンスを実現できます。Oracle GGHubで実行されているリモートReplicatの場合は、次の構成をお薦めします。

  • APPLY_PARALLELISM – 自動並列度を無効化します。MAX_APPLY_PARALLELISMとMIN_APPLY_PARALLELISMを使用するかわりに、ターゲット・データベスに最大量の並行性を許可します。これは、ハブとターゲット・データベース・サーバーの使用可能なCPUに基づいて、できるかぎり高く設定することをお薦めします。
  • MAP_PARALLELISM – 2から5の値を設定する必要があります。アプライヤが多数ある場合は、マッパーを増やすことでアプライヤに作業を渡す能力が向上します。
  • BATCHSQL - 配列処理を使用してDMLを適用します。これにより、レイテンシが高いネットワークでネットワーク・オーバーヘッドの量が削減されます。多数のデータ競合がある場合は、BATCHSQLによってパフォーマンスが低下することに注意してください。これは、バッチ操作のロールバック後に非バッチ・モードで適用するために証跡ファイルからの再読取りがあるためです。

データベース接続を設定して検証した後に、次のステップを実行するとデプロイメントのReplicatを追加できます。

  1. Oracle GoldenGate管理サーバーにログインします
  2. 「管理サービス」ホーム・ページで、「Replicat」の横にあるプラス(+)記号をクリックします。Replicatの追加ページが表示されます。
  3. Replicatのタイプを選択して、「次」をクリックします。
  4. 次に示すように詳細を入力します。
    • プロセス名: REP_1
    • 説明: DC 2 PDBのReplicat
    • 目的: 一方向
    • 資格証明ドメイン: GoldenGate
    • 資格証明別名: DC2_PDB
    • ソース: トレイル
    • トレイル名: aa
    • 開始: ログでの位置
    • チェックポイント表: "GGADMIN"."CHKP_TABLE"
  5. 「次」をクリックします
  6. 「アクション・メニュー」で、「詳細」をクリックしてReplicatのパラメータを編集します。
    REPLICAT REP_1
USERIDALIAS Reg2_PDB DOMAIN GoldenGate
MAP <SOURCE_PDB_NAME>.<OWNER>.*, TARGET <OWNER>.*;
  7. 「アクション・メニュー」から、「開始」をクリックします。

ステップ4.4.3 - 分散パスの構成

分散パスは、次の図に示すように、証跡ファイルを別の(または同じ)データ・センター内の追加のOracle GoldenGate Hubに送信する必要があるときのみ必要になります。

図22-4 Oracle GoldenGate分散パス


Oracle GoldenGate分散パス

NGINXリバース・プロキシでOracle GoldenGate Distributionパスを使用する場合は、パスのクライアントとサーバーの証明書が構成されるように、追加のステップを実行する必要があります。

分散パスの作成の詳細は、『Oracle GoldenGate Microservices Architectureの使用』を参照してください。証明書を正しく構成するためのステップバイステップの例は、NGINXを使用したオンプレミスのOracle GoldenGateからOCI GoldenGateへの接続についてのビデオを視聴してください。

このサブステップで実行するステップは次のとおりです。

  • ステップ4.4.3.1 - ターゲット・サーバーのルート証明書のダウンロードとソースOracle GoldenGateへのアップロード
  • ステップ4.4.3.2 - ソースOracle GoldenGateで使用するためのターゲット・デプロイメントでのユーザーの作成
  • ステップ4.4.3.3 - ソースOracle GoldenGateでの資格証明の作成
  • ステップ4.4.3.4 - ソースOracle GoldenGateからターゲット・デプロイメントへの分散パスの作成
  • ステップ4.4.3.5 - 分散パスの推奨事項

ステップ4.4.3.1 - ターゲット・サーバーのルート証明書のダウンロードとソースOracle GoldenGateへのアップロード

ターゲット・デプロイメント・サーバーのルート証明書をダウンロードし、ソース・デプロイメントのサービス・マネージャにCA証明書を追加します。

  1. ターゲットのGoldenGateデプロイメントで、「管理サービス」にログインします。
  2. NGINXを使用したオンプレミスのOracle GoldenGateからOCI GoldenGateへの接続についてのビデオの"ステップ2 - ターゲット・サーバーのルート証明書のダウンロード"に関する説明に従います。

ステップ4.4.3.2 - ソースOracle GoldenGateで使用するためのターゲット・デプロイメントでのユーザーの作成

ターゲット・デプロイメントで、次に接続する分散パスのユーザーを作成します。

  1. ターゲットGoldenGateで、管理サービスにログインします。
  2. 「管理サービス」で「管理者」をクリックします。
  3. 「ユーザー」の横のプラス(+)記号をクリックします。
  4. 次に示すように詳細を入力します。
    • ユーザー名: ggnet
    • ロール: オペレータ
    • タイプ: パスワード
  5. 「発行」をクリックします

ステップ4.4.3.3 - ソースOracle GoldenGateデプロイメントでの資格証明の作成

前のステップで作成したユーザーでターゲット・デプロイメントを接続するソース・デプロイメントに資格証明を作成します。たとえば、OP2CのドメインとWSSNETの別名です。

  1. ソースOracle GoldenGateで、管理サービスにログインします。
  2. 「管理サービス」の「構成」をクリックします。
  3. 「データベース」ホーム・ページで「資格証明」の横にあるプラス(+)記号をクリックします。
  4. 次に示すように詳細を入力します。
    • 資格証明ドメイン: OP2C
    • 資格証明別名: wssnet
    • ユーザーID: ggnet
  5. 「発行」をクリックします

ステップ4.4.3.4 - ソースOracle GoldenGateからターゲット・デプロイメントへの分散パスの作成

分散サーバーから受信サーバーに証跡ファイルを送信するパスが作成されます。パスはDistribution Serviceで作成できます。ソース・デプロイメントのパスを追加するには:

  1. ソースOracle Goldengateで、分散サービスにログインします。
  2. 「分散サービス」ホーム・ページで、「パス」の横のプラス(+)記号をクリックします。「パスの追加」ページが表示されます。
  3. 次に示すように詳細を入力します。
    オプション 説明
    パス名 パスの名前を選択します
    ソース: トレイル名 ドロップダウン・リストからExtractの名前を選択します(証跡名が自動的に入力されます)。表示されない場合は、Extractの追加時に指定した証跡名を入力します。
    生成されたソースURI サーバーの名前にlocalhostを指定します。これにより、任意のOracle RACノードで分散パスを起動できるようになります。
    ターゲット認証方式 「ユーザーID別名」を使用します
    ターゲット 「ターゲット」の転送プロトコルをwss (セキュアWebソケット)に設定します。「ターゲット・ホスト」を、NGINXが構成された「ポート番号」とともにターゲット・システムへの接続に使用されるターゲット・ホスト名/VIPに設定します(デフォルトは443)。
    ドメイン 「ドメイン」を、先ほど作成した資格証明ドメイン(OP2Cなど)に設定します。
    別名 「別名」は、資格証明別名wssnetに設定されます。
    自動再起動オプション 分散サーバーが自動的に起動されたときに分散パスを再起動するように設定します。これは、分散サーバーのRACノードの再配置後に、手動操作を不要にするために必要です。「再試行」の回数は10に設定することをお薦めします。「遅延」を1に設定します。これは、再起動の試行間に一時停止する分数です。
  4. 「パスの作成」をクリックします。
  5. 「アクション・メニュー」から、「開始」をクリックします。

ステップ4.4.3.5 - 分散パスの推奨事項

GGHubに証跡ファイルを送信するGoldenGate分散パスがある場合は、GGHubのロール・トランジション後に、証跡ファイルを新しいプライマリGGHubシステムに送信するようにそのパスを変更する必要があります。これを行うには、次のRESTコールの例を使用します。

curl -s -K src_access.cfg
 https://Source_VIP/Source_Deployment_Name/distsrvr/services/v2/sources/Distribution_Path_Name
 -X PATCH --data '{"target":{"uri":"ogg://Target_VIP:9103/services/v2/targets?trail=dd"}}' | python
 -m json.tool

「Oracle GoldenGate Hub向けの計画および計画外停止の管理」で示されているサンプル・シェル・スクリプトを使用して、ハブ・ロール・トランジション後のソース分散パスのターゲット・アドレスの変更を自動化できます。このスクリプトは、ファイル・システムのスイッチオーバーやフェイルオーバーが発生したときにacfs_standby CRSアクション・スクリプトによってコールされます。

ソース分散パスは、その障害発生後に自動的に再起動されるように構成して、ターゲットGoldenGateデプロイメントがOracle RACノード間またはスタンバイ・ハブに再配置された場合に分散パスが再起動されるようにする必要があります。自動再起動を有効にせずに分散パスを作成した場合は、分散サーバーのWeb UIまたはRESTコールを介してそれを有効にできます。たとえば:

$ curl -s -K
 access.cfg https://<Source VIP>/<Source Deployment Name>/distsrvr/services/v2/sources/ggs_to_gghub
 -X PATCH --data '{"options":{"autoRestart":{"delay": 2,"retries": 10}}}' | python -m json.tool

分散パスの現在の構成を確認するには、次の例を使用します。

$ curl -s -K
 access.cfg https://<Source VIP>/<Source Deployment Name>/distsrvr/services/v2/sources/ggs_to_gghub
 -X GET | python -m json.tool 

# Sample output:
"name": "scam_to_gghub", 
  "options": { 
     "autoRestart": { 
     "delay": 2, 
     "retries": 10 
  },

ステップ4.4.4 - タイム・ラグをモニターするためのハートビート表の設定

OCI GoldenGateでハートビート表を追加するためのステップの手順を使用して、ソース・システムとターゲット・システムの間のどこでいつラグが発生しているかを判断するために使用できるハートビート・プロセスの作成のベスト・プラクティスを実装します。

このドキュメントでは、ソース・データベースとターゲット・データベースの間の処理時間を追跡するために必要な、表および追加された表マッピング文を作成するための段階的なプロセスを説明します。情報がデータ・フローに追加されると、その情報がターゲット表に格納されます。これらの表は、ソース・システムとターゲット・システムの間でいつラグが発生するかを判断するために分析できます。