すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:Db2 for LUWデータベースからのデータの同期に関する注意事項と制限事項

最終更新日:Nov 04, 2024

このトピックでは、Db2 for LUWデータベースからのデータの同期に関する注意事項と制限事項について説明します。 データ同期タスクが期待どおりに実行されるようにするには、タスクを設定する前に注意事項と制限事項をお読みください。

Db2 for LUWデータベースのデータをPolarDB-X V2.0インスタンスに同期する

説明

既定では、Data Transmission Service (DTS) は、データ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースに対するカスケード操作や削除操作などの特定の操作は、ターゲットデータベースと同期されません。

制限タイプ

説明

ソースデータベースの制限

  • 帯域幅の要件: ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうでなければ、データ同期速度は低下する。

  • 同期するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 同期するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、ターゲットデータベース内のテーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルをバッチで同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

  • データログ機能を有効にする必要があります。 それ以外の場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

    説明

    増分データ同期のみを実行する場合、ソースデータベースのデータログを24時間以上保存する必要があります。 完全データ同期と増分データ同期の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保存する必要があります。 そうしないと、DTSはデータログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 そうしないと、DTSのサービスレベル契約 (SLA) に記載されているサービスの信頼性またはパフォーマンスが保証されません。

  • テーブルを同期するには、変更データキャプチャ (CDC) 機能を有効にする必要があります。

その他の制限

  • DTSは、Db2 for LUWのCDCレプリケーション技術に基づいて、Db2 for LUWデータベースの増分データをターゲットデータベースに同期します。 しかし、CDC複製技術には独自の限界がある。 詳細については、「SQLレプリケーションの一般的なデータ制限」をご参照ください。

  • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 初期の完全データ同期中に、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 したがって、最初の完全データ同期が完了した後、ターゲットデータベースの使用されるテーブルスペースのサイズは、ソースデータベースのサイズよりも大きくなります。

  • データ同期中は、DTSのみを使用してデータをターゲットデータベースに書き込むことをお勧めします。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 データ同期が完了したら、data Management (DMS) を使用してDDLステートメントをオンラインで実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

特別なケース

ソースDb2 for LUWデータベースは自己管理データベースです。 Db2 for LUWデータベースのデータを同期する場合は、次の項目に注意してください。

  • データ同期タスクの実行中にソースデータベースでプライマリ /セカンダリの切り替えを実行すると、タスクは失敗します。

  • DTSは、同期先データベースの最新の同期データレコードのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて同期レイテンシを計算します。 データ操作言語 (DML) 操作がソースデータベースで長時間実行されない場合、同期レイテンシが不正確になる可能性があります。 同期レイテンシが高すぎる場合は、ソースデータベースでDML操作を実行してレイテンシを更新できます。

    説明

    同期するオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。 ハートビートテーブルは1秒ごとに更新されるか、データを受信します。

Db2 for LUWデータベースのデータをPolarDB for MySQLクラスターに同期する

説明

デフォルトでは、DTSはデータ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースのカスケード操作や削除操作などの特定の操作は、ターゲットデータベースと同期されません。

制限タイプ

説明

ソースデータベースの制限

  • 帯域幅の要件: ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうでなければ、データ同期速度は低下する。

  • 同期するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 同期するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、ターゲットデータベース内のテーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルをバッチで同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

  • データログ機能を有効にする必要があります。 それ以外の場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

    説明

    増分データ同期のみを実行する場合、ソースデータベースのデータログを24時間以上保存する必要があります。 完全データ同期と増分データ同期の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保存する必要があります。 そうしないと、DTSはデータログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 そうしないと、DTSのSLAに記載されているサービスの信頼性またはパフォーマンスを保証できません。

その他の制限

  • DTSは、Db2 for LUWのCDCレプリケーション技術に基づいて、Db2 for LUWデータベースの増分データをターゲットデータベースに同期します。 しかし、CDC複製技術には独自の限界がある。 詳細については、「SQLレプリケーションの一般的なデータ制限」をご参照ください。

  • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 初期の完全データ同期中に、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 したがって、最初の完全データ同期が完了した後、ターゲットデータベースの使用されるテーブルスペースのサイズは、ソースデータベースのサイズよりも大きくなります。

  • データ同期中は、DTSのみを使用してデータをターゲットデータベースに書き込むことをお勧めします。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 データ同期が完了したら、DMSを使用してDDLステートメントをオンラインで実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

  • ターゲットデータベースでDDL文の実行に失敗した場合、データ同期タスクは引き続き実行されます。 タスクログで実行に失敗したDDLステートメントを表示できます。 タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。

  • MySQLデータベースの列名は大文字と小文字を区別しません。 したがって、ソースデータベースの複数の列の名前が大文字と小文字のみが異なる場合、同期中に列のデータはターゲットMySQLデータベースの同じ列に書き込まれます。 これにより、予期しない同期結果が生じる可能性があります。

  • データ同期が完了したら、analyze table <Table name> コマンドを実行して、データが宛先テーブルに書き込まれているかどうかを確認することを推奨します。 たとえば、ソースMySQLデータベースで高可用性 (HA) 切り替えがトリガーされた場合、データはメモリにのみ書き込まれます。 その結果、データ損失が発生する。

