タスク4: Oracle GoldenGate環境の構成
このタスクを完了するには、次のステップを実行します。
- ステップ4.1 - データベース資格証明の作成
- ステップ4.2 - 自動起動プロファイルの作成
- ステップ4.3 - Oracle GoldenGateプロセスの構成
ステップ4.1 - データベース資格証明の作成
Oracle GoldenGateデプロイメントを作成したら、Oracle GoldenGate管理サービスのホーム・ページを使用して、前述のTNS別名を使用してデータベース資格証明を作成します。
oggadmin
ユーザーとして、データベース資格証明を作成します。
- 管理サービスにログインします: https://gghub.example.com:443/deployment_name/adminsrvr
- 「管理サービス」の「構成」をクリックします。
- 「データベース」タブの「資格証明の追加」のプラス(+)をクリックします。
- ソースおよびターゲットの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 Administration Serverの起動時にExtractプロセスとReplicatプロセスを自動的に起動する、新しいプロファイルを作成します。その後、ExtractプロセスまたはReplicatプロセスが中止された場合は再起動します。GoldenGate Microservicesでは、自動起動と再起動はプロファイルによって管理されます。
Oracle GoldenGate Administration Server GUIを使用して、各Oracle GoldenGateプロセスに割り当てることができる新しいプロファイルを作成します。
- ソースおよびターゲットGoldenGateで、管理サービスにログインします。
- 「管理サービス」の「プロファイル」をクリックします。
- 「管理対象プロセスの設定」で「プロファイル」の横にあるプラス(+)記号をクリックします。
- 次に示すように詳細を入力します。
- プロファイル名: Start_Default
- 説明: デフォルトの自動起動/再起動プロファイル
- デフォルト・プロファイル: はい
- 自動開始: はい
- 自動開始オプション
- 開始の遅延: 1分
- 自動再起動: はい
- 自動再起動オプション
- 最大再試行回数: 5
- 再試行の遅延: 30秒
- 再試行期間: 30分
- 失敗時にのみ再起動: はい
- 試行回数に達したらタスクを無効化: はい
- 「発行」をクリックします
ステップ4.3 - Oracle GoldenGateプロセスの構成
Oracle GoldenGate Microservices ArchitectureによるExtract、分散パスおよびReplicatプロセスの作成時に、GGHubノード間で共有する必要があるすべてのファイルは、すでに共有ファイル・システムに格納されているデプロイメント・ファイルによって共有されています。
Extract、分散パスおよびReplicatプロセスのためにGGHubでOracle GoldenGate Microservicesを実行する際にお薦めする基本的な構成の詳細を次に示します。
次のサブステップを実行して、このステップを完了します。
- ステップ4.3.1 - Extractの構成
- ステップ4.3.2 - Replicatの構成
- ステップ4.3.3 - 分散パスの構成
- ステップ4.3.4 - タイム・ラグを監視するためのハートビート表の設定
ステップ4.3.1 - Extractの構成
Oracle GoldenGate管理サービスのGUIインタフェースを使用してExtractを作成するときには、「トレイルのサブディレクトリ」パラメータを空のままにして、共有ファイル・システムに格納されているデプロイメント・ディレクトリに自動的に証跡ファイルが作成されるようにします。証跡ファイルのデフォルトの場所は、/<deployment directory>/var/lib/data
ディレクトリです。
ノート:
マルチテナント・データベースから取得するには、c##アカウントを使用してルート・レベルで構成したExtractを使用する必要があります。マルチテナント・データベースにデータを適用するには、PDBごとに個別のReplicatが必要になります。これは、ReplicatはPDBレベルで接続して、そのPDB以外のオブジェクトにアクセスできないためです。
REDO転送の最大パフォーマンス・モードまたは最大可用性モードを使用しているOracle Data Guard構成を使用するGoldenGate Extractプロセスでは、トランザクションが失われて論理データの不整合が発生しないように、プライマリ・システムにあるExtractプロセス・パラメータ・ファイルに次のパラメータを追加する必要があります。
TRANLOGOPTIONS HANDLEDLFAILOVER
このパラメータにより、まだData Guardスタンバイ・データベースに適用されていないREDOからExtractがトランザクション・データを抽出しないようにします。これは、Oracle GoldenGateがソース・スタンバイ・データベースに存在しないデータをターゲット・データベースにレプリケートしないようにするために重要です。
このパラメータが指定されていないと、ソース・データベースのデータ損失フェイルオーバー後に、ソース・データベースに存在していないデータがターゲット・データベースに保持される可能性があります。それにより、論理データの不整合が発生します。
デフォルトでは、スタンバイ・データベースで適用されたSCN情報を問い合せることができないためにExtractが停止すると、その60秒後に、警告メッセージがExtractレポート・ファイルに書き込まれます。たとえば:
WARNING OGG-02721 Extract has been waiting for the standby database for 60 seconds.
Extractレポート・ファイルに警告メッセージが書き込まれるまでの時間は、ExtractパラメータのTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_WARNING
を使用すると調整できます。
Extractが30分(デフォルト)後にスタンバイ・データベースによって適用されたSCN情報を問い合せることができない場合、Extractプロセスは異常終了して、次のメッセージがExtractレポート・ファイルに記録されます。
ERROR OGG-02722 Extract abended waiting for 1,800 seconds for the
standby database to be accessible or caught up with the primary database.
デフォルトの30のタイムアウトが満了する前にスタンバイ・データベースが使用可能になると、Extractはソース・データベースからデータのマイニングを続行して、次のメッセージをレポート・ファイルに報告します。
INFO OGG-02723 Extract resumed from stalled state and started
processing LCRs.
タイムアウト値の30分は、ExtractパラメータのTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_ABEND <value>
を使用すると調整できます。このvalueは、異常終了するまでにスタンバイが使用できない秒数です。
スタンバイ・データベースを長期間使用できなくなる場合に(計画メンテナンスのための停止時間の間など)、Extractでプライマリ・データベースからデータの抽出を継続するには、Extractパラメータ・ファイルからTRANLOGOPTIONS HANDLEDLFAILOVER
パラメータを削除し、Extractを再起動します(次の図4から6の例を参照)。このパラメータは、スタンバイが使用可能になったら必ず設定してください。
ノート:
スタンバイが使用できない間にプライマリ・データベースからの抽出が続行されていると、スタンバイが使用可能になったときにデータ損失フェイルオーバーが発生し、フェイルオーバーの前にすべてのプライマリREDOが適用されていない可能性もあります。GoldenGateターゲット・データベースには、ソース・データベースに存在しないデータが含まれるようになります。「オンプレミス: Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」で説明したように、Extractプロセスに自動再起動プロファイルが割り当てられている場合は、Data Guardのロール・トランジション後にExtractプロセスが自動的に再起動されます。Extractは、デフォルトの5分タイムアウト期間が満了するまで、新しいスタンバイ・データベースの現在の状態を無視して、新しいプライマリ・データベースからのREDOデータのマイニングを続行します。この期間の経過後にスタンバイが使用できない場合、Extractは次のエラーで異常終了します。
INFO OGG-25053 Timeout waiting for 300 seconds for standby database
reinstatement. Now enforcing HANDLEDLFAILOVER.
ERROR OGG-06219 Unable to extract data from the Logmining server OGG$CAP_XXXXX.
ERROR OGG-02078 Extract encountered a fatal error in a processing thread and is
abending.
Extractは、GoldenGate Microservicesの自動再起動プロファイルに基づいて、再試行回数に達するか新しいスタンバイ・データベースが使用可能になるまで自動的に再起動し続け、HANDLEDLFAILOVER
タイムアウトに達すると失敗します。
データベース・ロール・トランジション後のタイムアウト期間中、HANDLEDLFAILOVER
パラメータは自動的に一時停止されるため、ソース・スタンバイ・データベースが最新の状態に維持されていないことの考慮なしに、データがOracle GoldenGateレプリカ・データベースにレプリケートされます。Extractの異常終了前に起動するスタンバイ・データベースのタイムアウト期間は、ExtractパラメータのTRANLOGOPTIONS DLFAILOVER_TIMEOUT
を使用すると調整できます。
DLFAILOVER_TIMEOUT
をデフォルトの5分のままにして、古いプライマリがスタンバイに変換できるようにすることをお薦めします。新しいスタンバイ・データベースが長期間使用できなくなるか完全に消失した場合に、Extractを起動して実行状態を維持するには、Extractパラメータ・ファイルからHANDLEDLFAILOVER
パラメータを削除する必要があります。このパラメータを削除すると、ExtractはREDOがスタンバイ・データベースに適用されるまで待機することなくデータを抽出します。
スタンバイ・データベースがオンラインに復帰して、プライマリ・データベースからすべてのREDOを適用するまでは、スタンバイ・データベースとOracle GoldenGateレプリカ・データベースの間にデータの相違があります。これは、スタンバイ・データベースが最新状態になると解決されます。その時点で、統合Extractプロセス・パラメータ・ファイルにHANDLEDLFAILOVER
パラメータを再追加し、Extractを停止してから再起動します。
プライマリ・データベースが損なわれたときにはブローカがスタンバイ・データベースに自動的にフェイルオーバーできるなど、Oracle Data Guardファスト・スタート・フェイルオーバーが無効になっている場合は、次に示す追加の統合Extractパラメータを指定する必要があります。
TRANLOGOPTIONS FAILOVERTARGETDESTID n
このパラメータでは、スタンバイ・データベースにまだ適用されていないREDOデータを抽出しないことに関して、Oracle GoldenGate Extractプロセスを遅らせたままにしておく必要があるスタンバイ・データベースを指定します。
Oracle Data Guardファスト・スタート・フェイルオーバーが無効のときに、追加の統合ExtractパラメータFAILOVERTARGETDESTID
を指定していないと、抽出は次のエラーで異常終了します。
ERROR OGG-06219 Unable to extract data from the Logmining server OGG$CAP_XXXXX.
ERROR OGG-02078 Extract encountered a fatal error in a processing thread and is
abending.
FAILOVERTARGETDESTID
の正しい値を判断するには、ソース・スタンバイ・データベースへのREDOの送信に使用されるGoldenGateソース・データベースのLOG_ARCHIVE_DEST_N
パラメータを使用します。たとえば、LOG_ARCHIVE_DEST_2
がスタンバイ・データベースを指している場合は2の値を使用します。
プライマリ・データベース・システムでoracle
ユーザーとして、次のコマンドを実行します。
[opc@exapri-node1 ~]$ sudo su - oracle
[oracle@exapri-node1 ~]$ source <dbName>.env
[oracle@exapri-node1 ~]$ sqlplus / as sysdba
SQL> show parameters log_archive_dest
NAME TYPE VALUE
--------------------- ----------- ---------------------------------------------------
log_archive_dest_1 string location=USE_DB_RECOVERY_FILE_DEST,
valid_for=(ALL_LOGFILES, ALL_ROLES)
log_archive_dest_2 string service="<dbName>", SYNC AFFIRM delay=0
optional compression=disable max_failure=0 reopen=300
db_unique_name="<dbName>" net_timeout=30,
valid_for=(online_logfile,all_roles)
この例では、次のようにExtractパラメータを設定します。
TRANLOGOPTIONS FAILOVERTARGETDESTID 2
Extractの作成:
- Oracle GoldenGate管理サーバーにログインします
- 「管理サービス」の「概要」をクリックします
- 「Extractの追加」のプラス(+)・ボタンをクリックします。
- 「統合Extract」を選択します
- 次のように必要な情報を追加します。
- プロセス名: EXT_1
- 説明: DC 1 CDBのExtract
- 目的: 一方向
- 開始: 今すぐ
- トレイル名: aa
- 資格証明ドメイン: GoldenGate
- 資格証明別名: DC1_CDB
- PDBに登録: PDB名
- 「次」をクリックします
- PDBからのCDBルート取得を使用する場合は、PDB名を指定して
SOURCECATALOG
パラメータを追加します。 - Oracle Data Guard構成の場合は、このステップでの前の説明に従って、必要に応じて
TRANLOGOPTIONS
パラメータを追加します。- パラメータ
TRANLOGOPTIONS HANDLEDLFAILOVER
を追加します - Oracle Data Guardファスト・スタート・フェイルオーバー(FSFO)を使用中でない場合のみ、パラメータ
TRANLOGOPTIONS FAILOVERTARGETDESTID <log_archive_dest_numer>
を追加します。
- パラメータ
- 「Create and Run」をクリックします
ステップ4.3.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
によってパフォーマンスが低下することに注意してください。これは、バッチ操作のロールバック後に非バッチ・モードで適用するために証跡ファイルからの再読取りがあるためです。
ステップ4.3.2.1 - チェックポイント表の作成
チェックポイント表は、Oracle GoldenGate Replicatプロセスに必須のコンポーネントです。Administration Serviceの資格証明ページからデータベースに接続した後、チェックポイント表を作成できます。
ターゲット・デプロイメントにチェックポイント表を作成します。
- Oracle GoldenGate管理サーバーにログインします
- 「管理サービス」の「構成」をクリックします。
- 「データベース」をクリックして、ターゲット・データベースまたはPDBへの「接続」をクリックします。
- 「チェックポイント」の横のプラス(+)記号をクリックします。「チェックポイントの追加」ページが表示されます。
- 次に示すように詳細を入力します。
- チェックポイント表: ggadmin.chkp_table
- 「発行」をクリックします
チェックポイント表の詳細は、Oracle DatabaseでのOracle GoldenGateのガイドを参照してください。
ステップ4.3.2.2 - Replicatの追加
データベース接続を設定して検証した後に、次のステップを実行するとデプロイメントのReplicatを追加できます。
- Oracle GoldenGate管理サーバーにログインします
- 「管理サービス」ホーム・ページで、「Replicat」の横にあるプラス(+)記号をクリックします。Replicatの追加ページが表示されます。
- Replicatのタイプを選択して、「次」をクリックします。
- 次に示すように詳細を入力します。
- プロセス名: REP_1
- 説明: DC 2 PDBのReplicat
- 目的: 一方向
- 資格証明ドメイン: GoldenGate
- 資格証明別名: DC2_PDB
- ソース: トレイル
- トレイル名: aa
- 開始: ログでの位置
- チェックポイント表: "GGADMIN"."CHKP_TABLE"
- 「次」をクリックします
- 「アクション・メニュー」から、「開始」をクリックします。
ステップ4.3.3 - 分散パスの構成
分散パスは、次の図に示すように、証跡ファイルを別の(または同じ)データ・センター内の追加のOracle GoldenGate Hubに送信する必要があるときのみ必要になります。
図22-4 Oracle GoldenGate分散パス
![Oracle GoldenGate分散パス Oracle GoldenGate分散パス](img/gghub-trail-distribution-path.png)
NGINXリバース・プロキシでOracle GoldenGate Distributionパスを使用する場合は、パスのクライアントとサーバーの証明書が構成されるように、追加のステップを実行する必要があります。
分散パスの作成の詳細は、『Oracle GoldenGate Microservices Architectureの使用』を参照してください。証明書を正しく構成するためのステップバイステップの例は、NGINXを使用したオンプレミスのOracle GoldenGateからOCI GoldenGateへの接続についてのビデオを視聴してください。
このサブステップで実行するステップは次のとおりです。
- ステップ4.3.3.1 - ターゲット・サーバーのルート証明書のダウンロードとソースOracle GoldenGateへのアップロード
- ステップ4.3.3.2 - ソースOracle GoldenGateが使用するターゲット・デプロイメントのユーザーの作成
- ステップ4.3.3.3 - ソースOracle GoldenGateの資格証明の作成
- ステップ4.3.3.4 - ソースOracle GoldenGateからターゲット・デプロイメントへの分散パスの作成
- ステップ4.3.3.5 - 分散パスの推奨事項
ステップ4.3.3.1 - ターゲット・サーバーのルート証明書のダウンロードとソースOracle GoldenGateへのアップロード
ターゲット・デプロイメント・サーバーのルート証明書をダウンロードし、ソース・デプロイメントのサービス・マネージャにCA証明書を追加します。
- ターゲットのGoldenGateデプロイメントで、「管理サービス」にログインします。
- NGINXを使用したオンプレミスのOracle GoldenGateからOCI GoldenGateへの接続についてのビデオの"ステップ2 - ターゲット・サーバーのルート証明書のダウンロード"に関する説明に従います。
ステップ4.3.3.2 - ソースOracle GoldenGateが使用するターゲット・デプロイメントのユーザーの作成
ターゲット・デプロイメントで、次に接続する分散パスのユーザーを作成します。
- ターゲットGoldenGateで、管理サービスにログインします。
- 「管理サービス」で「管理者」をクリックします。
- 「ユーザー」の横のプラス(+)記号をクリックします。
- 次に示すように詳細を入力します。
- ユーザー名: ggnet
- ロール: オペレータ
- タイプ: パスワード
- 「発行」をクリックします
ステップ4.3.3.3 - ソースOracle GoldenGateデプロイメントでの資格証明の作成
前のステップで作成したユーザーでターゲット・デプロイメントを接続するソース・デプロイメントに資格証明を作成します。たとえば、OP2CのドメインとWSSNETの別名です。
- ソースOracle GoldenGateで、管理サービスにログインします。
- 「管理サービス」の「構成」をクリックします。
- 「データベース」ホーム・ページで「資格証明」の横にあるプラス(+)記号をクリックします。
- 次に示すように詳細を入力します。
- 資格証明ドメイン: OP2C
- 資格証明別名: wssnet
- ユーザーID: ggnet
- 「発行」をクリックします
ステップ4.3.3.4 - ソースOracle GoldenGateからターゲット・デプロイメントへの分散パスの作成
分散サーバーから受信サーバーに証跡ファイルを送信するパスが作成されます。パスはDistribution Serviceで作成できます。ソース・デプロイメントのパスを追加するには:
- ソースOracle Goldengateで、分散サービスにログインします。
- 「分散サービス」ホーム・ページで、「パス」の横のプラス(+)記号をクリックします。「パスの追加」ページが表示されます。
- 次に示すように詳細を入力します。
オプション 説明 パス名 パスの名前を選択します ソース: トレイル名 ドロップダウン・リストからExtractの名前を選択します(証跡名が自動的に入力されます)。表示されない場合は、Extractの追加時に指定した証跡名を入力します。 生成されたソースURI サーバーの名前に localhost
を指定します。これにより、任意のOracle RACノードで分散パスを起動できるようになります。ターゲット認証方式 「ユーザーID別名」を使用します ターゲット 「ターゲット」の転送プロトコルをwss (セキュアWebソケット)に設定します。「ターゲット・ホスト」を、NGINXが構成された「ポート番号」とともにターゲット・システムへの接続に使用されるターゲット・ホスト名/VIPに設定します(デフォルトは443)。 ドメイン 「ドメイン」を、先ほど作成した資格証明ドメイン(OP2Cなど)に設定します。 別名 「別名」は、資格証明別名wssnetに設定されます。 自動再起動オプション 分散サーバーが自動的に起動されたときに分散パスを再起動するように設定します。これは、分散サーバーのRACノードの再配置後に、手動操作を不要にするために必要です。「再試行」の回数は10に設定することをお薦めします。「遅延」を1に設定します。これは、再起動の試行間に一時停止する分数です。 - 「パスの作成」をクリックします。
- 「アクション・メニュー」から、「開始」をクリックします。
ステップ4.3.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.3.4 - タイム・ラグを監視するためのハートビート表の設定
OCI GoldenGateでハートビート表を追加するためのステップの手順を使用して、ソース・システムとターゲット・システムの間のどこでいつラグが発生しているかを判断するために使用できるハートビート・プロセスの作成のベスト・プラクティスを実装します。
このドキュメントでは、ソース・データベースとターゲット・データベースの間の処理時間を追跡するために必要な、表および追加された表マッピング文を作成するための段階的なプロセスを説明します。情報がデータ・フローに追加されると、その情報がターゲット表に格納されます。これらの表は、ソース・システムとターゲット・システムの間でいつラグが発生するかを判断するために分析できます。