データ レプリケーションの設定

レプリケーション データ タスクの設定を構成できます。

• レプリケーション タスクを開き、ツール バーの [設定] をクリックします。

「設定: <タスク名>」ダイアログが開きます。使用可能な設定については以下で説明します。

タスク モード

このタブでは、レプリケーション モードを設定し、変更をターゲットに適用する方法を決定できます。

レプリケーション モード

次のレプリケーション モードを使用できます。

• フル ロード: 選択したソース テーブルからターゲット プラットフォームにデータをロードし、必要に応じてターゲット テーブルを作成します。フル ロードはタスクの開始時に自動的に実行されますが、必要に応じて手動で実行することもできます。
• 変更を適用: ソース テーブルに加えられた変更を反映して、ターゲット テーブルを常に最新の状態に保ちます。

• 保存先の変更: ソース テーブルへの変更を変更テーブル (ソース テーブルごとに 1 つ) に保存します。

  詳細については、「変更の保存」を参照してください。

[変更の保存] または [変更の適用] を選択し、ソース データに CDC またはビューをサポートしていないテーブルが含まれている場合、2 つのデータ パイプラインが作成されます。1 つは CDC をサポートするテーブル用のパイプラインで、もう 1 つは [フル ロード] のみをサポートする他のすべてのテーブルおよびビュー用の別のパイプラインです。

変更適用モード

変更は、次のいずれかの方法でターゲット テーブルに適用されます。

• バッチ最適化: これが既定です。このオプションを選択すると、変更はバッチで適用されます。トランザクションをもっとも効率的な方法でバッチにグループ化するための前処理アクションが発生します。
• トランザクション: このオプションを選択すると、各トランザクションをコミットされた順序で個別に適用します。この場合、すべてのテーブルで厳密な参照整合性が確保されます。

メタデータ

基本

• ターゲット テーブル スキーマ: ソース テーブル スキーマを使用しない場合 (またはソース データベースにスキーマがない場合)、ソース テーブルをレプリケートするターゲットのスキーマ。

  情報メモOracle ターゲットにレプリケートする場合、既定のターゲット テーブル スキーマは「system」です。この項目を空のままにする場合 (この場合、ソース スキーマが使用される)、ソース スキーマがターゲット上にすでに存在することを確認する必要があります。存在しない場合、タスクは失敗します。
  情報メモスキーマ名に許可される最大文字数は 128 文字です。

• LOB 列を含めない: ソース LOB 列をレプリケートしない場合は、これを選択します。

• LOB 列サイズを (KB) に制限: これが既定です。小さい LOB のみをレプリケートする必要がある場合や、ターゲット プラットフォームが無制限の LOB サイズをサポートしていない場合は、このオプションを選択します。この項目に許可される最大値は 102400 KB (100 MB) です。

  小さい LOB をレプリケートする場合、ソースからの「ルックアップ」経由ではなく「インライン」でレプリケートされるため、このオプションは [LOB 列サイズを制限しない] オプションよりも効率的です。変更処理中、小さい LOB は通常ソースからの「ルックアップ」を介してレプリケートされます。

  [LOB サイズを制限] の値はバイト単位であるため、サイズは次の式に従って計算する必要があります。

  • BLOB: 最大の LOB の長さ。
  • NCLOB: 最長の TEXT の文字数を 2 倍した長さ (各文字は 2 バイトとして扱われるため)。データに 4 バイト文字が含まれる場合は 4 倍してください。
  • CLOB: 最長の TEXT の文字数 (各文字は UTF8 文字として処理されるため)。データに 4 バイト文字が含まれる場合は 2 倍してください。
  情報メモ

  • 指定したサイズより大きい LOB は切り捨てられます。
  • Oracle ソースからの変更処理中、インライン BLOB はインラインでレプリケートされます。
  • この設定への変更は、既存のテーブルがリロードされた後にのみ影響します。