特別なケース

ソースDb2 for LUWデータベースは自己管理データベースです。 Db2 for LUWデータベースのデータを同期する場合は、次の項目に注意してください。

  • データ同期タスクの実行中にソースデータベースでプライマリ /セカンダリの切り替えを実行すると、タスクは失敗します。

  • DTSは、同期先データベースの最新の同期データレコードのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて同期レイテンシを計算します。 ソースデータベースでDML操作が長時間実行されない場合、同期レイテンシが不正確になる可能性があります。 同期レイテンシが高すぎる場合は、ソースデータベースでDML操作を実行してレイテンシを更新できます。

    説明

    同期するオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。 ハートビートテーブルは1秒ごとに更新されるか、データを受信します。

Db2 for LUWデータベースのデータをApsaraDB RDS for MySQLインスタンスに同期する

説明

デフォルトでは、DTSはデータ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースのカスケード操作は、ターゲットデータベースと同期されません。

制限タイプ

説明

ソースデータベースの制限

  • 帯域幅の要件: ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうでなければ、データ同期速度は低下する。

  • 同期するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 同期するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、ターゲットデータベース内のテーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルをバッチで同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

  • データログ機能を有効にする必要があります。 それ以外の場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

    説明

    増分データ同期のみを実行する場合、ソースデータベースのデータログを24時間以上保存する必要があります。 完全データ同期と増分データ同期の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保存する必要があります。 そうしないと、DTSはデータログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 そうしないと、DTSのSLAに記載されているサービスの信頼性またはパフォーマンスを保証できません。

その他の制限

  • DTSは、Db2 for LUWのCDCレプリケーション技術に基づいて、Db2 for LUWデータベースの増分データをターゲットデータベースに同期します。 しかし、CDC複製技術には独自の限界がある。 詳細については、「SQLレプリケーションの一般的なデータ制限」をご参照ください。

  • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 初期の完全データ同期中に、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 したがって、最初の完全データ同期が完了した後、ターゲットデータベースの使用されるテーブルスペースのサイズは、ソースデータベースのサイズよりも大きくなります。

  • データ同期中は、DTSのみを使用してデータをターゲットデータベースに書き込むことをお勧めします。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 データ同期が完了したら、DMSを使用してDDLステートメントをオンラインで実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

  • ターゲットデータベースでDDL文の実行に失敗した場合、データ同期タスクは引き続き実行されます。 タスクログで実行に失敗したDDLステートメントを表示できます。 タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。

  • MySQLデータベースの列名は大文字と小文字を区別しません。 したがって、ソースデータベースの複数の列の名前が大文字と小文字のみが異なる場合、同期中に列のデータはターゲットMySQLデータベースの同じ列に書き込まれます。 これにより、予期しない同期結果が生じる可能性があります。

  • データ同期が完了したら、analyze table <Table name> コマンドを実行して、データが宛先テーブルに書き込まれているかどうかを確認することを推奨します。 たとえば、ソースMySQLデータベースで高可用性 (HA) 切り替えがトリガーされた場合、データはメモリにのみ書き込まれます。 その結果、データ損失が発生する。

特別なケース

ソースDb2 for LUWデータベースは自己管理データベースです。 Db2 for LUWデータベースのデータを同期する場合は、次の項目に注意してください。

  • データ同期タスクの実行中にソースデータベースでプライマリ /セカンダリの切り替えを実行すると、タスクは失敗します。

  • DTSは、同期先データベースの最新の同期データレコードのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて同期レイテンシを計算します。 ソースデータベースでDML操作が長時間実行されない場合、同期レイテンシが不正確になる可能性があります。 同期レイテンシが高すぎる場合は、ソースデータベースでDML操作を実行してレイテンシを更新できます。

    説明

    同期するオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。 ハートビートテーブルは1秒ごとに更新されるか、データを受信します。

Db2 for LUWデータベースのデータをAnalyticDB for PostgreSQLインスタンスに同期する

説明

デフォルトでは、DTSはデータ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースのカスケード操作や削除操作などの特定の操作は、ターゲットデータベースと同期されません。

制限タイプ

説明

