データベース取り込みとレプリケーション > データベース取り込みとレプリケーション > データベース取り込みとレプリケーションソース - 準備と使用方法
  

データベース取り込みとレプリケーションソース - 準備と使用方法

データベース取り込みとレプリケーションタスクを初期ロード操作、増分ロード操作、または初期ロードと増分ロードの組み合わせ操作に設定する前に、ソースデータベースを準備し、ソースの使用に関する考慮事項を確認して、予期しない結果を回避します。

DB2 for iソース

データベース取り込みとレプリケーションタスクでDb2 for iソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

Db2 for iソースの変更キャプチャメカニズム

データベース取り込みとレプリケーションは、IBM i上のDb2ソースから変更データをキャプチャしてそのデータをターゲットに適用するための、単一の変更キャプチャメカニズムとアーキテクチャを提供します。
Secure Agentは、IBM iソースシステムとは別に、LinuxまたはWindowsボックスで実行する必要があります。IBM iシステムとSecure Agentボックス間のネットワーク帯域幅は堅牢でなければなりません。Informaticaでは、数百ギガビットまたは1ギガバイト以上のログデータを処理できるネットワーク転送速度を推奨しています。Db2がCDC対象のログデータを生成する速度以上の速度でログデータをSecure Agentに配信できるほどのネットワーク転送速度ではない場合、データベース取り込みジョブはタイムリーにデータをターゲットに提供できません。データスループットがSLAを満たしていない場合は、ハードウェアを変更して、IBM iシステムとSecure Agentボックス間のイーサネット帯域幅を増やすことを検討してください。
次の図は、Db2 for i変更キャプチャコンポーネントとデータフローを示しています。
  1. 1Secure Agent配下のDBMI Agentサービスで実行されるログコレクターは、Db2 for iのジャーナルされたデータに対するDb2 DISPLAY LOGコマンドに要求を送信します。
    2. 各要求には、開始RBAと、データベースの取り込み用のCDC対象のテーブルのリストが含まれます。
  2. 2このコマンドは、Db2ジャーナルおよびジャーナルレシーバーからソーステーブルのデータを要求します。
  3. 3このコマンドは、データを含むジャーナルエントリをUOW（Unit Of Work）マネージャに返します。
  4. 4UOWマネージャは、コミットされたトランザクション順にジャーナル処理済みデータをログパーサーに送信します。
  5. 5ログパーサーは、コミットされたトランザクションからのDML変更を解析します。CDCライターにデータを送信する前に、ログパーサーはデータをDb2ジャーナルデータの標準的な形式に変換します。この形式は、DBMI Agentタスクによって消費でき、ターゲットに適用できます。
    6. 注: このリソース集約型のアクティビティはSecure Agentボックスで発生するため、IBM iシステムのCPU消費は最小限に抑えられます。
  6. 6CDCライターが、フォーマットされたデータをターゲットに適用します。

データベース取り込みおよびレプリケーションのジャーナルレシーバ出口

データベース取り込みおよびレプリケーションは、変更データキャプチャ処理に使用されているDb2 for iジャーナルレシーバが削除されるのを防ぐための出口プログラムを提供しています。ジャーナルレシーバ出口を使用して、CDC中のジャーナルレシーバの削除に関連して発生する可能性があるエラーを防止します。
出口プログラムは、ジャーナルレシーバがデータベース取り込みおよびレプリケーションの増分ロードジョブまたは組み合わせロードジョブによって読み取られている間、ジャーナルレシーバをロックします。CDC処理中に出口プログラムがジャーナルレシーバのロックレコードを検出した場合、出口プログラムは、システムによってジャーナルレシーバが削除されないように防ぐ応答を返します。
データベース取り込みおよびレプリケーションジョブがチェーン上の次のジャーナルレシーバに切り替わると、データベース取り込みおよびレプリケーションは、最後に読み取られたジャーナルレシーバのロックレコードを削除し、次に読み取られるジャーナルレシーバのロックレコードを追加します。システムは、現在ロックされているレシーバの後に作成されたジャーナルレシーバは削除しません。
ジャーナルレシーバー出口の制御情報は、ソースシステム上のDb2 for iテーブルに格納されます。以下のカラムがテーブルに含まれています。
JOURNAL_RECEIVER_LIBRARYエントリとJOURNAL_RECEIVER_NAMEエントリの各組み合わせによって、変更データキャプチャ中に削除できないようにロックされるジャーナルレシーバインスタンスが識別されます。
ジャーナルレシーバ出口を使用するには、次の手順を実行します。
  1. 1ジャーナルレシーバ出口をインストールします。インストールプロセスによって、ジャーナルレシーバー削除出口プログラムがQIBM_QJO_DLT_JRNRCV出口ポイントに登録されます。詳細については、「データベース取り込みおよびレプリケーションのジャーナルレシーバ出口のインストール」を参照してください。
  2. 2Db2 for i CDCソースを持つ各タスクに対して、タスクウィザードの［ソース］ページで、次のカスタムプロパティを指定します。
    3. カスタムプロパティ
    説明
    pwx.cdcreader.iseries.option.useJournalReceiverExit
    このプロパティをtrueに設定すると、タスクからデプロイされたジョブインスタンスに対してジャーナルレシーバ出口を使用できるようになります。
    pwx.cdcreader.iseries.option.JournalReceiverExitJobToken
    pwx.cdcreader.iseries.option.useJournalReceiverExitがtrueに設定されている場合は、データベース取り込みおよびレプリケーションジョブのインスタンスごとに一意で最大256文字の長さのトークン文字列を指定する必要があります。
    トークン文字列がすべてのジョブインスタンスの間で一意でない場合、特に複数のジョブが同じジャーナルレシーバにアクセスしていると、予測不能な結果が生じる可能性があります。
    また、ジョブの再開操作または再デプロイ操作後もトークン値が変わらないことを確認してください。
    pwx.cdcreader.iseries.option.useJournalReceiverQueries
    このプロパティをtrueに設定すると、データベース取り込みおよびレプリケーションはDb2マシンのメンテナンスレベルを確認して、ジャーナルレシーバクエリを実行できるかどうかを判別できるようになります。

データベース取り込みおよびレプリケーションのジャーナルレシーバ出口のインストール

データ取り込みおよびレプリケーションのジャーナルレシーバ出口を使用して、Db2 for iジャーナルレシーバが変更データキャプチャで使用されている間に削除されるのを防ぎます。ジャーナルレシーバ出口を手動でインストールするには、次の手順を実行します。
  1. 1V01_Exit_Installファイルをコンピュータのローカルフォルダに解凍します。
  2. 2SQL_1.txtファイル内のSQL文を実行して、システムにインストール用の十分なスペースがあるかどうかを確認します。戻り値1は、システムに十分なスペースがあることを意味します。
  3. 3SQL_2.txtファイル内のSQL文を実行して、スキーマと、ジャーナルレシーバ出口ポイント処理用のデフォルトのジャーナルおよびジャーナルレシーバを作成します。
  4. 4FTP_3.txtファイル内のFTPコマンドを実行して、ジャーナルレシーバ出口をインストールします。
    5. 注: FTPを開始する前に、ジャーナルレシーバ出口プログラムが含まれているIBMi_SaveFile_V01.savfファイルがあるディレクトリに移動します。
  5. 5SQL_4.txtファイル内のSQL文を実行して、出口ポイントをIBM iシステムに追加します。
    6. 注: SQLを実行する前に、<userId>をシステムの有効なユーザーIDに置き換えてください。
  6. 6SQL_5.txtファイル内のSQL文を使用して、ジャーナルレシーバが削除されないようにロックするために使用するDb2オブジェクトを作成します。

DB2 for LUWソース

データベース取り込みとレプリケーションタスクでDb2 for Linux, UNIX, and Windows（LUW）ソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

DB2 for z/OSソース

データベース取り込みとレプリケーションタスクでDb2 for z/OSソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

Db2 for z/OS CDCのストアドプロシージャのインストールと設定

増分ロードジョブのDb2 for z/OS CDC処理を実行するために、データベース取り込みとレプリケーションは、z/OSソースシステムで実行されるストアドプロシージャを提供します。ストアドプロシージャは、Db2 Instrumentation Facility Interface（IFI）を呼び出して、Db2ログから変更データを収集します。

z/OSシステム要件

開始する前に、Db2 for z/OSソースシステムが次の要件を満たしていることを確認してください。

ストアドプロシージャライブラリをインストールし、JCLをカスタマイズします