• LOB 列サイズを制限しない: このオプションを選択すると、サイズに関係なく LOB 列がレプリケートされます。

  情報メモLOB 列のレプリケートは、パフォーマンスに影響を与える可能性があります。これは、ソース LOB 値を取得するために Data Movement gateway がソース テーブルからルックアップを実行する必要がある大きな LOB 列の場合に特にあてはまります。

  • LOB サイズが次以下の場合に最適化: 小さい LOB と大きい LOB の両方をレプリケートする必要があり、ほとんどの LOB が小さい場合は、このオプションを選択します。

    情報メモ

    このオプションは、次のソースとターゲットでのみサポートされます。

    • ソース: Oracle、Microsoft SQL server、MySQL、PostgreSQL、IBM DB2 for LUW

    • ターゲット: Oracle、Microsoft SQL Server、MySQL, PostgreSQL。

    このオプションを選択すると、フル ロード中に小さい LOB が「インライン」でレプリケートされ (より効率的)、大きい LOB はソース テーブルからのルックアップを実行することによってレプリケートされます。ただし、変更処理中は、ソース テーブルからのルックアップを実行することにより、小さい LOB と大きい LOB の両方がレプリケートされます。

    情報メモ

    このオプションを選択すると、Data Movement gateway はすべての LOB サイズをチェックして、どの LOB サイズを「インライン」で転送するかを決定します。指定されたサイズより大きい LOB は、フル LOB モードを使用してレプリケートされます。

    したがって、ほとんどの LOB が指定された設定よりも大きいことがわかっている場合は、代わりに LOB 列を無制限にレプリケート のオプションを使用します。

  • チャンク サイズ (KB): 必要に応じて、データをターゲットにレプリケートするときに使用する LOB チャンクのサイズを変更します。ほとんどの場合は既定のチャンク サイズで十分ですが、パフォーマンスの問題が発生した場合は、サイズを調整することでパフォーマンスが向上する可能性があります。

    情報メモ

    一部のデータベースでは、データの挿入または更新時にデータ型の検証が行われます。このような場合、データが指定されたチャンク サイズより大きいと、構造化データ型 (XML、JSON、GEOGRAPHY など) のレプリケーションは失敗する可能性があります。

拡張

コントロール テーブル設定

• コントロール テーブル スキーマ: コントロール テーブルをソース スキーマ (既定) またはターゲット スキーマに作成しない場合は、コントロール テーブルのターゲット スキーマを指定します。

  情報メモスキーマ名に許可される最大文字数は 128 文字です。
• テーブルスペースにターゲット コントロール テーブルを作成します: ​ ターゲット connector が Oracle の場合、ターゲット コントロール テーブルを作成するテーブルスペースを指定します。この項目に情報を入力しない場合、テーブルはターゲット データベースの既定のテーブルスペースに作成されます。
• テーブルスペースにターゲット コントロール テーブルの索引を作成します:ターゲット connector が Oracle の場合、コントロールテーブルのインデックスを作成するテーブルスペースを指定します。この項目に情報を入力しない場合、インデックスはコントロール テーブルと同じテーブルスペースに作成されます。
• レプリケーション履歴タイムスロット (分): Replication 履歴コントロール テーブルの各タイムスロットの長さ。既定は 5 分です。

コントロール テーブルの選択

変更の適用

これらの設定は、 [変更の適用] レプリケーション モードが有効になっている場合にのみ使用できます。

基本

DDL 変更をターゲット テーブルに適用

次のオプションは、対応するソース テーブルで実行される DDL 操作をターゲット テーブルでも実行するかどうかを決定します。

拡張

「変更処理のチューニング」を参照してください。

変更の保存

これらの設定は、 [変更の保存] レプリケーション モードが有効になっている場合にのみ使用できます。

基本

DDL オプション

次のオプションのいずれかを選択して、ソース テーブルに対する DDL 操作を処理する方法を決定します。

• 変更テーブルに適用: ソース テーブルに対する DDL 操作 (追加される列など) は、対応する変更テーブルにのみ適用されます。
• 無視: ソーステーブルに対するすべての DDL 操作は無視されます。

詳細設定

更新時

更新前のデータと更新後のデータの両方を保存するには、 [変更前イメージと変更後イメージを保存する] を選択します。選択しない場合は、更新後のデータのみが保存されます。

変更テーブルの作成

次のセクションでは、変更テーブルに変更を保存するときに使用できるオプションについて説明します。

