タスク10 - Oracle GoldenGateプロセスの構成
「Cloud: Oracle Exadata Database ServiceでのOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」に記載されているアドバイスに加えて、Extract、分散パスおよびReplicatに関する次の推奨事項に従ってください。
このタスクを完了するには、次のステップを実行します。
- ステップ10.1 - プライマリ・システムのExtract構成の変更
- ステップ10.2 - プライマリおよびスタンバイ・システムの分散パス構成の変更
ステップ10.1 - プライマリ・システムのExtract構成の変更
REDO転送の「最大パフォーマンス」または「最大可用性」モードを使用しているData Guard構成を使用するExtractプロセスについては、プライマリ・システムのExtractプロセス・パラメータ・ファイルに次のパラメータを追加して、トランザクションが失われることで論理データの不整合が発生しないようにする必要があります。
TRANLOGOPTIONS HANDLEDLFAILOVER
このパラメータにより、まだData Guardスタンバイ・データベースに適用されていないREDOからExtractがトランザクション・データを抽出しないようにします。これは、Oracle GoldenGateがソース・スタンバイ・データベースに存在しないデータをターゲット・データベースにレプリケートしないようにするために重要です。
このパラメータが指定されていないと、ソース・データベースのデータ損失フェイルオーバー後に、ソース・データベースに存在していないデータがターゲット・データベースに保持される可能性があります。それにより、論理データの不整合が発生します。
デフォルトでは、スタンバイ・データベースで適用されたSCN情報を問い合せることができないためにExtractが停止すると、その60秒後に、警告メッセージがExtractレポート・ファイルに書き込まれます。たとえば:
WARNING OGG-02721 Extractはスタンバイ・データベースを60秒待機しています。
Extractレポート・ファイルに警告メッセージが書き込まれるまでの時間は、ExtractパラメータのTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_WARNING
を使用すると調整できます。
Extractが30分(デフォルト)後にスタンバイ・データベースによって適用されたSCN情報を問い合せることができない場合、Extractプロセスは異常終了して、次のメッセージがExtractレポート・ファイルに記録されます。
ERROR OGG-02722 Extractは、スタンバイ・データベースがアクセス可能になるか、プライマリ・データベースに同期することを1,800秒待機して異常終了しました。
デフォルトの30のタイムアウトが満了する前にスタンバイ・データベースが使用可能になると、Extractはソース・データベースからデータのマイニングを続行して、次のメッセージをレポート・ファイルに報告します。
INFO OGG-02723 Extractは停止状態から復帰してLCRの処理を開始しました。
タイムアウト値の30分は、ExtractパラメータのTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_ABEND <value>
を使用すると調整できます。このvalueは、異常終了するまでにスタンバイが使用できない秒数です。
計画メンテナンスの停止時など、スタンバイ・データベースが長時間使用できなくなるときに、Extractでプライマリ・データベースからのデータ抽出を続行する場合は、Extractパラメータ・ファイルからTRANLOGOPTIONS HANDLEDLFAILOVER
パラメータを削除して、Extractを再起動してください。このパラメータは、スタンバイが使用可能になったら必ず設定してください。
ノート:
スタンバイが使用できない間にプライマリ・データベースからの抽出が続行されていると、スタンバイが使用可能になったときにデータ損失フェイルオーバーが発生し、フェイルオーバーの前にすべてのプライマリREDOが適用されていない可能性もあります。Oracle GoldenGateターゲット・データベースには、ソース・データベースに存在しないデータが含まれるようになります。
「Cloud: Oracle Exadata Database ServiceでのOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」で説明したように、Extractプロセスに自動再起動プロファイルが割り当てられている場合は、Data Guardのロール・トランジション後にExtractプロセスが自動的に再起動されます。Extractは、デフォルトの5分タイムアウト期間が満了するまで、新しいスタンバイ・データベースの現在の状態を無視して、新しいプライマリ・データベースからのREDOデータのマイニングを続行します。この期間の経過後にスタンバイが使用できない場合、Extractは次のエラーで異常終了します。
INFO OGG-25053 スタンバイ・データベース復帰のための300秒の待機がタイムアウトです。ただちにHANDLEDLFAILOVERを実施します。
ERROR OGG-06219 ログマイニング・サーバーOGG$CAP_XXXXXからデータを抽出できません
ERROR OGG-02078 Extractは処理スレッドで致命的エラーを検出し、異常終了しています。
Extractは、Oracle 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 ログマイニング・サーバーOGG$CAP_XXXXXからデータを抽出できません
ERROR OGG-02078 Extractは処理スレッドで致命的エラーを検出し、異常終了しています。
FAILOVERTARGETDESTID
の適切な値を判断するには、ソース・スタンバイ・データベースへのREDOの送信に使用されるOracle GoldenGateソース・データベースのLOG_ARCHIVE_DEST_N
パラメータを使用します。たとえば、LOG_ARCHIVE_DEST_2
がスタンバイ・データベースを指している場合は2の値を使用します。
プライマリ・システムのoracle
ユーザーとして、次のコマンドを実行します。
[opc@exapri-node1 ~]$ sudo su - oracle
[oracle@exapri-node1 ~]$ source <db_name>.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="<db_name>", SYNC AFFIRM delay=0
optional compression=disable max_failure=0 reopen=300
db_unique_name="<db_name>" net_timeout=30,
valid_for=(online_logfile,all_roles)
この例では、次のようにExtractパラメータを設定します。
TRANLOGOPTIONS FAILOVERTARGETDESTID 2
Extractパラメータ・ファイルにパラメータを追加するには:
- ソースOracle GoldenGateのOracle GoldenGate管理サーバーにログインします。
- 「管理サービス」の「概要」をクリックします。
- 変更する「Extract」の横にある「アクション」ボタンをクリックします。
- 「詳細」を選択します。
- 「パラメータ」タブを選択し、現在のパラメータ・ファイルを編集するための鉛筆アイコンを選択します。
TRANLOGOPTIONS
パラメータを追加し、変更を保存するために「適用」を選択します。
新しいパラメータを有効にするために、Extractプロセスを停止してから再起動する必要があります。これは管理サーバーを使用して実行できます。
Extract TRANLOGOPTIONS
パラメータの詳細は、『Oracle GoldenGateリファレンス』を参照してください。
ステップ10.2 - プライマリおよびスタンバイ・システムの分散パス構成の変更
受信サーバーを実行しているOracle GoldenGate環境のターゲット・データベースがOracle Data Guardで保護されている場合、受信サーバーに証跡ファイルを送信する分散パスには重要な考慮事項があります。Oracle Data Guardロール・トランジション後に受信サーバーが別のシステムに移動される場合は、新しいターゲット・システム・アドレスを反映するように分散パスを変更する必要があります。
分散パスは、受信サーバー・システムのターゲット・データベースでデータベース・ロール・トランジション・トリガーを使用して自動的に変更できます。
プライマリおよびスタンバイ・システムのVIPが異なるルートCA証明書を使用する場合は、「タスク11 - Oracle GoldenGateプロセスの構成」の「ステップ11.3 - 分散パス構成」で説明したように、ソース・デプロイメントのサービス・マネージャにスタンバイ証明書を追加する必要があります。
次の手順に従って、データベース・ロール・トランジション・トリガーを作成します。このトリガーでは、ターゲット・データベースのData Guardロールのトランジション中に受信サーバーがプライマリとスタンバイのシステム間で移動されるときに分散パスのターゲット・アドレスを変更します。
次のサブステップを実行して、このステップを完了します。
- ステップ10.2.1 - 分散パスを変更するシェル・スクリプトの作成
- ステップ10.2.2 - DBMS_SCHEDULERジョブの作成
- ステップ10.2.3 - デプロイメント構成ファイルの作成
- ステップ10.2.4 - データベース・ロール・トランジション・トリガーの作成
ステップ10.2.1 - 分散パスを変更するシェル・スクリプトの作成
「分散パス・ターゲット変更スクリプトの例」には、分散パス・ターゲット・アドレスの変更に使用できるシェル・スクリプトの例が記載されています。適切な変数値の設定については、スクリプト例のコメントを参照してください。
ノート:
スクリプトは、TARGETプライマリおよびスタンバイ・データベース・システムのすべてのOracle RACノード上の同じローカル・ディレクトリに配置する必要があります。スクリプト・ファイルの権限は6751に設定します。
TARGET
プライマリとスタンバイ・システムのoracle
OSユーザーとして、ステップに従ってスクリプトchange_path_target.sh
を作成して配布します。
[opc@exadb-node1 ~]$ sudo su – oracle
[oracle@exadb-node1 ~]$ /usr/local/bin/dcli -l oracle -g ~/dbs_group mkdir
-p /u02/app/oracle/goldengate/scripts
[oracle@exadb-node1 ~]$ vi /u02/app/oracle/goldengate/scripts/change_path_target.sh
# Paste the script from Example Distribution Path Target Change Script
[oracle@exadb-node1 ~]$ /usr/local/bin/dcli -l oracle -g ~/dbs_group
-f /u02/app/oracle/goldengate/scripts/change_path_target.sh
-d /u02/app/oracle/goldengate/scripts
ステップ10.2.2 - DBMS_SCHEDULERジョブの作成
PL/SQL内からオペレーティング・システム・シェル・スクリプトを実行するために、DBMS_SCHEDULER
ジョブを作成する必要があります。
TARGET
プライマリ・システムのoracle
OSユーザーとして、ルート・コンテナ・データベース(CDB)内でSYSDBA
ユーザーとしてのスケジューラ・ジョブを作成します。[opc@exapri-node1 ~]$ sudo su - oracle [oracle@exapri-node1 ~]$ source <db_name>.env [oracle@exapri-node1 ~]$ sqlplus / as sysdba SQL> exec dbms_scheduler.create_job(job_name=>'gg_change_path_target', job_type=>'EXECUTABLE', number_of_arguments => 6, job_action=>'/u02/app/oracle/goldengate/scripts/change_path_target.sh', enabled=>FALSE);
外部ジョブを実行するには、
$ORACLE_HOME/rdbms/admin/externaljob.ora
ファイルのパラメータrun_user
とrun_group
をOracleデータベースのオペレーティング・システムのユーザーとグループに設定する必要があります。TARGET
プライマリおよびスタンバイ・システムのroot
OSユーザーとして、ファイルexternaljob.ora
を作成します。[opc@exadb-node1 ~]$ sudo su – [root@exadb-node1 ~]# export DB_NAME=<database_name> [root@exadb-node1 ~]# dbaascli database getDetails --dbname $DB_NAME |grep homePath |uniq "homePath" : "/u02/app/oracle/product/19.0.0.0/dbhome_1", [root@exadb-node1 ~]# vi /u02/app/oracle/product/19.0.0.0/dbhome_1/rdbms/admin/externaljob.ora # Before run_user = nobody run_group = nobody # After run_user = oracle run_group = oinstall
- このステップは、プライマリおよびスタンバイ・システムのすべてのノードで繰り返します。
ノート:
extrernaljob.ora
は、プライマリおよびスタンバイ・データベース・システムのすべてのOracle RACノードで構成する必要があります。
ステップ10.2.3 - デプロイメント構成ファイルの作成
このシェル・スクリプト例では、REST APIコールを使用してOracle GoldenGate分散パスにアクセスします。このREST APIコールをセキュアにするために、curl
で読み取る構成ファイルにはユーザー名とパスワードを含めることをお薦めします。
TARGET
プライマリおよびスタンバイ・システムのoracle
OSユーザーとして、デプロイメント資格証明が含まれている構成ファイルを作成します。
[opc@exadb-node1 ~]$ sudo su – oracle
[oracle@exadb-node1 ~]$
cat > /u02/app/oracle/goldengate/scripts/<INSTANCE_NAME>.cfg << EOF
user = "oggadmin:<password>"
EOF
[oracle@exadb-node1 ~]$ chmod 600 /u02/app/oracle/goldengate/scripts/<INSTANCE_NAME>.cfg
[oracle@exadb-node1 ~]$ /usr/local/bin/dcli -l oracle -g ~/dbs_group
-f /u02/app/oracle/goldengate/scripts/<INSTANCE_NAME>.cfg
-d /u02/app/oracle/goldengate/scripts
ステップ10.2.4 - データベース・ロール・トランジション・トリガーの作成
スタンバイ・データベースがプライマリ・データベースになったときに起動するOracle GoldenGateソース・データベースでロール・トランジション・トリガーを作成し、分散パスのターゲット・アドレスを変更します。
TARGET
プライマリ・システムのoracle
OSユーザーとして、次のSQL文を実行してロール・トランジション・トリガーを作成します。
[opc@exapri-node1 ~]$ sudo su - oracle
[oracle@exapri-node1 ~]$ source <db_name>.env
[oracle@exapri-node1 ~]$ sqlplus / as sysdba
CREATE OR REPLACE TRIGGER gg_change_path
AFTER db_role_change ON DATABASE
declare
role varchar2(30);
hostname varchar2(64);
begin
select database_role into role from v$database;
select host_name into hostname from v$instance;
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',1,'<PRIMARY Source VIP');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',2,'<STANDBY Source VIP');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',4,'<Distribution path name');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',5,'<Instance name>'
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',6,'<Config file containing the deployment credentials>');
if role = 'PRIMARY' and hostname like '<primary target cluster name>%'
then
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',3,'<PRIMARY Target VIP>:443');
elsif role = 'PRIMARY'
then
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',3,'<STANDBY Target VIP>:443');
end if;
DBMS_SCHEDULER.RUN_JOB(job_name=>'gg_change_path_target');
end;
/
ステップ10.3 - プライマリ・システムのReplicat構成
「タスク11 - Oracle GoldenGateプロセスの構成」の「ステップ11.4 - Replicatの構成」で説明したように、すべてのOracle GoldenGate Replicatプロセスにはターゲット・データベースのチェックポイント表が必要です。Oracle Data Guardで構成したReplicatには、その他の構成要件はありません。