クライアントマシンで、次の手順を実行します。
  1. 1Db2 for zOS Database Ingestionコネクタが使用可能であることを確認します。
    2. Db2 for zOS Database Ingestionコネクタパッケージには、Db2 for z/OSストアドプロシージャライブラリが含まれています。コネクタがSecure Agent Group（ランタイム環境）に対して有効になっている場合、コネクタパッケージの.zipファイルがインストール場所のダウンロードフォルダにダウンロードされます。パッケージ名の形式はpackage-DB2ZMIです。nnnnn。nnnnnは増分されたパッケージバージョン番号です。複数のパッケージバージョンが存在する場合は、最新のバージョンを使用してください。
  2. 2package-DB2ZMInnnnn.zipファイルを解凍します。ストアドプロシージャファイルは、パッケージ名の下のDb2WLMStoredProcedureフォルダに追加されます。
  3. 3FTPを使用して、Db2WLMStoredProcedureフォルダ内の#STPINSTファイルをz/OSシステム上のシーケンシャルファイル、PDS、またはPDSEに転送します。
    4. 注:
  4. 4FTPまたは別のファイル転送方法を使用して、次のファイルをそれぞれz/OSシステム上の別のデータセットに転送します。
    5. 注:
z/OSシステムでは、TSOを使用して送信（XMI）データセットをAPF許可ライブラリで受信し、ストアドプロシージャJCLメンバを編集します。また、DB2ユーザー特権を設定し、使用されている場合はリソース制限テーブルに行を追加します。
  1. 1DBRMLIB転送データセットを受信します。
    2. RECEIVE INDATASET(DBMI.ZOS.DBRMLIB.XMI)
    注:
  2. 2LOADLIB転送データセットを受信します。
    3. RECEIVE INDATASET(DBMI.ZOS.LOADLIB.XMI)
    手順1の注を参照してください。
  3. 3USERJCL転送データセットを受信します。
    4. RECEIVE INDATASET(DBMI.ZOS.USERJCL.XMI)
    手順1の注を参照してください。
  4. 4ご使用の環境のストアドプロシージャJCLを含む#STPINSTファイルをカスタマイズします。
    5. JCLは、データのDb2 IFIへの要求の結果を保持するストアドプロシージャとグローバル一時テーブルを作成します。また、ストアドプロシージャパッケージをバインドします。
    注:
  5. 5受信したUSERJCLデータセットのメンバのJCLをカスタマイズします。詳細については、「Db2 for z/OS USERJCLデータセット」を参照してください。
  6. 6ストアドプロシージャJCLジョブを実行する前に、必要なDB2権限が付与されていることを確認します。詳細については、DB2 for z/OSの権限を参照してください。
  7. 7データベース取り込みパッケージのDB2 DSNRLSTxxリソース制限テーブルに行を追加して、プロセッサリソースがストアドプロシージャの処理に十分であることを確認します。そうしないと、増分ロードジョブが異常終了する可能性があります。次のカラムを含む行を追加します。
    8. 次に、リソース制限テーブルへの変更を有効にするために、DB2 -START RLIMITコマンドを発行します。

Db2 for z/OS USERJCLデータセット

ダウンロードされたUSERJCLデータセットは区分データセット（PDS）または拡張区分データセット（PDSE）であり、Informatica提供のWLM Db2ストアドプロシージャの使用時に他の方法では容易に入手できない情報を収集するジョブを実行するためのJCLメンバが含まれています。
メンバJCLは、USERJCL PDSまたはPDSEで完全にカスタマイズできます。元のメンバが参照用にそのまま保持されるように、提供されたJCLメンバのコピーを別の名前で作成し、そのコピーをカスタマイズすることをお勧めします。
複数のDb2サブシステムに複数のストアドプロシージャをインストールする場合、インストールできるUSERJCLライブラリは1つだけで、そのライブラリにDb2サブシステムごとに合わせてカスタマイズしたメンバを作成できます。あるいは、特定のDb2サブシステム用に別のライブラリを作成することもできます。データベース取り込みとレプリケーションジョブに、Db2サブシステムの正しいライブラリおよびメンバ情報が含まれていることを確認してください。
USERJCL PDSまたはPDSEには、以下のメンバが含まれています。
LOGINVメンバ
LOGINVには、Db2ログインベントリリストを取得するジョブのJCLが含まれています。タスクウィザードで取り込みタスクの［増分ロード操作の当初の開始点］プロパティを［特定の日付と時刻］に設定した場合、インベントリリストを使用して、データベース取り込みとレプリケーションジョブの初回実行時または再開時にログ内の開始点が決定されます。ログインベントリリストはデータベース取り込みとレプリケーションに、開始RBAまたはLSNと終了RBAまたはLRSN、およびDb2サブシステムのすべてのアクティブログとアーカイブログの開始タイムスタンプと終了タイムスタンプを提供します。データベース取り込みとレプリケーションは、この情報を使用して適切なログアーカイブを選択し、要求された開始点を検索します。［増分ロード操作の当初の開始点］プロパティが［特定の日付と時刻］以外のオプションに設定されている場合は、USERJCLライブラリをインストールする必要はありません。
LOGINVメンバの内容:
//<USERID>I JOB 'LOG INVENTORY',MSGLEVEL=(1,1),MSGCLASS=X,
// NOTIFY=&SYSUID,CLASS=A,REGION=0M
//* -------------------------------------------------------
//*
//* PLEASE CHANGE DSN? TO THE DB2 SUBSYSTEM OF YOUR CHOICE.
//*
//* THIS JCL MEMBER CAN BE USED TO RUN A LOG INVENTORY
//* LIST. DBMI WILL REQUEST THIS IF A DBMI JOB IS TRYING TO
//* RETART USING TIME. THE LOG INVERNTORY GIVES DBMI THE
//* ABILITY TO CORRELATE RBA/LSRN TO ACTUAL LOG RESTART
//* POSITIONS. DBMI PARSES THE SYSPRINT OUTPUT TO GET THE
//* REQUIRED INFORMATION.
//*
//*
//* SUBSTITUTION TAGS
//* _________________
//*
//* SUBSTITUTION TAGS ARE USED TO INSERT DATA INTO THE JOB
//* BY DBMI BEFORE IT IS SUBMITTED. YOU MAY COPY THIS JCL
//* INTO ANOTHER MEMBER AND MODIFY ITS CONTENTS. SUBSTITUTION
//* TAGS MAY ALSO BE REMOVED AND HARD CODED FOR INDIVIDUAL
//* JOB NEEDS.
//*
//*
//* <USERID> WILL BE REPLACED WITH THE USER ID.
//*
//* -------------------------------------------------------
//LOGINV EXEC PGM=DSNJU004
//STEPLIB DD DISP=SHR,DSN=DSN?10.SDSNLOAD
// DD DISP=SHR,DSN=DSN?10.DSNC.RUNLIB.LOAD
//SYSUT1 DD DISP=SHR,DSN=DSN?.BSDS01
//SYSPRINT DD SYSOUT=*
//SYSSUMRY DD SYSOUT=*
//
USERJCLメンバジョブをサブミットし、サブミットされたジョブから出力を取得するために、データベース取り込みとレプリケーションは、必要に応じてDb2提供のストアドプロシージャをバッチで実行します。データベース取り込みとレプリケーションユーザーが、これらのストアドプロシージャを実行するために必要な特権を持っていることを確認します。Db2提供のプロシージャの詳細については、https://www.ibm.com/docs/en/db2-for-zos/12?topic=sql-procedures-that-are-supplied-db2を参照してください。
USERJCLメンバは、次のように処理されます。
  1. 1LOGINVメンバの場合、データベース取り込みとレプリケーションタスクウィザードの［ソース］ページで［増分ロード操作の当初の開始点］詳細プロパティが［特定の日付と時刻］に設定されている場合、データベース取り込みとレプリケーションは、ソースに次のカスタムプロパティが指定されているかどうかをチェックします。
  2. 2データベース取り込みとレプリケーションは、Db2提供のストアドプロシージャADMIN_DS_BROWSEを使用してLOGINVメンバを読み取ります。
  3. 3データベース取り込みとレプリケーションは、ジョブの実行に必要なタグを置き換えます。
  4. 4データベース取り込みとレプリケーションは、Db2提供のストアドプロシージャADMIN_SUBMIT_JOBを使用して、ジョブをDb2 for z/OSデータベースにサブミットします。
  5. 5データベース取り込みとレプリケーションは、Db2提供のストアドプロシージャADMIN_JOB_QUERYを使用して、サブミットされたジョブのステータスを照会します。
  6. 6ジョブが完了すると、データベース取り込みとレプリケーションは、Db2提供のストアドプロシージャADMIN_JOB_FETCHを使用して、ジョブ出力を取得します。

DB2 for z/OSの権限