• サフィックス: すべての変更テーブルのサフィックスとして使用する文字列を指定します。規定値は __ct です。変更テーブル名は、ターゲット テーブルの名前にサフィックスが追加されたものです。たとえば、既定値を使用すると、変更テーブルの名前は HR__ct になります。
• ヘッダー列のプレフィックス: すべての変更テーブルのヘッダー列のプレフィックスとして使用する文字列を指定します。規定値は header__ です。たとえば、既定値を使用すると、ヘッダー列 stream_position は header__stream_position になります。

変更テーブルの詳細については、「変更テーブルの使用」を参照してください。

フル ロード開始時に変更テーブルが存在する場合: 次のいずれかを選択して、フル ロード レプリケーションの開始時に変更テーブルをロードする方法を決定します。

• ドロップして変更テーブルを作成: テーブルがドロップされ、その場所に新しいテーブルが作成されます。
• 古い変更を削除し、変更を既存の変更テーブルに保存: テーブルのメタデータに影響を与えることなく、データは切り捨てられて追加されます。
• 古い変更を保持し、新しい変更を既存の変更テーブルに保存: 既存の変更テーブルのデータとメタデータは影響を受けません。

テーブルのヘッダー列

変更テーブルのヘッダー列には、操作のタイプ (INSERT など) やコミット時間など、変更処理操作に関する情報が表示されます。このすべての情報が必要ない場合は、ヘッダー列を選択して (または 1 つも選択せずに) 変更テーブルを作成するように ランディング タスクを構成することで、ターゲット データベースのフットプリントを削減できます。

ヘッダー列の説明については、「 変更テーブル」を参照してください。

エラー処理

基本

適用の競合

挿入適用時にキーを複製する: INSERT 操作で競合が発生した場合に実行するアクションを選択します。

• 無視: タスクは続行され、エラーは無視されます。

   

• 既存のターゲット レコードを更新: INSERTED ソース レコードと同じ主キーを持つターゲット レコードが更新されます。

• 例外テーブルにレコードを記録 (既定): タスクは続行され、エラーは例外テーブルに書き込まれます。

• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません。

• タスクを停止: タスクは停止され、手動による操作が必要となります。

更新を適用するためのレコードが見つかりません: UPDATE 操作で競合が発生した場合に実行するアクションを選択します。

• 無視: タスクは続行され、エラーは無視されます。

• 不足しているターゲット レコードを挿入: 不足しているターゲット レコードがターゲット テーブルに挿入されます。ソース エンドポイントが Oracle の場合、このオプションを選択するには、すべてのソース テーブル列に対してサプリメンタル ロギングを有効にする必要があります。

• 例外テーブルにレコードを記録 (既定): タスクは続行され、エラーは例外テーブルに書き込まれます。

• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません。

• タスクを停止: タスクは停止され、手動による操作が必要となります。

詳細設定

データ エラー

データ切り捨てエラーの場合: 1 つ以上の特定のレコードで切り捨てが発生した場合に実行する処理を選択します。リストから次のいずれかを選択できます。

• 無視: タスクは続行され、エラーは無視されます。
• 例外テーブルへのログ レコード (既定): タスクは続行され、エラーは例外テーブルに書き込まれます。
• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません
• タスクを停止: タスクは停止され、手動による操作が必要となります。

その他のデータ エラーの場合: 1 つ以上の特定のレコードでエラーが発生した場合に実行する処理を選択します。リストから次のいずれかを選択できます。

• 無視: タスクは続行され、エラーは無視されます。
• 例外テーブルへのログ レコード (既定): タスクは続行され、エラーは例外テーブルに書き込まれます。
• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません
• タスクを停止: タスクは停止され、手動による操作が必要となります。

その他のデータ エラーが発生した場合にエラー処理をエスカレートします (テーブルごと): このチェック ボックスをオンにすると、非切り捨てデータ エラーの数 (テーブルごと) が指定された量に達したときにエラー処理がエスカレートされます。有効な値は 1 ～ 10,000 です。

エスカレーション アクション: エラー処理がエスカレートされたときに実行される処理を選択します。使用できるアクションは、上記の [その他のデータ エラーの場合] ドロップダウン リストから選択したアクションに応じて異なります。

