トランザクション・ログの設定と要件

Oracle GoldenGateは、REDOログを使用して、ソース・トランザクションのレプリケートに必要なデータを取得します。Oracle GoldenGateの処理を始める前に、Oracle REDOログをソース・システムに適切に構成する必要があります。

この項では、Oracle GoldenGateに適用される次のロギング・レベルについて説明します。使用するロギング・レベルは、使用しているOracle GoldenGate機能によって異なります。

ノート:この必要なロギングの結果、REDOボリュームが増えます。Oracle GoldenGate処理を開始してロギングが有効化されるまで待つ場合があります。

この表に、様々なロギング・プロパティのOracle GoldenGateユースケースを示します。

「ロギング」オプション	コマンド名	処理の内容	ユース・ケース
強制ロギングモード	ALTER DATABASE FORCE LOGGING;	すべてのトランザクションおよびロードのロギングを強制します。	すべてのOracle GoldenGateユースケースで強くお薦めします。FORCE LOGGINGは、すべての表レベルのNOLOGGING設定をオーバーライドします。
最小のデータベース・レベルのサプリメンタル・ロギング 「サブセット・データベース・レプリケーションのロギングの有効化」を参照してください。	ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;	最小サプリメンタル・ロギングで行連鎖情報をREDOログに追加できるようにします。	すべてのOracle GoldenGateユースケースに必要です。
スキーマ・レベルのサプリメンタル・ロギング	[ADD SCHEMATRANDATA](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-5DA7C3DC-5D87-4A8B-AD23-6EF587A5CF41)	主キーの無条件のサプリメンタル・ロギングを有効化し、スキーマのすべての表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを有効化します。これらのキーは、すべてスケジューリング列と呼ばれます。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。	スキーマの現在および将来のすべての表でロギングを有効化します。主キー、一意キーおよび外部キーの列がソースとターゲットの両方で同じでない場合は、ALLCOLSを使用します。
サポートされるすべての列で無条件のロギングを使用したスキーマ・レベルのサプリメンタル・ロギング。(サポートされない列タイプの場合は、「スキーマ・レベルのサプリメンタル・ロギングの有効化」を参照してください。)	ALLCOLSオプションを指定したADD SCHEMATRANDATA	スキーマのすべての表で、表のすべての列の無条件のサプリメンタル・ロギングを有効化します。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。	双方向およびアクティブ/アクティブ構成で使用され、そこには更新または削除の実行時に、変更された列だけでなくすべてのカラム値がチェックされます。より多くのリソースが消費されますが、最高レベルのリアルタイム・データ検証と競合検出が可能になります。 この方法は、初期ロードにHANDLECOLLISIONSパラメータを使用する場合にも使用する必要があります。
スキーマ・レベルのサプリメンタル・ロギング、最小設定	NOSCHEDULINGCOLSオプションを指定したADD SCHEMATRANDATA	スキーマのすべての表の主キーおよび有効なすべての一意索引の無条件のサプリメンタル・ロギングを有効化します。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。	非統合Replicatにのみ使用します。これは、最低限必要なスキーマ・レベルのロギング。
統合Replicatの組込みサポートを使用した表レベルのサプリメンタル・ロギング 「表レベルのサプリメンタル・ロギングの有効化」を参照してください	ADD TRANDATA	主キーの無条件のサプリメンタル・ロギングを有効化し、表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを有効化します。これらのキーは、すべてスケジューリング列と呼ばれます。	スキーマ・レベルのサプリメンタル・ロギングが使用されていないかぎり、すべてのOracle GoldenGateユースケースで必要です。主キー、一意キーおよび外部キーの列がソースとターゲットの両方で同じでない場合は、ALLCOLSを使用します。
サポートされるすべての列で無条件のロギングを使用した表レベルのサプリメンタル・ロギング。(サポートされない列タイプの場合は、「表レベルのサプリメンタル・ロギングの有効化」を参照してください。)	ALLCOLSオプションを指定したADD TRANDATA	表のすべての列の無条件のサプリメンタル・ロギングを有効化します。	双方向およびアクティブ/アクティブ構成で使用され、そこには更新または削除の実行時に、変更された列だけでなくすべてのカラム値がチェックされます。より多くのリソースが消費されますが、最高レベルのリアルタイム・データ検証と競合検出が可能になります。 ソースおよびターゲットの主キー、一意キーおよび外部キーがソースとターゲット間で同一でないか、定期的に変更される場合にも使用できます。
表レベルのサプリメンタル・ロギング、最小設定	NOSCHEDULINGCOLSオプションを指定したADD TRANDATA	表の主キーおよび有効なすべての一意索引の無条件のサプリメンタル・ロギングを有効化します。	非統合Replicatおよび非パラレルReplicatに使用します。これは、最低限必要な表レベルのロギング。
JSONリレーショナル二面性ビューおよびJSONコレクション表の表レベルのサプリメンタル・ロギング。	Duality View nameおよびCollection Table nameを含むADD TRANDATA	指定した二面性ビューおよびコレクション表のサプリメンタル・ロギングを有効にします。	ガイドラインは、JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化を参照してください。詳細は、「JSONリレーショナル二面性ビューおよびJSONコレクション表のサポートの詳細」も参照してください。