Db2 for z/OSソースを持つデータベース取り込みとレプリケーションタスクをデプロイして実行するには、ソース接続で取り込みロードタイプに必要な特権を持つデータベース取り込みとレプリケーションユーザーを指定する必要があります。
初期ロード処理の特権
増分ロード処理の特権
増分ロードジョブの場合は、次の特権を付与します。
注: これらを付与するために必要な権限がない場合は、SYSDBA権限以上の権限レベルを持つDB2管理者に発行を依頼してください。
z/OSでストアドプロシージャを実行するために必要な権限
ストアドプロシージャJCLジョブを実行する前に、次のDB2権限が付与されていることを確認します。
さらに、グローバル一時テーブルのJCLで指定されているスキーマおよびストアドプロシージャ名に対するINSERTおよびDELETE権限を付与します。
GRANT INSERT, DELETE ON schema.stored_procedure_name_RS_TBL TO user

Db2 for z/OSソースの変更キャプチャメカニズム

データベース取り込みとレプリケーションは、z/OS上のDb2ソースから変更データをキャプチャしてそのデータをターゲットに適用するための、単一の変更キャプチャメカニズムとアーキテクチャを提供します。このアーキテクチャはマルチスレッド処理を使用して、データの収集と、データの解析およびターゲットが受け入れる形式への変換のパフォーマンスを最適化します。
Secure Agentは、Db2 z/OSソースシステムとは別に、LinuxまたはWindowsボックスで実行する必要があります。z/OSシステムとSecure Agentボックス間のネットワーク帯域幅は堅牢でなければなりません。Informaticaでは、数百ギガバイトまたは1ギガビット以上のログデータを処理できるネットワーク転送速度を推奨しています。Db2がCDC対象のログデータを生成する速度以上の速度でログデータをSecure Agentに配信できるほどのネットワーク転送速度ではない場合、データベース取り込みとレプリケーションジョブはタイムリーにデータをターゲットに提供できません。データスループットがSLAを満たしていない場合は、ハードウェアを変更して、z/OSシステムとSecure Agentボックス間のイーサネット帯域幅を増やすことを検討してください。
次の図は、Db2 for z/OS変更キャプチャコンポーネントとデータフローを示しています。
  1. 1Secure Agent配下のDBMI Agentサービスで実行されるマルチスレッドログコレクタは、Db2ログデータの複数の同時要求をDb2ストアドプロシージャに発行します。
    2. 各要求には、開始RBA、またはログがデータ共有環境にある場合は開始LRSNと、データベース取り込み用のCDC対象のテーブルのリストが含まれます。
    一連のログデータの処理中に、ログコレクタは次の一連のログデータを要求できます。
  2. 2Db2 Instrumentation Facility Interface（IFI）APIは、アクティブログとアーカイブログから、CDC対象の選択したソーステーブルのデータを抽出します。その後、IFIはデータを未加工のネイティブ形式で、z/OS Workload Manager（WLM）のInformatica Db2ストアドプロシージャに転送します。
  3. 3Db2ストアドプロシージャは、キャプチャされたデータとともにUOWをUOWマネージャに返します。
  4. 4UOWマネージャは、UOWをコミット順にログパーサーに送信します。
  5. 5マルチスレッドログパーサーは、コミットされたUOWからのDML変更を同時に解析します。結果は、ターゲットタイプが期待する形式の未加工のネイティブDb2ログデータです。
    6. 注: このリソース集約型のアクティビティはSecure Agentボックスで発生するため、z/OSシステムのCPU消費は最小限に抑えられます。
  6. 6CDCライターが、フォーマットされたデータをターゲットに適用します。

Microsoft SQL Server、RDS for SQL Server、Azure SQL Database、Azure Managed Instanceソース

データベース取り込みとレプリケーションタスクでMicrosoft SQL Serverソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。SQL Serverソースタイプには、オンプレミスのSQL Server、Relational Database Service（RDS）for SQL Server、Azure SQL Database、およびAzure SQL Managed Instanceが含まれます。

ソースの準備:

使用に関する考慮事項:

SQL Server権限

SQL Serverソースからデータをレプリケートするには、データベース取り込みとレプリケーションユーザーに一部のSQL Server権限を付与する必要があります。

SQL Server CDCの有効化の前提条件

変更をキャプチャするには、［ログベース］または［CDCテーブル］のキャプチャメソッドを使用している増分ロードジョブと組み合わせロードジョブのデータベースとソーステーブルでSQL Server CDCを有効にする必要があります。
データベースでCDCを有効にするには、次の手順を実行します。
SQL ServerソーステーブルでCDCを有効にするには、db_ownerロールが割り当てられていることを確認し、次のコマンドを実行します。
EXEC sys.sp_cdc_enable_table @source_schema = N'<schemaname>', @source_name = N'<tablename>', @role_name = NULL;
注: sp_cdc_enable_tableの構文には、最低限必要な引数が含まれています。より多くの引数を使用することができます。詳細については、WebSphereサーバーのマニュアルを参照してください。

データのレプリケートに必要な権限

必要な権限は、ジョブのロードタイプとCDCメソッドに応じて異なります。
ユーザーの作成
データベース接続には、マスタデータベースおよびソースデータベースでログインユーザーを作成する必要があります。
USE master;
CREATE DATABASE <DB>;
CREATE LOGIN <login_name> WITH PASSWORD = '<password>';
CREATE USER <user> FOR LOGIN <login_name>;

USE <DB>;
CREATE USER <user> FOR LOGIN <login_name>;
初期ロードジョブに対する権限
初期ロードジョブには、次の最小限の権限が必要です。
GRANT SELECT ON <table> TO <user>;
GRANT SELECT ON sys.system_internals_partition_columns to <user>;
増分ロードジョブ、および初期ロードと増分ロードの組み合わせジョブに対する権限
増分ロードジョブと組み合わせロードジョブの場合、初期ロードジョブに対して上記の最小限の権限に加えて、増分CDC処理に必要な追加の権限がいくつか必要となります。CDCの権限は、使用するCDCメソッドに応じて異なります。

SQL Serverソースの変更キャプチャメカニズム

データベース取り込みとレプリケーションは、SQL Serverソースから変更データをキャプチャしてそのデータをターゲットに適用するための、複数の変更キャプチャメカニズムを提供します。

トランザクションログとCDCテーブルを使用するログベースの変更データキャプチャ

ログベースのCDCを使用するデータベース取り込みとレプリケーションの増分ロードジョブは、アクティブなトランザクションログからレコードを解析し、CDCテーブルから変更レコードを直接読み取ることで、DMLとDDLの変更をキャプチャします。必要な再開ポイント（LSN）が利用可能な場合、変更データはアクティブなトランザクションログから読み取られます。キャプチャ開始点がトランザクションログ内のレコードより前の日付である場合、またはその他の特定の状況では、データベース取り込みとレプリケーションは自動的にCDCテーブルからの変更データの読み取りに移行します。CDCテーブルから変更を読み取った後、データベース取り込みとレプリケーションは、トランスペアレントな方法でアクティブなトランザクションログの読み取りに戻ります。
ログベースの変更キャプチャ処理には、次のコンポーネントが関わります。
次の図は、SQL Serverのログベースの変更データキャプチャコンポーネントとデータフローを示しています。
  1. 1ログリーダープロセスは、ログレコードを読み取り、コミットされたトランザクションのDMLおよびDDLの変更をキャプチャします。
    2. キャプチャプロセスは、コミットされたトランザクションが完了するか、致命的なエラーによってキャプチャプロセスが停止または中断されるか、cdc.<capture_instance>_CTテーブルからの変更レコードの読み取りへの切り替えがトリガーされるまで続行されます。
  2. 2特定の状況では、データベース取り込みとレプリケーションは、CDCキャプチャインスタンステーブルリーダーを使用して、cdc.<capture instance>_CTテーブルからの変更の読み取りに自動的に切り替わります。
    3. 以下の条件下では、処理は、cdc.<capture instance>_CTテーブルに切り替わります。
  3. 3ログリーダーとCDCキャプチャインスタンステーブルリーダーは、変更レコードをCDCライターに送信します。
  4. 4CDCライターは変更レコードをフォーマットし、ターゲットに適用します。

CDCテーブルのみを使用した変更キャプチャ

データベース取り込みとレプリケーションの増分ロードジョブは、トランザクションログを使用せずにSQL Server CDCテーブルから直接変更をキャプチャできるようになりました。
CDCテーブルのみを使用する変更キャプチャ処理には、次のコンポーネントが関わります。
次の図は、SQL Serverのログベースの変更データキャプチャコンポーネントとデータフローを示しています。
  1. 1CDCキャプチャインスタンステーブルリーダーはcdcから変更を読み取ります。<capture instance>_CTテーブル内に存在する場合、キャプチャプロセスの初期化および開始中である。
  2. 2CDCキャプチャインスタンステーブルリーダーは変更レコードをCDCライターに送信します。
  3. 3CDCライターは変更レコードをフォーマットし、ターゲットに適用します。