• テーブルを一時停止 (既定): タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータは ランディング済み されません。

  情報メモ

  動作は変更処理モードに応じて異なります。

  • トランザクションの適用モードでは、最後の変更は ランディング済み されません。

  • バッチ最適化の適用モードでは、データがまったく ランディング済み されない、または部分的にのみ ランディング済み される状況が発生する可能性があります。

• タスクを停止: タスクは停止され、手動による操作が必要となります。
• 例外テーブルにレコードを記録: タスクは続行され、レコードは例外テーブルに書き込まれます。

テーブル エラー

テーブル エラーが発生した場合: ドロップダウン リストから次のいずれかを選択できます。

• テーブルを一時停止 (既定): タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません
• タスクを停止: タスクは停止され、手動による操作が必要となります。

テーブル エラーが発生した場合にエラー処理をエスカレートします (テーブルごと): このチェック ボックスをオンにすると、テーブル エラーの数 (テーブルごと) が指定された量に達したときにエラー処理がエスカレートされます。有効な値は 1 ～ 10,000 です。

エスカレーション アクション: テーブル エラーのエスカレーション ポリシーは [タスクを停止] に設定されており、変更できません。

競合を適用

DELETE を適用するためのレコードが見つかりません: DELETE 操作で競合が発生した場合に実行するアクションを選択します。

• 無視: タスクは続行され、エラーは無視されます。
• 例外テーブルにレコードを記録: タスクは続行され、レコードは例外テーブルに書き込まれます。
• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません。
• タスクを停止: タスクは停止され、手動による操作が必要となります。

適用の競合が発生した場合、エラー処理をエスカレートします (テーブルごと): このチェック ボックスをオンにすると、適用の競合の数 (テーブルごと) が指定された量に達した場合にエラー処理をエスカレートします。有効な値は 1 ～ 10,000 です。

エスカレーション アクション: エラー処理がエスカレートされたときに実行される処理を選択します。

• 例外テーブルにレコードを記録 (既定): タスクは続行され、エラーは例外テーブルに書き込まれます。

• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません。

  情報メモ

  動作は変更処理モードに応じて異なります。

  • トランザクションの適用モードでは、最後の変更はレプリケートされません

  • バッチ最適化の適用モードでは、データのレプリケーションが行われないか、データのレプリケーションが部分的に行われる可能性があります。。

• タスクを停止: タスクは停止され、手動による操作が必要となります。

環境エラー

• 最大再試行数: このオプションを選択すると、復元可能な環境エラーが発生した場合にタスクを再試行する最大回数を指定できます。タスクが指定された回数再試行されると、タスクは停止され、手動による操作が必要となります。

  タスクを再試行しない場合は、チェック ボックスをオフにするか、「0」を指定します。

  タスクを無限に再試行するには、「-1」を指定します。

  • 再試行の間隔 (秒): カウンターを使用して、システムがタスクを再試行するまでに待機する秒数を選択または入力します。

    有効な値は 0 ～ 2,000 です。

• 長時間の停止の場合は再試行間隔を長くする: 長時間停止した場合の再試行間隔を長くするには、このチェック ボックスをオンにします。このオプションを有効にすると、最大再試行間隔に達するまで、各再試行と次の再試行の間隔が 2 倍になります (指定された最大間隔に従って再試行を継続します)。
  • 最大再試行間隔 (秒): [長時間の停止の場合は再試行間隔を長くする] オプションが有効になっている場合、カウンターを使用して、タスクの再試行間隔を待機する秒数を選択または入力します。有効な値は 0 ～ 2,000 です。

変更処理のチューニング

トランザクション オフロードのチューニング

どの [変更処理モード] が選択されているかに関係なく、次のチューニング オプションを使用できます。

• 次の場合に、進行中のトランザクションをディスクにオフロードします

  Qlik Cloud Data Integration では通常、ソースやターゲットに完全にコミットされるまで、トランザクション データがメモリ内に保持されます。ただし、割り当てられたメモリより大きいトランザクション、または指定された制限時間内にコミットされないトランザクションは、ディスクにオフロードされます。

  • トランザクション メモリ サイズが超過 (MB): すべてのトランザクションがディスクにオフロードされる前に、メモリで占有できる最大サイズ。規定値は 1024 です。
  • トランザクション期間が次を超えています (秒): 各トランザクションがディスクにオフロードされるまでに、メモリに留まることができる最大時間。期間は、Qlik Cloud Data Integration がトランザクションのキャプチャを開始した時間から計算されます。規定値は 60 です。