サブセット・データベース・レプリケーションのロギングの有効化

Oracleソース・データベースを強制ロギング・モードにすることを強くお薦めします。強制ロギング・モードでは、すべてのトランザクションおよびロードのロギングが強制的に実行され、逆にユーザーまたは記憶域設定がオーバーライドされます。これにより、Extract構成のソース・データが失われることがなくなります。

サブセット・データベース・レプリケーションと呼ばれる詳細なデータベース・サプリメンタル・ロギング・モードがあります。これは、すべてのOracle GoldenGateおよびXStreamクライアントの基本的な推奨モードです。これは、以前に使用していた最小サプリメンタル・ロギング・モードにかわるものです。

現時点では、サブセット・データベース・レプリケーション・ロギングは、CDB$ROOTで有効になっています(これは、すべてのユーザーPDBに継承されます)。

ノート:データベース・レベルの主キー(PK)および一意索引(UI)のロギングは、表のサブセットをレプリケートする場合にかぎりお薦めしません。ライブ・スタンバイで使用することも、移行やアップグレードの停止時間を短縮するために、Oracle GoldenGateがすべての表をレプリケートする場合に使用することもできます。

次のステップを実行して、サブセット・データベース・レプリケーション・ロギングと強制ロギングを確認し、必要に応じて有効化します。

1. ALTER SYSTEM権限を持つユーザーとしてSQL*Plusにログインします。

2. 次のコマンドを発行し、データベースがサプリメンタル・ロギング・モードかどうか、および強制ロギング・モードかどうかを確認します。両方の問合せで結果がYESの場合、データベースはOracle GoldenGate要件を満たしています。

   SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;

3. いずれかまたは両方のプロパティで結果がNOの場合、次のステップに進み、必要に応じて有効化します。

   ALTER PLUGGABLE DATABASE *pdbname* ADD SUPPLEMENTAL LOG DATA SUBSET DATABASE REPLICATION;
   ALTER DATABASE FORCE LOGGING;

4. 次のコマンドを発行し、これらのプロパティが有効化されていることを確認します。

   SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;

   両方のプロパティで、この問合せの出力がYESになる必要があります。

5. ログ・ファイルを切り替えます。

   ALTER SYSTEM SWITCH LOGFILE;

スキーマレベル・サプリメンタル・ロギングの有効化

Oracle GoldenGateは、スキーマ・レベルのサプリメンタル・ロギングをサポートしています。スキーマ・レベルのロギングは、Oracle GoldenGateのDDLレプリケーション機能を使用する場合はOracleソース・データベースとターゲット・データベースで必要であり、レプリケートされる表でDDLを実行できる場合はソース・データベースで必要です。その他すべてのユースケースではオプションですが、表レベルのロギングをかわりに使用する必要があります(表レベルのサプリメンタル・ロギングの有効化を参照してください)。