ソースデータベースの制限

  • 帯域幅の要件: ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうでなければ、データ同期速度は低下する。

  • 同期するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 同期するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、ターゲットデータベース内のテーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルをバッチで同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

  • データログ機能を有効にする必要があります。 それ以外の場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

    説明

    増分データ同期のみを実行する場合、ソースデータベースのデータログを24時間以上保存する必要があります。 完全データ同期と増分データ同期の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保存する必要があります。 そうしないと、DTSはデータログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 そうしないと、DTSのSLAに記載されているサービスの信頼性またはパフォーマンスを保証できません。

その他の制限

  • DTSは、Db2 for LUWのCDCレプリケーション技術に基づいて、Db2 for LUWデータベースの増分データをターゲットデータベースに同期します。 しかし、CDC複製技術には独自の限界がある。 詳細については、「SQLレプリケーションの一般的なデータ制限」をご参照ください。

  • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 初期の完全データ同期中に、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 したがって、最初の完全データ同期が完了した後、ターゲットデータベースの使用されるテーブルスペースのサイズは、ソースデータベースのサイズよりも大きくなります。

  • データ同期中は、DTSのみを使用してデータをターゲットデータベースに書き込むことをお勧めします。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 データ同期が完了したら、DMSを使用してDDLステートメントをオンラインで実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

  • スキーマ同期および増分データ同期中、ソースデータベースの外部キーはターゲットデータベースに同期されません。

  • 同期するオブジェクトとしてテーブルのみを選択できます。 テーブルを追加最適化 (AO) テーブルにすることはできません。

  • 列マッピングが完全でないテーブル同期に使用されている場合、またはソーステーブルとターゲットテーブルのスキーマに一貫性がない場合、ターゲットデータベースに含まれていないソースデータベースの列のデータが失われます。

特別なケース

ソースDb2 for LUWデータベースは自己管理データベースです。 Db2 for LUWデータベースのデータを同期する場合は、次の項目に注意してください。

  • データ同期タスクの実行中にソースデータベースでプライマリ /セカンダリの切り替えを実行すると、タスクは失敗します。

  • DTSは、同期先データベースの最新の同期データレコードのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて同期レイテンシを計算します。 ソースデータベースでDML操作が長時間実行されない場合、同期レイテンシが不正確になる可能性があります。 同期レイテンシが高すぎる場合は、ソースデータベースでDML操作を実行してレイテンシを更新できます。

    説明

    同期するオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。 ハートビートテーブルは1秒ごとに更新されるか、データを受信します。

Db2 for LUWデータベースのデータをApsaraMQ for Kafkaインスタンスに同期する

説明

デフォルトでは、DTSはデータ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースのカスケード操作や削除操作などの特定の操作は、ターゲットデータベースと同期されません。

制限タイプ

説明

ソースデータベースの制限

  • 帯域幅の要件: ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうでなければ、データ同期速度は低下する。

  • 同期するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 同期するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、ターゲットデータベース内のテーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルをバッチで同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

  • データログ機能を有効にする必要があります。 それ以外の場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

    説明

    増分データ同期のみを実行する場合、ソースデータベースのデータログを24時間以上保存する必要があります。 完全データ同期と増分データ同期の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保存する必要があります。 そうしないと、DTSはデータログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 そうしないと、DTSのSLAに記載されているサービスの信頼性またはパフォーマンスを保証できません。

その他の制限

  • DTSは、Db2 for LUWのCDCレプリケーション技術に基づいて、Db2 for LUWデータベースの増分データをターゲットデータベースに同期します。 しかし、CDC複製技術には独自の限界がある。 詳細については、「SQLレプリケーションの一般的なデータ制限」をご参照ください。

  • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 初期の完全データ同期中に、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 したがって、最初の完全データ同期が完了した後、ターゲットデータベースの使用されるテーブルスペースのサイズは、ソースデータベースのサイズよりも大きくなります。

  • データ同期中は、DTSのみを使用してデータをターゲットデータベースに書き込むことをお勧めします。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 データ同期が完了したら、data Management (DMS) を使用してDDLステートメントをオンラインで実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

特別なケース

  • データ同期タスクの実行中にソースデータベースでプライマリ /セカンダリの切り替えを実行すると、タスクは失敗します。

  • DTSは、同期先データベースの最新の同期データレコードのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて同期レイテンシを計算します。 ソースデータベースでDML操作が長時間実行されない場合、同期レイテンシが不正確になる可能性があります。 同期レイテンシが高すぎる場合は、ソースデータベースでDML操作を実行してレイテンシを更新できます。

    説明

    同期するオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。 ハートビートテーブルは1秒ごとに更新されるか、データを受信します。

  • データ同期中に、ターゲットApsaraMQ for Kafkaインスタンスがスケーリングされている場合、インスタンスを再起動する必要があります。