その他のチューニング

• ステートメントのキャッシュ サイズ (ステートメントの数): 後で実行するためにサーバーに保存する準備済みステートメントの最大数 (ターゲットに変更を適用する場合)。既定値は 50 です。最大値は 200 です。

• タスク リカバリ データをターゲット データベースに保存する: タスク固有のリカバリ情報をターゲット データベースに保存するには、このオプションを選択します。このオプションを選択すると、Data Movement gateway はターゲット データベースに attrep_txn_state という名前のテーブルを作成します。このテーブルには、データ移動ゲートウェイデータ フォルダー内のファイルが破損した場合、またはデータ フォルダーを含むストレージ デバイスに障害が発生した場合にタスクを復元するために使用できるトランザクション データが含まれています。

バッチ最適化の適用

次の設定は、適用モードがバッチ最適化のみに設定されている場合にのみ使用できます。

• バッチ変更を一定間隔で適用する:

• Larger than (最小時間): バッチ変更を適用する際の、各適用間の最小待機時間。既定値は 1 です。

  Longer than (最小時間) の値を増やすと、変更がターゲットに適用される頻度が減少し、一方でバッチのサイズが増加します。これにより、大規模なバッチの処理用に最適化されたターゲット データベースに変更を適用するときのパフォーマンスが向上します。

• Less than (最大時間): バッチ変更を適用する際の、各適用間の最大待機時間 (タイムアウトを宣言するまで)。つまり、許容できる最大の待機時間のことです。既定値は 30 です。この値により、Longer than (最小時間) の値に達した後、変更を適用するまでの最大待機時間が決定されます。

• 処理メモリ (MB) が次を超えた場合にバッチを強制適用: バッチ最適化の適用モードで前処理に使用するメモリの最大量。既定値は 500 です。

  最大バッチ サイズについては、この値を Data Movement gateway に割り当て可能な最大のメモリ量に設定します。これにより、大規模なバッチの処理用に最適化されたターゲット データベースに変更を適用するときのパフォーマンスが向上します。

トランザクションの適用

次の設定は、 [適用モード] が [トランザクション] に設定されている場合にのみ使用できます。

• トランザクションごとの最小変更数: 各トランザクションに含める変更の最小数。既定値は 1000 です。

  情報メモData Movement gateway は、変更の数がトランザクションごとの最小変更数以上の場合、またはバッチ タイムアウト値 (下記を参照) に達した場合の、いずれかの先に発生したほうのタイミングでターゲットに変更を適用します。ターゲットに適用される変更の頻度はこれら 2 つのパラメーターによって制御されるため、ソース レコードへの変更がターゲット レコードにすぐに反映されない場合があります。
• 適用前にトランザクションをバッチ処理する最大時間 (秒): タイムアウトを宣言するまでにトランザクションをバッチで収集する最大時間。既定値は 1 です。

文字置換

ターゲット データベース内のソース文字の置換または削除、および/または選択した文字セットでサポートされていないソース文字の置換または削除ができます。

ソース文字の置換または削除

[ソース文字の置換または削除] テーブルを使用して、特定のソース文字の置換を定義します。これは、文字の Unicode 表現がソース プラットフォームとターゲット プラットフォームで異なる場合などに便利です。たとえば、Linux では、Shift_JIS 文字セットのマイナス文字は U+2212 と表されますが、Windows では U+FF0D と表されます。

選択した文字セットでサポートされていないソース文字の置換または削除

[文字セットでサポートされていないソース文字] テーブルを使用して、選択した文字セットでサポートされていないすべての文字に対して 1 つの置換文字を定義します。

SaaS アプリケーション

初期ロード用

SaaS アプリケーション ソースからデータを移動する場合、初期フル ロードを実行する方法を設定できます。

次の頻度で変更を読み込む (分)

ソースから変更を読み取る間隔を分単位で設定します。有効な範囲は 1 ～ 1440 です。