デフォルトでは、スキーマ・レベルのロギングにより、デフォルトで主キーの無条件のサプリメンタル・ロギングが自動的に有効化され、スキーマ内のすべての表の一意キーおよび外部キーの条件付きサプリメンタル・ロギングが自動的に有効化されます。必要に応じて、オプションでロギングを変更できます。

ノート: Oracleでは、表レベルのロギングではなくスキーマ・レベルのロギングを使用することを強くお薦めします。これは、スキーマに追加された新しい表がワイルドカード指定を満たす場合に確実に取得されるためです。キー列の変更がサプリメンタル・ログ・データにも自動的に反映されるため、この方法もお薦めします。たとえば、キーが変更された場合に、ADD TRANDATAを発行する必要はありません。

次のステップをソース・システムで実行して、スキーマ・レベルのサプリメンタル・ロギングを有効化します。

1. ソース・システムでコマンドラインを起動します。

2. 資格証明ストア内の、スキーマ・レベルのサプリメンタル・ロギングを有効にする権限を持つユーザーの別名でDBLOGINコマンドを発行します。

   DBLOGIN USERIDALIAS *alias*

   USERIDALIASおよび追加オプションの詳細は、Oracle GoldenGateパラメータおよび機能リファレンスのUSERIDALIASに関する項を参照してください。

