トランザクション・ログの設定と要件
Oracle GoldenGateは、REDOログを使用して、ソース・トランザクションのレプリケートに必要なデータをキャプチャします。Oracle GoldenGateの処理を始める前に、Oracle REDOログをソース・システムに適切に構成する必要があります。
この項では、Oracle GoldenGateに適用される次のロギング・レベルについて説明します。使用するロギング・レベルは、使用しているOracle GoldenGate機能によって異なります。
ノート:
この必要なロギングによってREDOの量が増えます。Oracle GoldenGate処理を開始してログが有効化されるまで待つ場合があります。
この表に、様々なロギング・プロパティのOracle GoldenGateユースケースを示します。
ロギング・オプション | コマンド名 | 機能 | ユースケース |
---|---|---|---|
強制ロギング・モード |
|
すべてのトランザクションおよびロードのロギングを強制します。 |
すべてのOracle GoldenGateユースケースで強くお薦めします。 |
最小のデータベース・レベルのサプリメンタル・ロギング 「サブセット・データベース・レプリケーションのロギングの有効化」を参照してください。 |
|
最小サプリメンタル・ロギングで行連鎖情報をREDOログに追加できるようにします。 |
すべてのOracle GoldenGateユースケースに必要です。 |
スキーマ・レベルのサプリメンタル・ロギング |
主キーの無条件のサプリメンタル・ロギングを有効化し、スキーマのすべての表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを有効化します。これらのキーは、すべてスケジューリング列と呼ばれます。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。 |
スキーマの現在および将来のすべての表でロギングを有効化します。主キー、一意キーおよび外部キーの列がソースとターゲットの両方で同じでない場合は、 |
|
サポートされるすべての列で無条件のロギングを使用したスキーマ・レベルのサプリメンタル・ロギング。(サポートされない列タイプの場合は、「スキーマ・レベルのサプリメンタル・ロギングの有効化」を参照してください。) |
|
スキーマのすべての表で、表のすべての列の無条件のサプリメンタル・ロギングを有効化します。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。 |
双方向およびアクティブ/アクティブ構成で使用され、そこでは更新または削除の実行時に、変更された列だけでなくすべての列値がチェックされます。より多くのリソースが消費されますが、最高レベルのリアルタイム・データ検証と競合検出が可能になります。 この方法は、初期ロードに |
スキーマ・レベルのサプリメンタル・ロギング、最小設定 |
|
スキーマのすべての表の主キーおよび有効なすべての一意索引の無条件のサプリメンタル・ロギングを有効化します。 また、この設定により、このスキーマで作成される新規オブジェクトに適切なサプリメンタル・ロギングが設定されます。 |
非統合Replicatにのみ使用します。これは、最低限必要なスキーマ・レベルのロギングです。 |
統合Replicatの組込みサポートを使用した表レベルのサプリメンタル・ロギング 「表レベルのサプリメンタル・ロギングの有効化」を参照してください |
|
主キーの無条件のサプリメンタル・ロギングを有効化し、表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを有効化します。これらのキーは、すべてスケジューリング列と呼ばれます。 |
スキーマ・レベルのサプリメンタル・ロギングが使用されていないかぎり、すべてのOracle GoldenGateユースケースで必要です。主キー、一意キーおよび外部キーの列がソースとターゲットの両方で同じでない場合は、 |
サポートされるすべての列で無条件のロギングを使用した表レベルのサプリメンタル・ロギング。(サポートされない列タイプの場合は、「表レベルのサプリメンタル・ロギングの有効化」を参照してください。) |
|
表のすべての列の無条件のサプリメンタル・ロギングを有効化します。 |
双方向およびアクティブ/アクティブ構成で使用され、そこでは更新または削除の実行時に、変更された列だけでなくすべての列値がチェックされます。より多くのリソースが消費されますが、最高レベルのリアルタイム・データ検証と競合検出が可能になります。 ソースおよびターゲットの主キー、一意キーおよび外部キーがソースとターゲット間で同一でないか、定期的に変更される場合にも使用できます。 |
表レベルのサプリメンタル・ロギング、最小設定 |
|
表の主キーおよび有効なすべての一意索引の無条件のサプリメンタル・ロギングを有効化します。 |
非統合Replicatおよび非パラレルReplicatに使用します。これは、最低限必要な表レベルのロギングです。 |
JSONリレーショナル二面性ビューおよびJSONコレクション表の表レベルのサプリメンタル・ロギング。 |
|
指定された二面性ビューおよびコレクション表のサプリメンタル・ロギングを有効にします。 |
ガイドラインは、「JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化」を参照してください。詳細は、「JSONリレーショナル二面性ビューおよびJSONコレクション表のサポートの詳細」も参照してください。 |
サブセット・データベース・レプリケーションのロギングの有効化
Oracleソース・データベースを強制ロギング・モードにすることを強くお薦めします。強制ロギング・モードでは、すべてのトランザクションおよびロードのロギングを強制し、反対にユーザーまたは記憶域の設定をオーバーライドします。これにより、Extract構成のソース・データが失われることがなくなります。
サブセット・データベース・レプリケーションと呼ばれる詳細なデータベース・サプリメンタル・ロギング・モードがあります。これは、すべてのOracle GoldenGateおよびXStreamクライアントの基本的な推奨モードです。これは、以前に使用していた最小サプリメンタル・ロギング・モードにかわるものです。
詳細は、Oracle Database SQL言語リファレンスのALTER DATABASE
を参照してください。
現時点では、サブセット・データベース・レプリケーション・ロギングは、CDB$ROOT
で有効になっています(これは、すべてのユーザーPDBに継承されます)。
ノート:
データベース・レベルの主キー(PK)および一意索引(UI)のロギングは、表のサブセットをレプリケートする場合にかぎり非推奨です。ライブ・スタンバイで使用することも、移行やアップグレードの停止時間を短縮するために、Oracle GoldenGateがすべての表をレプリケートする場合に使用することもできます。
次のステップを実行して、サブセット・データベース・レプリケーション・ロギングと強制ロギングを確認し、必要に応じて有効化します。
スキーマ・レベルのサプリメンタル・ロギングの有効化
Oracle GoldenGateでは、スキーマ・レベルのサプリメンタル・ロギングをサポートしています。スキーマ・レベルのロギングは、Oracle GoldenGateのDDLレプリケーション機能を使用する場合はOracleソース・データベースとターゲット・データベースで必要であり、レプリケートされる表でDDLを実行できる場合はソース・データベースで必要です。その他すべてのユースケースではオプションですが、表レベルのロギングをかわりに使用する必要があります(「表レベルのサプリメンタル・ロギングの有効化」を参照してください)。
スキーマ・レベルのロギングでは、デフォルトで主キーの無条件のサプリメンタル・ロギングを自動的に有効化し、スキーマのすべての表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを自動的に有効化します。必要に応じて、オプションでロギングを変更できます。
ノート:
ワイルドカード指定を満たす場合に、スキーマに追加される新しい表がキャプチャされるため、表レベルのロギングよりもスキーマ・レベルのロギングを使用することを強くお薦めします。キー列の変更がサプリメンタル・ログ・データにも自動的に反映されるため、この方法もお薦めします。たとえば、キーが変更された場合に、ADD TRANDATA
を発行する必要はありません。
次のステップをソース・システムで実行して、スキーマ・レベルのサプリメンタル・ロギングを有効化します。
表レベルのサプリメンタル・ロギングの有効化
表レベルのサプリメンタル・ロギングは、次の場合にソース・システムで有効化します。
-
スキーマ・レベルのロギングを使用しない場合に、必要なレベルのロギングを有効にする場合(「スキーマ・レベルのサプリメンタル・ロギングの有効化」を参照)。スキーマ・レベルまたは表レベルのロギングを使用する必要があります。表レベルのロギングでは、デフォルトで主キーの無条件のサプリメンタル・ロギングを自動的に有効化し、表の一意キーおよび外部キーの条件付きのサプリメンタル・ロギングを自動的に有効化します。必要に応じて、オプションでロギングを変更できます。
-
指定した表で主キーのロギングを回避する場合。
-
キー以外の列の値を表レベルで記録し、Oracle GoldenGateの特定の機能(フィルタリング、競合検出および解決ロジックなど)をサポートする場合。
-
表レベルのサプリメンタル・ロギングのみを持つ表でキー列が変更された場合は、表に対するDMLアクティビティを許可する前に、その表に対して
ADD TRANDATA
を実行する必要があります。 -
JSONリレーショナル二面性ビュー(JSON DV)およびJSONコレクション表のサプリメンタル・ロギングを有効にするには、「JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化」のガイドラインに従う必要があります。
次のステップをソース・システムで実行して、表レベルのサプリメンタル・ロギングを有効化するか、コマンドのオプションの機能を使用します。
-
ソース・システムでコマンドラインを実行します。
-
資格証明ストア内の、表レベルのサプリメンタル・ロギングを有効にする権限を持つユーザーの別名を使用して
DBLOGIN
コマンドを発行します。DBLOGIN USERIDALIAS alias
DBLOGIN
およびその他のオプションの詳細は、Oracle GoldenGateパラメータおよび機能リファレンスのUSERIDALIAS
を参照してください。 -
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
列を記録する必要があります。
-
-
ADD TRANDATA
にCOLS
オプションを使用する場合、ターゲットでそれらの列に一意の索引を作成して行の取得を最適化します。KEYCOLS
句の代替キーとしてこれらの列を記録する場合は、Oracle GoldenGateプロセスを構成するときにKEYCOLS
句をTABLE
およびMAP
文に追加する必要があります。
JSONリレーショナル二面性ビューおよびJSONコレクション表のサプリメンタル・ロギングの有効化
JSONリレーショナル二面性ビューおよびJSONコレクション表をレプリケートする前に、Oracle GoldenGateでサプリメンタル・ロギングを設定する必要があります。デフォルトでは、サプリメンタル・ロギングはJSONリレーショナル二面性ビューおよびJSONコレクション表に対して有効になっていません。二面性ビューおよびコレクション表のサプリメンタル・ロギングを有効にする場合は、次のガイドラインを使用できます:
-
論理レプリケーションの有効化: 二面性ビューおよびコレクション表に対する変更を取得するには、論理レプリケーションの有効化(
ADD TRANDATA
を使用)が必須です。このプロセスにより、JSONドキュメント・レベルで変更を追跡するために必要なサプリメンタル・ロギングが有効になります。詳細は、
ADD TRANDATA
を参照してください。Oracle Database 23ai側では、JSONリレーショナル二面性ビューおよびJSONコレクション表の
CREATE/ALTER DDL
に句が追加されています。この句を使用すると、ビュー・レベルでサプリメンタル・ロギングが有効になります。このロギングは、実表での既存のロギングに加えて行われます。詳細は、『Oracle Database SQL言語リファレンス』の
CREATE TABLE/CREATE JSON RELATIONAL DUALITY VIEW
およびALTER TABLE/ALTER JSON RELATIONAL DUALITY VIEWS
コマンドのlogical_replication_clauseの項を参照してください。 -
JSON二面性ビューおよびJSONコレクション表に対するDML変更:
INSERT
およびUPDATE
操作の場合、完全なJSONドキュメントおよび_id
キー属性がサプリメンタル・ログに記録されます。DELETE操作の場合、キー_id
属性のみがログに記録されます。 -
JSONリレーショナル二面性ビューのトランザクション・コミットのロギング:二面性ビューのサプリメンタル・ロギングは、コミット時に発生します。ネット・チェンジのみが記録されます。
たとえば、JSON二面性ビューを含むトランザクションでレコードを
INSERT
し、このレコードを2回UPDATE
した場合、論理変更は1つのみ存在し、更新されたレコードのINSERT
が含まれます。 -
基礎となる表を使用したJSON二面性ビューからJSON二面性ビューへのレプリケーション: 二面性ビューの基礎となるリレーショナル表レベルでのレプリケーションの変更は概ね効率的です。基礎となるリレーショナル表に基づく二面性ビューは、ビューであるため、これらの変更が自動的に反映されます。この場合、二面性ビューに追加のサプリメンタル・ロギングは必要ありません。
表レベルのサプリメンタル・ロギングを設定するステップは、「表レベルのサプリメンタル・ロギングの有効化」を参照してください。
表レベルのサプリメンタル・ロギングの削除
表をOracle GoldenGateで取得する必要がなくなり、表のTABLE
パラメータがExtractパラメータ・ファイルから削除されているか、またはTABLEEXCLUDE
を使用してワイルドカード文から表を除外している場合、サプリメンタル・ロギングを表から削除できます。
ノート:
Extractで、サプリメンタル・ロギングが有効になっていない表を解決すると、DML操作のタイプによっては異常終了します。
DELETE TRANDATA
を使用してサプリメンタル・ロギングを削除すると、Replicatの表のIDENTITYレベルはNOTHING
に設定されます。サプリメンタル・ロギングは、Microservices Architecture Webインタフェースを使用して、「管理サービス」、「構成」ページから、ソース・データベースに対して作成された「資格証明」で無効にするか、DELETE TRANDATA
コマンドを使用して発行できます。
次に、DELETE TRANDATA
を発行する構文を示します。
DBLOGIN USERIDALIAS alias_name
DELETE TRANDATA schema.tablename
サプリメンタル・ロギングのレベルをチェックするには、次のようにします。
INFO TRANDATA schema.tablename