クエリベースの変更キャプチャ

データベース取り込みとレプリケーションの増分ロードジョブは、変更が発生したときに更新されるタイムスタンプカラムを照会することにで、ソースにおける挿入と更新の変更をキャプチャします。ソースの設定は、各ソーステーブルへの共通CDCクエリカラムの追加に制限されます。クエリベースのCDCメソッドはクエリカラムを使用して、指定のCDC間隔の開始以降に変更された行を識別します。
クエリベースの変更キャプチャを実装するには、タスクウィザードの［ソース］ページで次のオプションを設定します。
CDC間隔が経過した後、データベース取り込みとレプリケーションは、CDCクエリカラムを参照するWHERE句を含むSQLクエリを使用して、CDC間隔の間に変更を受け取った行を識別します。変更データがキャプチャされ、ターゲットに適用されます。
クエリベースのCDC用に選択されたソーステーブルにCDCクエリカラムがない場合、変更データキャプチャはこれらのテーブルを無視し、残りのテーブルで処理を続行します。スキップされたテーブルの場合、ターゲットデータベースで生成された、対応するテーブルは空になります。どのソーステーブルにもCDCクエリカラムがない場合、ジョブは実行時に失敗します。
次の図は、SQL Serverのクエリベースの変更データキャプチャコンポーネントとデータフローを示しています。
  1. 1CDC間隔が経過した後、データベース取り込みとレプリケーションは、CDCクエリカラムを使用して変更データを抽出するSQLクエリをソースデータベースで実行します。
  2. 2変更レコードがCDCライターに送信されます。
  3. 3CDCライターは変更レコードをフォーマットし、ターゲットに適用します。

MongoDBソース

データベース取り込みとレプリケーションタスクでMongoDBソースを使用するには、以下の考慮事項を確認してください。

ソースの準備:

{ resource:
{ db: "", collection: "" }
, actions: [ "find", "changeStream" ] }

使用に関する考慮事項:

MySQLソース

データベース取り込みとレプリケーションタスクでMySQLソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

Netezzaソース

データベース取り込みとレプリケーションタスクでNetezzaソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

Oracleソース

データベース取り込みとレプリケーションタスクでOracleソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

Oracleソース準備用のAmazon Relational Database Service（RDS）:
  1. 1RDSファイルシステム上にオンラインREDOログとアーカイブREDOログをそれぞれ保持するONLINELOG_DIRディレクトリおよびARCHIVELOG_DIRのディレクトリを作成します。次の実行文を使用します。
    2. exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
    exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
  2. 2Amazon RDS for Oracleソースタイプに必要なOracle特権をデータベース取り込みとレプリケーションユーザーに付与します。
    3. Amazon RDS for Oracleソースに必要な特権の詳細については、Amazon RDS for Oracleソースに対するOracle特権を参照してください。
  3. 3アーカイブREDOログの適切な保持時間を定義します。次の実行文を使用します。
    4. exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention days',number_of_days);
  4. 4Amazon RDSコンソールで、データベースインスタンスの自動バックアップを有効にするために、ソースデータベースのバックアップ保持期間を0より大きい値に設定します。
    5. 注: この手順では、データベースに対してARCHIVELOGモードを有効にします。
  5. 5データベースレベルでサプリメンタルロギングが有効になっていることを確認します。次の文を使用します。
    6. exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
    データベース取り込みとレプリケーションタスクを作成するときに、選択したソーステーブルのサプリメンタルロギングを有効にするスクリプトを生成できます。
  6. 6オプションで、Amazon RDSコンソールでは、パラメータグループを作成し、デフォルトのバッファープールのキャッシュサイズを定義することができます。デフォルトのバッファプールは、プライマリデータベースのブロックサイズを使用するバッファを保持します。次のDB_CACHE_SIZEパラメータ値を使用します。
    7. 次に、ソースデータベースのパラメーターグループを選択します。

使用に関する考慮事項:

データベース取り込みとレプリケーション環境に関する情報の収集

データベース取り込みとレプリケーションタスクの作成を開始する前に、以下の情報を収集してください。

全般的な情報

どのOracleバージョンを使用しているか。
答え: ___________________________________________________
Oracleをオンプレミスで実行するか、それともクラウドベースのAmazon RDS for Oracle環境で実行するか。
答え: ___________________________________________________
ターゲットタイプは何か。
答え: ___________________________________________________
どのタイプのロード操作を実行する予定か。初期ロード（ポイントインタイムバルクロード）、増分ロード（変更のみ）、または初期ロードと増分ロードの組み合わせ（初期ロードとそれに続く増分ロード）のどれか。
答え: ___________________________________________________
Secure Agentを実行するシステムのコア数、メモリ量、およびディスク容量はいくつか。
答え: ___________________________________________________

Oracle環境

Oracleソースデータベースサーバーのホスト名とポート番号は何か。
答え: ___________________________________________________
データベースのOracleシステム識別子（SID）は何か。
答え: ___________________________________________________
データベースへの接続に使用するOracleデータベースのユーザー名とパスワードは何ですか?
答え: ___________________________________________________
Secure Agentを実行するシステムにOracle Database ClientまたはInstant Clientがインストールされていますか?
答え: ___________________________________________________
データベースはOracle Real Application Cluster（RAC）で実行されますか? 非アクティブなノードを含め、RACメンバーの最大数はいくつですか?
答え: ___________________________________________________
Oracle Data Guardの論理または物理スタンバイデータベースから変更データをキャプチャする必要があるか。
答え: ___________________________________________________
Oracleマルチテナント環境のプラガブルデータベース（PDB）のテーブルから変更データをキャプチャする必要がありますか?
答え: ___________________________________________________
Oracle Transparent Data Encyrption（TDE）を使用するテーブルスペースから変更データをキャプチャする必要がありますか? はいの場合、TDEウォレットディレクトリとパスワードは何ですか?
答え: ___________________________________________________
ソーステーブルのUnit of Work（UOW）の一般的なサイズはいくつか。
答え: ___________________________________________________

Oracle REDOログ

REDOログはOracle Automatic Storage Management（ASM）環境にありますか? ASMインスタンスに接続してREDOログを読み取る場合に、SYSDBAまたはSYSASM権限を持つASMのログインユーザーIDの作成を許可されているか。
答え: ___________________________________________________
OracleソースデータベースのARCHIVELOGモードと最少グローバル補足ログが有効になっているか。されていない場合は、有効にできるか。
答え: ___________________________________________________
変更データを読み取るアーカイブREDOログのプライマリおよびセカンダリアーカイブ先はどこか。
答え: ___________________________________________________
Oracleデータベースのピーク期間中とピーク期間外に作成されるアーカイブREDOログの1時間あたりの平均量はいくつか。
答え: ___________________________________________________
使用している環境のREDOログへの読み取りアクセスを持っているか。
答え: ___________________________________________________
REDOログを直接読み取る権限を持っていない場合、アーカイブREDOログファイルを共有ディスクまたはファイルシステムにコピーし、その共有ディスクまたはファイルシステムから、コピーしたREDOログファイルにアクセスできるか。
答え: ___________________________________________________
データベース取り込みとレプリケーションで、アーカイブログだけでなくオンラインログから変更データを読み取れるようにするか。
答え: ___________________________________________________
CDC処理中のエラーまたは異常を診断するために、必要に応じて、診断に使用するアーカイブREDOログをInformaticaグローバルカスタマサポートに提供できるか。
答え: ___________________________________________________

データベース取り込みを設定するための詳細情報

データのレプリケート元となるソーステーブルのスキーマ名は何か。
答え: ___________________________________________________
スキーマ内のすべてのテーブルまたはそれらのテーブルのサブセットからデータをレプリケートするか。サブセットの場合は、それらのリストを作成してください。
答え: ___________________________________________________
ソーステーブルにプライマリキーがあるか。すべてのプライマリキーに対して補足ログを有効にできるか。
答え: ___________________________________________________
キーなしのソーステーブルはあるか。
答え: ___________________________________________________
ソーステーブルに、サポートされていないデータ型のカラムが含まれているか。ソースタイプでサポートされていないデータ型を判別するには、データベース取り込みとレプリケーションヘルプの「データベース取り込みとレプリケーションのソースに関する考慮事項」のソース固有のトピックを参照してください。
答え: ___________________________________________________
UTF-8のデフォルトのコードページは容認できるか。できない場合、どのコードページを使用するか。
答え: ___________________________________________________
SSLを使用して、Secure Agentとデータベースサーバー間で交換するデータを暗号化するか。暗号化SSLまたはTLSプロトコルはどれを使用するか。
答え: ___________________________________________________
新しいOracleユーザーを作成し、データベース取り込みとレプリケーションで必要となる特権をそのユーザーに割り当てることができるか。使用するユーザー名を決定してください。
答え: ___________________________________________________
ソーステーブルに、データベース取り込みとレプリケーションがサポートしていないOracleデータ型が含まれているか。
答え: ___________________________________________________
カラムの追加、削除、変更、名前変更操作など、ソースでのスキーマドリフトの変更をキャプチャするか。
答え: ___________________________________________________