3. ADD SCHEMATRANDATAまたはADD TRANDATAをマルチテナント・データベースで使用する場合は、PDBに直接ログインしてコマンドを実行できます。または、(C##ユーザーを使用して)ルート・レベルでログインする場合は、PDBを含める必要があります。Oracle GoldenGateでデータの変更をキャプチャする対象の各スキーマに対し、ADD SCHEMATRANDATAコマンドを発行します。

   ADD SCHEMATRANDATA pdb.schema [ALLCOLS | NOSCHEDULINGCOLS]

   ここで:

   • オプションがない場合、ADD SCHEMATRANDATAスキーマでは、主キーのソース・システムで無条件のサプリメンタル・ロギングを有効化し、指定したスキーマの現在および将来のすべての表のすべての一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを有効化します。無条件ロギングでは、現在の操作でキーが変更されたかどうかにかかわらず、主キーの値がログに強制的に記録されます。条件付きロギングでは、現在の操作で外部キーまたは一意キーの少なくとも1つが変更された場合、それらのキーのすべての列値が記録されます。デフォルトは、非統合Replicatをオプションでサポートしますが、依存関係を計算するために、主キー、一意キーおよび外部キーをすべてインバウンド・サーバーで使用できるようにする必要があるため、統合Replicatをサポートする必要があります。

   • ALLCOLSを使用すると、表のすべての列の無条件のサプリメンタル・ロギングを有効化して、指定したスキーマの現在および将来のすべての表に適用できます。ソース表とターゲット表に異なるスケジューリング列が含まれる場合に、統合Replicatをサポートするために使用します。(スケジューリング列は、主キー、一意キーおよび外部キーになります。)

   • NOSCHEDULINGCOLSは、スキーマの既存の表および後で追加された新しい表で、主キーおよび有効なすべての一意索引の値のみをログに記録します。これは、必要最小限のレベルのスキーマ・レベルのロギングで、非統合モードのReplicatのみで有効です。

   次の例では、hrスキーマのデフォルトのサプリメンタル・ロギングをコマンドで有効にします。

   ADD SCHEMATRANDATA pdbeast.hr ALLCOLS

   次の例では、HRスキーマの主キーおよび有効な一意索引のみでサプリメンタル・ロギングをコマンドで有効にします。

   ADD SCHEMATRANDATA pdbeast.hr NOSCHEDULINGCOLS

表レベル・サプリメンタル・ロギングの有効化

表レベルのサプリメンタル・ロギングは、次の場合にソース・システムで有効化します。

• スキーマ・レベルのロギングを使用しない場合に、必要なレベルのロギングを有効にする場合(「スキーマ・レベルのサプリメンタル・ロギングの有効化」を参照)。スキーマ・レベルまたは表レベルのロギングを使用する必要があります。表レベルのロギングでは、デフォルトで主キーの無条件のサプリメンタル・ロギングを自動的に有効化し、表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを自動的に有効化します。必要に応じて、オプションでロギングを変更できます。

• 指定した表で主キーのロギングを回避する場合。

• キー以外の列の値を表レベルで記録し、Oracle GoldenGateの特定の機能(フィルタリング、競合検出および解決ロジックなど)をサポートする場合。

• 表レベルのサプリメンタル・ロギングのみを持つ表でキー列が変更される場合は、表に対するDMLアクティビティを許可する前に、その表に対してADD TRANDATAを実行する必要があります。

• JSONリレーショナル二面性ビュー(JSON DV)およびJSONコレクション表のサプリメンタル・ロギングを有効にするには、JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化のガイドラインに従う必要があります。

次のステップをソース・システムで実行して、表レベルのサプリメンタル・ロギングを有効化するか、コマンドのオプションの機能を使用します。

1. ソース・システムでコマンドラインを実行します。

2. 資格証明ストア内の、表レベルのサプリメンタル・ロギングを有効にする権限を持つユーザーの別名を使用してDBLOGINコマンドを発行します。

   DBLOGIN USERIDALIAS *alias*

   See USERIDALIAS in Parameters and Functions Reference for Oracle GoldenGatefor more information about DBLOGIN and additional options.

3. ADD TRANDATAコマンドを発行します。

   ADD TRANDATA [*PDB*.]*schema.**table* [, COLS (*columns)*] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]

   ここで:

   • PDBは、表 がマルチテナント・コンテナ・データベースにある場合、ルート・コンテナまたはプラガブル・データベースの名前です。

   • schemaは、表を含むソーススキーマである。

   • tableは、表名です。オブジェクト名を指定する手順は、「Oracle GoldenGateの入力でのオブジェクト名の指定」を参照してください。

   • ADD TRANDATAで他のオプションを指定しない場合は、主キーの無条件のサプリメンタル・ロギングを自動的に有効化し、表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを自動的に有効化します。無条件ロギングでは、現在の操作でキーが変更されたかどうかにかかわらず、主キーの値がログに強制的に記録されます。条件付きロギングでは、現在の操作で外部キーまたは一意キーの少なくとも1つが変更された場合、それらのキーのすべての列値が記録されます。デフォルトは、非統合Replicat (NOSCHEDULINGCOLSも参照)をオプションでサポートしますが、依存関係を計算するために、主キー、一意キーおよび外部キーをすべてインバウンド・サーバーで使用できるようにする必要があるため、統合Replicatをサポートする必要があります。

   • ALLCOLSでは、表のすべての列の無条件のサプリメンタル・ロギングを有効化します。ソース表とターゲット表に異なるスケジューリング列が含まれる場合に、統合Replicatをサポートするために使用します。(スケジューリング列は、主キー、一意キーおよび外部キーになります。)

   • NOSCHEDULINGCOLSは、非統合モードのReplicatプロセスでのみ有効です。これは、表に対して定義されている一意制約のタイプ、または一意制約のないすべての列に適した、ADD SUPPLEMENTAL LOG DATA ALWAYS句を含むALTER TABLEコマンドを発行します。このコマンドは、スキーマ・レベルのロギングが使用されていない場合に、Oracle GoldenGateの表レベルのロギングの基本要件を満たします。Oracle GoldenGateがキーまたは索引を選択する方法は、「ソース表とターゲット表での行の一意性の確保」を参照してください。

   • COLS columnsは、KEYCOLS句またはフィルタリングおよび操作に必要なキー以外の列を記録します。カッコは必須です。NOKEYオプションも存在しないかぎり、主キーに加えてこれらの列もログに記録されます。

   • NOKEYによって、主キーまたは一意なキーのロギングが回避されます。TABLEパラメータおよびMAPパラメータにKEYCOLS句が必要で、ADD TRANDATAコマンドでCOLS句を使用して代替のKEYCOLS列を記録する必要があります。

4. ADD TRANDATAにCOLSオプションを使用する場合、ターゲットでそれらの列に一意の索引を作成して行の取得を最適化します。KEYCOLS句の代替キーとしてこれらの列を記録する場合は、Oracle GoldenGateプロセスを構成するときにKEYCOLS句をTABLEおよびMAP文に追加する必要があります。

JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化

JSONリレーショナル二面性ビューおよびJSONコレクション表をレプリケートする前に、Oracle GoldenGateでサプリメンタル・ロギングを設定する必要があります。デフォルトでは、サプリメンタル・ロギングは、JSONリレーショナル二面性ビューおよびJSONコレクション表では有効になっていません。二面性ビューおよびコレクション表に対してサプリメンタル・ロギングを有効にする場合は、次のガイドラインを使用できます。

• 論理レプリケーションの有効化:二面性ビューおよびコレクション表に対する変更を取得するには、論理レプリケーションの有効化(ADD TRANDATAを使用)が必須です。このプロセスにより、JSONドキュメント・レベルで変更を追跡するために必要なサプリメンタル・ロギングが可能になります。

  詳細は、ADD TRANDATAを参照してください。

  Oracle AI Database側では、JSONリレーショナル二面性ビューおよびJSONコレクション表の句がCREATE/ALTER DDLに追加されています。この句を使用すると、ビュー・レベルでサプリメンタル・ロギングが有効になります。このロギングは、実表に対する既存のロギングに加えて行われます。

  詳細は、Oracle AI Database SQL言語リファレンスのCREATE TABLE/CREATE JSON RELATIONAL DUALITY VIEW のlogical_replication_clauseに関する項およびALTER TABLE/ALTER JSON RELATIONAL DUALITY VIEWSコマンドを参照してください。

• JSON二面性ビューおよびJSONコレクション表のDML変更: INSERTおよびUPDATE操作では、完全なJSONドキュメントおよび_idキー属性がサプリメンタルに記録されます。DELETE操作の場合、キー_id属性のみがログに記録されます。

• JSONリレーショナル二面性ビューのトランザクション・コミット・ロギング:二面性ビューのサプリメンタル・ロギングは、コミット時に発生します。ネットの変更のみがログに記録されます。

  たとえば、レコードをINSERTし、このレコードをJSON二面性ビューを含むトランザクションで2回UPDATEした場合、1つの論理変更のみが存在し、更新されたレコードを含むINSERTが含まれます。

• 基礎となる表を使用したJSON二面性ビューへのJSON二面性ビュー・レプリケーション: 基礎となるリレーショナル表レベルの二面性ビューでのレプリケーションの変更は、主に効率的です。基礎となるリレーショナル表の上にある二面性ビューは、ビューとしてこれらの変更を自動的に反映します。この場合、二面性ビューに対する追加のサプリメンタル・ロギングは必要ありません。

表レベルのサプリメンタル・ロギングを設定するステップは、表レベルのサプリメンタル・ロギングの使用可能に関する項を参照してください。

表レベルのサプリメンタル・ロギングの削除

表をOracle GoldenGateでキャプチャする必要がなくなり、その表のTABLEパラメータがExtractのパラメータ・ファイルから削除されているか、またはTABLEEXCLUDEを使用してワイルドカード文から表を除外している場合、サプリメンタル・ロギングは表から削除できます。

ノート: Extractで、サプリメンタル・ロギングが有効になっていない表を解決すると、DML操作のタイプに応じて異常終了します。

DELETE TRANDATAを使用してサプリメンタル・ロギングを削除すると、表のReplicatアイデンティティ・レベルがNOTHINGに設定されます。サプリメンタル・ロギングは、Microservices Architecture Webインタフェースを使用して、「管理サービス」、「構成」ページから、ソース・データベースに対して作成された「資格証明」で無効にするか、DELETE TRANDATAコマンドを使用して発行できます。

次に、DELETE TRANDATAを発行する構文を示します。

DBLOGIN USERIDALIAS alias_name
DELETE TRANDATA schema.tablename

サプリメンタル・ロギングのレベルを確認するには:

INFO TRANDATA schema.tablename