Oracle特権

Oracleソースを持つデータベース取り込みとレプリケーションタスクをデプロイして実行するには、ソース接続で取り込みロードタイプに必要な特権を持つデータベース取り込みとレプリケーションユーザーを指定する必要があります。
ログベースのCDCを使用した増分ロード処理の権限
注: OracleログがASMによって管理されている場合、ユーザーはSYSASMまたはSYSDBA権限を持っている必要があります。
ログベースのCDCメソッドを使用した増分ロードまたは、初期ロードと増分ロードの組み合わせを実行するデータベース取り込みとレプリケーションタスクの場合、データベース取り込みとレプリケーションユーザー（cmid_user）に次の権限が付与されていることを確認してください。
GRANT CREATE SESSION TO <cmid_user>;

GRANT SELECT ON table TO <cmid_user>; -- For each source table created by user

-- The following grants are required for combined initial and incremental loads only. Do not
-- use ANY TABLE unless your security policy allows it.
GRANT EXECUTE ON DBMS_FLASHBACK TO <cmid_user>;
GRANT FLASHBACK ON table|ANY TABLE TO <cmid_user>;

-- Include the following grant only if you want to Execute the CDC script for enabling
-- supplemental logging from the user interface. If you manually enable supplemental
-- logging, this grant is not needed.
GRANT ALTER table|ANY TABLE TO <cmid_user>;

GRANT SELECT ON DBA_CONSTRAINTS TO <cmid_user>;
GRANT SELECT ON DBA_CONS_COLUMNS TO <cmid_user>;
GRANT SELECT ON DBA_INDEXES TO <cmid_user>;
GRANT SELECT ON DBA_LOG_GROUPS TO <cmid_user>;
GRANT SELECT ON DBA_LOG_GROUP_COLUMNS TO <cmid_user>;
GRANT SELECT ON DBA_OBJECTS TO <cmid_user>;
GRANT SELECT ON DBA_OBJECT_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_TABLESPACES TO <cmid_user>;
GRANT SELECT ON DBA_USERS TO <cmid_user>;

GRANT SELECT ON "PUBLIC".V$ARCHIVED_LOG TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$CONTAINERS TO <cmid_user>; -- For Oracle multitenant environments
GRANT SELECT ON "PUBLIC".V$DATABASE TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$DATABASE_INCARNATION TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$ENCRYPTION_WALLET TO <cmid_user>; -- For Oracle TDE access
GRANT SELECT ON "PUBLIC".V$LOG TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$LOGFILE TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$PARAMETER TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$PDBS TO <cmid_user>; -- For Oracle multitenant environments
GRANT SELECT ON "PUBLIC".V$SPPARAMETER TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$STANDBY_LOG TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$THREAD TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$TRANSACTION TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$TRANSPORTABLE_PLATFORM TO <cmid_user>;
GRANT SELECT ON "PUBLIC".V$VERSION TO <cmid_user>;

GRANT SELECT ON SYS.ATTRCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CDEF$ TO <cmid_user>;
GRANT SELECT ON SYS.COL$ TO <cmid_user>;
GRANT SELECT ON SYS.COLTYPE$ TO <cmid_user>;
GRANT SELECT ON SYS.IDNSEQ$ TO <cmid_user>;
GRANT SELECT ON SYS.IND$ TO <cmid_user>;
GRANT SELECT ON SYS.INDPART$ TO <cmid_user>;
GRANT SELECT ON SYS.OBJ$ TO <cmid_user>;
GRANT SELECT ON SYS.PARTOBJ$ TO <cmid_user>;
GRANT SELECT ON SYS.RECYCLEBIN$ TO <cmid_user>;
GRANT SELECT ON SYS.TAB$ TO <cmid_user>;
GRANT SELECT ON SYS.TABCOMPART$ TO <cmid_user>;
GRANT SELECT ON SYS.TABPART$ TO <cmid_user>;
GRANT SELECT ON SYS.TABSUBPART$ TO <cmid_user>;

-- Also ensure that you have access to the following ALL_* views:
ALL_CONSTRAINTS
ALL_CONS_COLUMNS
ALL_ENCRYPTED_COLUMNS
ALL_INDEXES
ALL_IND_COLUMNS
ALL_OBJECTS
ALL_TABLES
ALL_TAB_COLS
ALL_TAB_PARTITIONS
ALL_USERS
クエリベースのCDCを使用した増分ロード処理の権限
クエリベースのCDCメソッドを使用した増分ロード、または初期ロードと増分ロードの組み合わせを実行するデータベース取り込みとレプリケーションタスクの場合、ユーザーが少なくとも次の特権を持っていることを確認してください。
GRANT CREATE SESSION TO <cmid_user>;

GRANT SELECT ON DBA_INDEXES TO <cmid_user>;
GRANT SELECT ON DBA_OBJECT_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_OBJECTS TO cmid_user;
GRANT SELECT ON DBA_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_USERS TO <cmid_user>;
GRANT SELECT ON DBA_VIEWS TO <cmid_user>; -- Only if you unload data from views

GRANT SELECT ANY TABLE TO <cmid_user>;
-or-
GRANT SELECT ON table TO <cmid_user>; -- For each source table created by user

GRANT SELECT ON ALL_CONSTRAINTS TO <cmid_user>;
GRANT SELECT ON ALL_CONS_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_IND_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_INDEXES TO <cmid_user>;
GRANT SELECT ON ALL_OBJECTS TO <cmid_user>;
GRANT SELECT ON ALL_TAB_COLS TO <cmid_user>;
GRANT SELECT ON ALL_USERS TO <cmid_user>;

GRANT SELECT ON "PUBLIC"."V$DATABASE" TO cmid_user;
GRANT SELECT ON "PUBLIC"."V$CONTAINERS" TO cmid_user;
GRANT SELECT ON SYS.ATTRCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CDEF$ TO <cmid_user>;
GRANT SELECT ON SYS.COL$ TO <cmid_user>;
GRANT SELECT ON SYS.COLTYPE$ TO <cmid_user>;
GRANT SELECT ON SYS.IND$ TO <cmid_user>;
GRANT SELECT ON SYS.IDNSEQ$ TO cmid_user;
GRANT SELECT ON SYS.OBJ$ TO <cmid_user>;
GRANT SELECT ON SYS.RECYCLEBIN$ TO <cmid_user>;
GRANT SELECT ON SYS.TAB$ TO <cmid_user>;
初期ロード処理の特権
初期ロードを実行するデータベース取り込みとレプリケーションタスクの場合、ユーザーが少なくとも次の権限を持っていることを確認してください。
GRANT CREATE SESSION TO <cmid_user>;

GRANT SELECT ON DBA_INDEXES TO <cmid_user>;
GRANT SELECT ON DBA_OBJECT_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_OBJECTS TO cmid_user;
GRANT SELECT ON DBA_TABLES TO <cmid_user>;
GRANT SELECT ON DBA_USERS TO <cmid_user>;
GRANT SELECT ON DBA_VIEWS TO <cmid_user>; -- Only if you unload data from views

GRANT SELECT ANY TABLE TO <cmid_user>;
-or-
GRANT SELECT ON table TO <cmid_user>; -- For each source table created by user

GRANT SELECT ON ALL_CONSTRAINTS TO <cmid_user>;
GRANT SELECT ON ALL_CONS_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_IND_COLUMNS TO <cmid_user>;
GRANT SELECT ON ALL_INDEXES TO <cmid_user>;
GRANT SELECT ON ALL_OBJECTS TO <cmid_user>;
GRANT SELECT ON ALL_TAB_COLS TO <cmid_user>;
GRANT SELECT ON ALL_USERS TO <cmid_user>;

GRANT SELECT ON "PUBLIC"."V$DATABASE" TO cmid_user;
GRANT SELECT ON "PUBLIC"."V$CONTAINERS" TO cmid_user;
GRANT SELECT ON SYS.ATTRCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CCOL$ TO <cmid_user>;
GRANT SELECT ON SYS.CDEF$ TO <cmid_user>;
GRANT SELECT ON SYS.COL$ TO <cmid_user>;
GRANT SELECT ON SYS.COLTYPE$ TO <cmid_user>;
GRANT SELECT ON SYS.IND$ TO <cmid_user>;
GRANT SELECT ON SYS.IDNSEQ$ TO cmid_user;
GRANT SELECT ON SYS.OBJ$ TO <cmid_user>;
GRANT SELECT ON SYS.RECYCLEBIN$ TO <cmid_user>;
GRANT SELECT ON SYS.TAB$ TO <cmid_user>;

Amazon RDS for Oracleソースに対するOracle特権

Amazon RDS for Oracleソースを使用している場合は、データベース取り込みとレプリケーションユーザーに特定の権限を付与する必要があります。
重要: GRANT文とプロシージャを実行するには、マスターユーザー名でAmazon RDSにログインする必要があります。
少なくとも、CDC処理に必要なオブジェクトおよびシステムテーブルに対するSELECT特権を、データベース取り込みとレプリケーションユーザー（cmid_user）に付与します。特定の状況では、追加の権限の付与が必要になります。
次のGRANT文を使用します。
GRANT SELECT ON "PUBLIC"."V$ARCHIVED_LOG" TO "cmid_user";

GRANT SELECT ON "PUBLIC"."V$DATABASE" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$LOG" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$LOGFILE" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$TRANSPORTABLE_PLATFORM" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$THREAD" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$DATABASE_INCARNATION" TO "cmid_user";
GRANT SELECT ON "PUBLIC"."V$TRANSACTION" TO "cmid_user";

GRANT SELECT ON "SYS"."DBA_CONS_COLUMNS" TO "cmid_user";
GRANT SELECT ON "SYS"."DBA_CONSTRAINTS" TO "cmid_user";
GRANT SELECT ON DBA_INDEXES TO "cmid_user";
GRANT SELECT ON "SYS"."DBA_LOG_GROUP_COLUMNS" TO "cmid_user";
GRANT SELECT ON "SYS"."DBA_TABLESPACES" TO "cmid_user";

GRANT SELECT ON "SYS"."OBJ$" TO "cmid_user";
GRANT SELECT ON "SYS"."TAB$" TO "cmid_user";
GRANT SELECT ON "SYS"."IND$" TO "cmid_user";
GRANT SELECT ON "SYS"."COL$" TO "cmid_user";

GRANT SELECT ON "SYS"."PARTOBJ$" TO "cmid_user";
GRANT SELECT ON "SYS"."TABPART$" TO "cmid_user";
GRANT SELECT ON "SYS"."TABCOMPART$" TO "cmid_user";
GRANT SELECT ON "SYS"."TABSUBPART$" TO "cmid_user";
COMMIT;

/* For combined load jobs:*/
GRANT EXECUTE ON DBMS_FLASHBACK TO "cmid_user";

/*To provide read access to the Amazon RDS online and archived redo logs:*/
GRANT READ ON DIRECTORY ONLINELOG_DIR TO "cmid_user";
GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO "cmid_user";
さらに、マスターユーザーとしてログインし、次のAmazon RDSプロシージャを実行して、さらにいくつかのオブジェクトに対するSELECT特権を付与します。
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'DBA_TABLES',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'DBA_OBJECTS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'DBA_OBJECT_TABLES',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'DBA_VIEWS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
/begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'DBA_USERS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT',
p_grant_option => false);
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$CONTAINERS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$PARAMETER',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$SPPARAMETER',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$STANDBY_LOG',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$VERSION',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_CONS_COLUMNS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_CONSTRAINTS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_OBJECTS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_TABLES',
p_grantee => 'cmid_user',
p_privilege => 'SELECT',
p_grant_option => false);
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_TAB_PARTITIONS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT',
p_grant_option => false);
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_USERS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rd 'ALL_TABLES',
p_grantee => 'sadmin_util.grant_sys_object(
p_obj_name => 'cmid_user',
p_privilege => 'SELECT',
p_grant_option => false);
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ALL_TAB_PARTITIONS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT',
p_grant_option => false);
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'ATTRCOL$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'CCOL$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'COLTYPE$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'INDPART$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'IDNSEQ$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'CDEF$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'RECYCLEBIN$',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/
/* Only required for RDS21 which supports PDB*/
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$PDBS',
p_grantee => 'cmid_user',
p_privilege => 'SELECT');
end;
/

CDCのOracleログアクセス方法

データベース取り込みとレプリケーションの増分ロードジョブ、および初期ロードと増分ロードの組み合わせジョブは、環境と要件に応じて、CDC処理のために別の方法でOracle REDOログにアクセスできます。

直接ログアクセス

データベース取り込みとレプリケーションジョブは、オンプレミスのソースシステム上の物理Oracle REDOログに直接アクセスして、変更データを読み取ることができます。
注: ログをソリッドステートディスク（SSD）に保存すると、この方法で最高のパフォーマンスを実現できます。
次の図は、データフローを示しています。
  1. 1Oracleデータベースが、変更レコードをディスク上のデータベースログファイルに書き込みます。
  2. 2データベース取り込みとレプリケーションのCDCリーダーが、物理ログファイルを読み取り、CDCの対象となるソーステーブルのログファイルから変更レコードを抽出します。
  3. 3データベース取り込みとレプリケーションのCDCライターが変更レコードを読み取ります。
  4. 4CDCライターが、変更レコードをターゲットに適用します。

NFSマウントされたログ

データベース取り込みとレプリケーションジョブは、ネットワークファイル共有（NFS）マウント、またはネットワーク接続ストレージ（NAS）やクラスタ化されたストレージなど別の方法を使用して、共有ディスクからOracleデータベースログにアクセスできます。
次の図は、データフローを示しています。
  1. 1Oracleデータベースが、変更レコードをデータベースログファイルに書き込みます。ログファイルが共有ディスクに書き込まれます。
    2. 共有ディスクは、ファイルをデータベースとSecure Agentホストの両方に対してローカルとして見える任意のシステムに配置できます。この共有は、上記のようにNFSを使用するか、ネットワーク接続ストレージ（NAS）またはクラスタ化されたストレージを使用して実現できます。
  2. 2データベース取り込みとレプリケーションのCDCリーダーが、ネットワークを介してNFSサーバーからログファイルを読み取り、CDCの対象となるソーステーブルの変更レコードを抽出します。
  3. 3データベース取り込みとレプリケーションのCDCライターが変更レコードを読み取ります。
  4. 4CDCライターが、変更レコードをターゲットに適用します。

ASM管理によるログ

データベース取り込みとレプリケーションジョブは、Oracle Automatic Storage Management（ASM）システムに格納されているOracle REDOログにアクセスできます。ASM管理によるREDOログから変更データを読み取るには、ASMユーザーが、ASMインスタンスに対するSYSASMまたはSYSDBA権限を持っている必要があります。
Oracle Database Ingestion接続を設定するときは、名前に「ASM」を含むプロパティを入力します。
また、Informaticaでは、Oracle ASMのREDOログファイルからデータを読み取る場合、ローカルのsqlnet.oraファイルのsqlnet.recv_timeoutパラメータを5分未満に設定することをお勧めします。このパラメータは、クエリがタイムアウトになるまでにOracleクライアントがASMからの応答を待機する時間を指定します。ネットワークの中断やその他の要因により、Oracle接続が応答しなくなることがあります。この値を設定すると、リーダーがそのような状況に適時応答してリカバリできるようになります。
次の図は、データフローを示しています。
  1. 1Oracleデータベースが、変更レコードをASM管理によるデータベースログファイルに書き込みます。
  2. 2データベース取り込みとレプリケーションのCDCリーダーが、ASM管理によるログファイルを読み取り、CDCの対象となるソーステーブルの変更レコードを抽出します。
  3. 3データベース取り込みとレプリケーションのCDCライターが変更レコードを読み取ります。
  4. 4CDCライターが、変更レコードをターゲットに適用します。

ステージングディレクトリを使用したASM管理によるログ

データベース取り込みジョブは、ASM環境のステージングディレクトリからASM管理によるREDOログにアクセスできます。ASMのみを使用する場合と比較して、この方法ではログファイルへのアクセスが高速になり、ASMシステムのI/Oが低減されます。ASM管理によるログから変更データを読み取るには、ASMユーザーが、ASMインスタンスに対するSYSASMまたはSYSDBA権限を持っている必要があります。
次の図は、データフローを示しています。
  1. 1Oracleデータベースが、変更レコードをASM管理によるログファイルに書き込みます。
  2. 2ASMが、ログをステージングディレクトリにコピーします。
    3. ステージングディレクトリは、NFSマウントなどの共有ディスク上にある必要があります。そうすることにより、ASMはそこにデータを書き込み、データベース取り込みとレプリケーションジョブはそこからデータを読み取ることができます。
  3. 3データベース取り込みとレプリケーションのCDCリーダーが、ステージングディレクトリにあるログファイルを読み取り、CDCの対象となるソーステーブルの変更レコードを抽出します。
  4. 4データベース取り込みとレプリケーションのCDCライターが変更レコードを読み取ります。
  5. 5CDCライターが、変更レコードをターゲットに適用します。

ディレクトリオブジェクトを使用したOracleサーバーファイルシステムのログへのBFILEアクセス

オンプレミスのOracleソースシステムでは、BFILEロケータを備えたOracleディレクトリオブジェクトを使用して、ローカルOracleサーバーファイルシステムからオンラインREDOログとアーカイブREDOログを読み取るように、データベース取り込みとレプリケーションを設定できます。Oracle REDOログファイルの場所を指すARCHIVELOG_DIRおよびONLINELOG_DIRという名前のOracleディレクトリオブジェクトを作成する必要があります。BFILEアクセスの設定については、OracleファイルシステムのOracle REDOログへのBFILEアクセスの設定を参照してください。
次の図は、データフローを示しています。
  1. 1Oracleデータベースが、ローカルOracleサーバーファイルシステムのREDOログファイルに変更レコードを書き込みます。データベース取り込みとレプリケーションタスクがログファイルを読み取る必要があるときに、Oracleに接続し、ARCHIVELOG_DIRまたはONLINELOG_DIRディレクトリオブジェクトを参照してログにアクセスするためのselect要求を発行します。
    2. 注: スタンバイデータベース、RDSデータベースインスタンス、または高速リカバリ領域がある環境など、複数のログの場所に格納されているOracleデータへのBFILEアクセスを使用した場合、データベース取り込みおよびレプリケーションは、ARCHIVELOG_DIRおよびONLINELOG_DIRで始まり、ARCHIVELOG_DIR_01、ARCHIVE_LOG_DIR_02などのサフィックスで終わるすべてのディレクトリオブジェクトを問い合せることで、ログを自動的に見つけることができます。データベース取り込みおよびレプリケーションジョブを実行するデータベースユーザーにCREATE ANY DIRECTORY特権とDROP ANY DIRECTORY特権が付与されている場合は、必要に応じてディレクトリオブジェクトを実行時に作成できます。
  2. 2データベース取り込みとレプリケーションのCDCリーダーが、Secure AgentボックスにインストールされているOCIクライアントを使用してログファイルを読み取り、CDC対象のソーステーブルの変更レコードを抽出します。
  3. 3CDCリーダーが、変更レコードをCDCライターに送信します。
  4. 4CDCライターが、変更レコードをターゲットに適用します。

OracleファイルシステムのOracle REDOログへのBFILEアクセスの設定

REDOログをローカルのOracleサーバーファイルシステムに保存し、BFILEでOracleディレクトリオブジェクトを使用してログにアクセスする場合は、次の設定タスクを実行します。
BFILEアクセスに固有ではない、次の通常のOracleソース前提条件タスクを完了します。
詳細については、「Oracleソース」を参照してください。
さらに、BFILEアクセスの場合は、次の手順を実行して、オンラインログの格納先とのアーカイブログの格納先を設定します。
  1. 1Oracleデータベースに、Oracleサーバーファイルシステム内のオンラインREDOログとアーカイブREDOログの場所をクエリします。次のサンプルクエリを使用できます。
    2. オンラインREDOログの場所を取得するには、次の手順を実行します。
    select * from v$logfile;
    ログのアーカイブ先を取得するには、次の手順を実行します。
    select dest_id, dest_name, destination, status from V$ARCHIVE_DEST;
  2. 2手順1で取得したログファイルの場所を指すONLINELOG_DIRおよびARCHIVELOG_DIRディレクトリオブジェクトを作成します。Oracleディレクトリオブジェクトは、アクセスするログファイルが配置されているOracleサーバーファイルシステム上の物理ディレクトリの論理エイリアス名を指定します。以下に例を示します。
    3. CREATE DIRECTORY ONLINELOG_DIR AS '/u01/oracle/data';
    CREATE DIRECTORY ARCHIVELOG_DIR AS '/u01/oracle/archivedata';
    Oracle Database Ingestion接続でリーダーモードを［ARCHIVEONLY］に設定して、アーカイブログからのみ変更を読み取る場合は、ONLINELOG_DIRディレクトリまたはディレクトリオブジェクトを作成する必要はありません。
    Oracleデータベースは、指定したディレクトリが存在することを確認しません。Oracleファイルシステムに存在する有効なディレクトリを指定していることを確認してください。
  3. 3ディレクトリオブジェクトがREDOログの正しいファイルシステムパスで作成されたことを確認するには、次のようなselect文を発行します。
    4. select * from all_directories;
    OWNER DIRECTORY_NAME DIRECTORY_PATH
    -------- ------------------- ----------------------------------
    SYS ARCHIVELOG_DIR /u01/oracle/data/JO112DTL
    SYS ONLINELOG_DIR /u01/oracle/data/JO112DTL
  4. 4Oracle Database Ingestion接続プロパティで指定されたデータベース取り込みとレプリケーションユーザーに、ONLINELOG_DIRおよびARCHIVELOG_DIRディレクトリオブジェクトへの読み取りアクセスを付与します。以下に例を示します。
    5. grant read on directory "ARCHIVELOG_DIR" to "cmid_user";
    grant read on directory "ONLINELOG_DIR" to "cmid_user";
    注: ONLINELOG_DIRパスが存在しないか、アクティブなREDOログのパスと一致する場合、データベース取り込みおよびレプリケーションはディレクトリの作成を試みます。ディレクトリオブジェクトを作成するための十分な権限がない場合は、エラーメッセージが発行されます。その場合は、DBAに、正しいパスでディレクトリオブジェクトを作成するよう依頼してください。
  5. 5Oracle Database Ingestion接続プロパティで、［BFILEアクセス］チェックボックスを選択します。
重要: 複数のログの場所に格納されているOracleデータへのBFILEアクセスを使用した場合、データベース取り込みおよびレプリケーションは、ARCHIVELOG_DIRおよびONLINELOG_DIRで始まり、ARCHIVELOG_DIR_01、ARCHIVE_LOG_DIR_02などのサフィックスで終わるすべてのディレクトリオブジェクトを問い合せることで、ログを自動的に見つけることができます。この機能により、データベース取り込みおよびレプリケーションは、プライマリデータベースとは異なるログの場所、Amazon RDSデータベースインスタンス上のレプリカログ、およびUSE_DB_RECOVERY_FILE_DESTパラメータが指す高速リカバリエリア内のアーカイブログを使用するOracleスタンバイデータベースをサポートします。
必要に応じて、カスタムプロパティpwx.cdcreader.oracle.database.additional BFILEARCHIVEDIR=<directory_object>およびpwx.cdcreader.oracle.database.additional BFILEONLINEDIR=<directory_object>を使用して、ARCHIVELOG_DIR名とONLINELOG_DIR名をオーバーライドすることができます。
データベース取り込みおよびレプリケーションジョブを実行するデータベースユーザーにCREATE ANY DIRECTORY特権とDROP ANY DIRECTORY特権を付与すると、必要に応じてディレクトリオブジェクトを実行時に作成できるようになります。例えば、データベースに複数のアーカイブログとオンラインログの格納先が存在する場合は、ディレクトリオブジェクトを次の命名規則で作成することができます。
データベース取り込みおよびレプリケーションは、これらの生成されたディレクトリオブジェクトに対してクリーンアップ処理を実行しません。
USE_DB_RECOVERY_FILE_DESTパラメータを使用しており、CREATE ANY DIRECTORY特権およびDROP ANY DIRECTORY特権が付与されていない場合、DBAは次のようなスクリプトを使用して、データベース取り込みおよびレプリケーションジョブを実行する前に、毎日または毎週ディレクトリオブジェクトを作成する必要があります。
create or replace directory ARCHIVELOG_DIR_2024_08_19 as '<DB_RECOVERY_FILE_DEST>/2024_08_19'
USE_DB_RECOVERY_FILE_DESTパラメータを使用しており、データベースユーザーにCREATE ANY DIRECTORY特権とDROP ANY DIRECTORY特権が付与されている場合、ディレクトリオブジェクトは実行時に必要に応じて作成され、14日後に削除されます。これらのディレクトリオブジェクトには、<ARCHIVEDIRNAME>_YYYY_MM_DDという命名規則があります。

ソースとしてのOracle Data GuardデータベースまたはFar Syncインスタンス

データベース取り込みとレプリケーションは、Oracle Data Guardプライマリデータベース、論理および物理スタンバイデータベース、およびFar Syncインスタンスから変更データをキャプチャできます。
Far Syncインスタンスは、プライマリデータベースからREDOを受け入れ、そのREDOをOracle Data Guard構成の他のメンバーに送信する、リモートOracle Data Guardの宛先です。
Oracle Data Guardプライマリデータベースまたは読み取りモードで開いているスタンバイデータベースからデータをターゲットに初期ロードできます。
設定
Oracle変更キャプチャの設定は、Oracle Data Guardデータベースタイプによって異なります。
スタンバイからプライマリロールへの遷移
Oracle Data Guard環境では、物理スタンバイデータベースがプライマリロールに遷移する可能性があります。通常、ロールの遷移はフェイルオーバーまたはスイッチオーバーが原因で発生します。遷移中は、物理スタンバイデータベースへのすべてのアクティブな接続が終了します。
物理スタンバイデータベースがプライマリロールに遷移した後にCDC処理を再開できるようにするには、データベース取り込みとレプリケーションが遷移ポイントを過ぎて処理できるように、元のスタンバイシステムでいくつかの接続設定プロパティを調整することが必要になる場合があります。遷移が完了したら、新しいプライマリデータベース環境でパフォーマンスを最適化するようプロパティを再度調整できます。
次の表で、この接続プロパティについて遷移段階別に説明します。
接続プロパティ
遷移前
遷移中
遷移後
RACメンバ
プライマリデータベース上のアクティブなスレッドの数を指定します。
スタンバイデータベースとプライマリデータベースの両方のデータベース上で一意のスレッドIDを持つアクティブなスレッドの総数を指定します。
例えば、プライマリデータベースがスレッドID 1と2を使用する2ノードのRACデータベースであり、スタンバイデータベースがスレッドID 2、3、4を使用する3ノードのRACデータベースの場合、プロパティ値を4に指定します。
再開ポイントが遷移ポイントを超えるまで進行したら、必要に応じてこのプロパティ値を編集し、新しいプライマリデータベースからの変更データキャプチャのパフォーマンスを最適化します。
CDCのスレッド追跡によるオーバーヘッドを最小限に抑えるため、環境に適した最小値を使用することをお勧めします。
リーダースタンバイログマスク
スタンバイ接続文字列
スタンバイユーザー名
スタンバイパスワード
すべてのスタンバイプロパティを削除します。読み取り専用アクセス用に開いている物理スタンバイデータベースには適用されません。
プロパティは削除されたままです。
これらのプロパティは指定しないでください。これらはプライマリデータベースでは使用されません。
データベース接続文字列
スタンバイデータベースが開かれていない場合、プライマリデータベース用の接続文字列を定義します。
スタンバイデータベースが開かれている場合、スタンバイデータベース用の接続文字列を定義します。
ロールの遷移後にプライマリロールになるデータベース用の接続文字列を指定します。
この接続プロパティが、新しいプライマリデータベースの接続文字列を定義していることを確認してください。

Oracleアーカイブログの保持に関する考慮事項

データベース取り込みとレプリケーションの増分ロードジョブ、および初期ロードと増分ロードの組み合わせジョブは、OracleオンラインREDOログおよびアーカイブREDOログのトランザクションデータにアクセスできる必要があります。ログを利用できない場合、データベース取り込みとレプリケーションジョブはエラーで終了します。
通常、Oracle DBAは、組織の特定のビジネスニーズとOracle環境に基づいて、アーカイブログの保持期間を設定します。ログを再起動処理に使用できるように、変更キャプチャが停止または潜在的な状態になると予想される最長期間プラス約1時間にわたって、ソースアーカイブログが保持されていることを確認してください。
環境内の現在のログ保持ポリシーが、データベース取り込みとレプリケーションの変更キャプチャ処理に対応するのに十分かどうかを判断するには、次の要素を考慮してください。
ログのキャプチャ処理を再開する必要があるときにアーカイブログを使用できない場合は、DBAに、アーカイブログを復元して必要に応じて保存期間を変更するよう依頼してください。それ以外の場合は、別の初期ロードを実行してターゲットを再マテリアライズしてから、増分変更データ処理を再度開始してください。ただし、この場合、一部の変更が失われる可能性があります。

PostgreSQLソース

データベース取り込みとレプリケーションタスクでPostgreSQLソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

データベース取り込みとレプリケーションタスクでPostgreSQLソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。
Secure Agent システム上で、オペレーティングシステムに適したODBCドライバをインストールします。
PostgreSQLデータベースシステムで、次の設定手順を実行します。
  1. 1増分ロードジョブ、初期および増分ロードジョブの場合、PostgreSQL postgresql.conf構成ファイルでwal_level=logicalパラメータが指定されていることを確認します。
    2. このパラメータは、PostgreSQLがログ先行書き込み（WAL）に書き込む情報の量を決定します。論理の設定によって、論理デコードのサポートに必要な情報が追加されます。
    Amazon Aurora PostgreSQLまたはAmazon RDS for PostgreSQLソースでwal_levelをlogicalに設定するには、クラスタパラメータグループでrds.logical_replicationパラメータを1に設定します。Azure Database for PostgreSQL - フレキシブル サーバ-の場合、Azureポータルの［サーバーパラメータ］ページでwal_levelパラメータをlogicalに設定します。
    Cloud SQL for PostgreSQLソースの場合は、次のアクションを実行します。
    1. aパブリックIPを使用してデータベースに接続します。
      2. 注: Google Cloudコンソールの［承認済みネットワーク］に必要なIPを必ず追加してください。
    2. bCloud SQL for PostgreSQLデータベースインスタンスレプリカを作成します。
    3. cCloud Shellで、ローカル管理者ユーザーとして次のコマンドを実行します。
      4. alter database postgres set default_transaction_read_only = off;
      gcloud sql connect database_replica --user=postgres --quiet;
      ALTER USER postgres WITH REPLICATION;
      CREATE USER replication_user WITH REPLICATION IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'password';
      ALTER USER postgres WITH REPLICATION;
    4. dGoogle Cloudコンソールで、次のデータベースフラグを追加します:
    5. eデータベースインスタンスを再起動します。
  2. 2PostgreSQL用DataDirect ODBCドライバを使用する場合は、データベースでSCRAM-SHA-256認証方法を使用していないことを確認してください。MD5などの別の認証方法を使用します。
    3. 注: PostgreSQL ODBCドライバは、SCRAM-SHA-256認証方法をサポートしています。PostgreSQL 13では、この認証方法がデフォルトの方法になりました。
  3. 3PostgreSQLソースを含むデータベース取り込みとレプリケーションタスクをデプロイして実行するには、ソース接続で、必要な特権を持つデータベースユーザーを指定する必要があります。次の方法でユーザーを作成し、そのユーザーに特権を付与します。
  4. 4増分ロードジョブ、または初期および増分ロードジョブの論理デコード出力にwal2jsonプラグインを使用する場合は、プラグインをインストールします。
  5. 5増分ロードジョブ、または初期および増分ロードジョブにpgoutputプラグインを使用する場合は、次のSQL文を使用して、データベース取り込みジョブのパブリケーションを作成します。
    6. CREATE PUBLICATION publication_name [FOR TABLE [ONLY] table_name [*] [,...] | FOR ALL TABLES ];
    ターゲットにレプリケートするすべてのテーブルがパブリケーションに含まれていることを確認してください。
  6. 6増分ロードジョブ、および初期ロードと増分ロードの組み合わせジョブの場合は、次の関数を使用してPostgreSQL論理レプリケーションスロットを作成します。
    7. SELECT pg_create_logical_replication_slot('slot_name', 'plugin_type');
    ここで、plugin_typeはpgoutputプラグインまたはwal2jsonプラグインのどちらかです。
  7. 7PostgreSQL 9.6ソースを使用する増分ロードジョブ、初期および増分ロードジョブの場合、postgresql.conf構成ファイルのmax_replication_slotsパラメータの値が、使用する予定の同時データベース取り込みジョブの数以上であることを確認します。
    8. 重要: すべてのレプリケーションスロットは、すべての同時ジョブで一意である必要があります。
  8. 8増分ロードジョブ、初期および増分ロードジョブの場合、PostgreSQLソースがUTF-8エンコードを使用していることを確認します。
  9. 9PostgreSQLソースがUTF-8エンコーディングを使用していることを確認します。ソースデータベースに別のエンコードを使用すると、初期ロードジョブ、増分ロードジョブ、および初期ロードと増分ロードの組み合わせジョブが失敗する可能性があります。

使用に関する考慮事項:

SAP HANAおよびSAP HANA Cloudソース

データベース取り込みとレプリケーションタスクでSAP HANAおよびSAP HANA Cloudソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項:

Teradataソース

データベース取り込みとレプリケーションタスクでTeradataソースを使用するには、最初にソースデータベースを準備し、使用に関する考慮事項を確認してください。

ソースの準備:

使用に関する考慮事項: