Data Transmission Service:移行ソースとしての SQL Server

種類

説明

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

• ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度が低下します。

• 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータの重複が発生する可能性があります。

• 移行のために特定のテーブルを選択し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つの移行タスクで移行できるテーブルは最大 1,000 個です。この制限を超えると、タスクは送信時にエラーで失敗します。この場合、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを構成することを推奨します。

• 1 つの移行タスクでサポートされるデータベースは最大 10 個です。この制限を超えると、安定性やパフォーマンスの問題が発生するリスクがあります。この場合、移行を複数のタスクに分割することを推奨します。

• データベース全体ではなく特定のオブジェクトを移行するタスクを構成する場合、同じテーブル名でスキーマ名が異なるオブジェクトを、1 つのタスク内で同じターゲットデータベースに移行することはできません。

• 増分データ移行を実行する場合、トランザクションログは次の要件を満たす必要があります：

  • トランザクションログが有効になっており、バックアップモードが「完全」に設定され、フル物理バックアップが正常に実行されている必要があります。

  • 増分データ移行のみの場合、Data Transmission Service (DTS) はソースデータベースのトランザクションログを 24 時間以上保持する必要があります。タスクに完全データ移行と増分データ移行の両方が含まれる場合、ログは少なくとも 7 日間保持する必要があります。完全データ移行が完了した後、保持期間を 24 時間以上に短縮できます。そうでない場合、DTS がトランザクションログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、データの不整合やデータ損失が発生する可能性があります。ログ保持期間が必要より短いことが原因で発生した問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

• 移行対象のソーステーブルで変更データキャプチャ (CDC) を有効にする場合、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。

  • sys.sysservers ビューの srvname フィールドの値は、SERVERPROPERTY 関数の戻り値と同じである必要があります。

  • ソースデータベースがセルフマネージド SQL Server の場合、データベース所有者は sa である必要があります。ソースデータベースが ApsaraDB RDS for SQL Server インスタンスの場合、データベース所有者は sqlsa である必要があります。

  • ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。

  • ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。

  • ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、より新しいバージョンにアップグレードすることを推奨します。

• DTS は fn_log 関数を使用してソースデータベースからログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログを早まってクリアしないでください。そうでない場合、DTS タスクが失敗する可能性があります。

• ソースデータベースでの操作に関する制限：

  • スキーマ移行および完全データ移行のフェーズでは、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。

  • 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースデータベースとターゲットデータベースのデータに不整合が生じます。リアルタイムのデータ整合性を確保するには、[スキーマ移行]、[完全データ移行]、[増分データ移行] を選択してください。

• ソースデータベースが読み取り専用インスタンスの場合、DTS は DDL 操作を移行しません。

• ソースデータベースが Azure SQL Database の場合、1 つの移行インスタンスで移行できるデータベースは 1 つだけです。

• ソースデータベースが ApsaraDB RDS for SQL Server インスタンスで、移行タスクに増分データ移行が含まれる場合、タスクの安定性のために TDE (透過的データ暗号化) が無効になっていることを確認してください。詳細については、「TDE を無効にする」をご参照ください。

• スキーマ移行タスクが実行される前に sp_rename コマンドを使用してストアドプロシージャなどのオブジェクトの名前を変更すると、タスクが期待どおりに動作しない、または失敗する可能性があります。

  説明

  データベースオブジェクトの名前を変更するには、ALTER コマンドを使用します。

• ハイブリッドログベース解析モードでは、ソースデータベースは 10 分未満の間隔での連続した列の追加または削除操作をサポートしません。たとえば、次の SQL ステートメントを連続して実行すると、タスクは失敗します。

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');

• ソースデータベースが Web 版の ApsaraDB RDS for SQL Server インスタンスである場合は、タスクを設定する際に、SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定します。

• 完全なデータ移行中は、データ書き込みに対する共有ロックの競合を防ぐために、ソースデータベースの READ_COMMITTED_SNAPSHOT パラメーターを有効にしてください。そうしないと、データの不整合やタスクの失敗などの問題が発生する可能性があります。このような状況で発生した問題は、DTS SLA の対象外です。

その他の制限

• DTS は、CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY の各データ型のデータ移行をサポートしていません。

• ターゲットデータベースの TIMESTAMP データ型の列にデータを書き込めない場合、DTS は完全または増分データ移行をサポートしません。これにより、データの不整合やタスクの失敗が発生する可能性があります。

• ソースデータベースからトリガーを移行するには、移行タスクに使用されるデータベースアカウントがターゲットデータベースに対する Owner 権限を持っている必要があります。

• ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) ステップで オブジェクト設定 を SQL Server 増分同期モード に設定した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。 このモードでは、DTS はヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列を含むテーブル、スパース列を含むテーブルの移行をサポートしていません。 これらの制限は、ハイブリッドログベースの解析モードでは適用されません。

  説明

  テーブルの詳細の表示方法については、「SQL Server でヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列を持つテーブル、スパース列を持つテーブルの情報を表示する方法」をご参照ください。

• オブジェクト設定 を SQL Server 増分同期モード に、クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) ステップで設定した場合、以下の制限も適用されます。

  • DTS は増分移行のために CDC コンポーネントに依存します。ソースデータベースの CDC ジョブが期待どおりに実行されていることを確認してください。そうでない場合、DTS タスクは失敗します。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行して、保持期間を調整します。

    説明

    • <time> は、保存期間を分単位で指定します。

    • 単一テーブルの 1 日あたりの増分 SQL 変更の平均数が 1000 万を超える場合、<time> を 1440 に設定します。

  • 1 つの移行タスクで、CDC を有効にするテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

• 増分同期のための CDC インスタンスのポーリングとクエリ ステップで、オブジェクト設定 を SQL Server 増分同期モード に設定した場合、以下の制限も適用されます:

  • DTS インスタンスが使用するソースデータベースアカウントは、CDC を有効にするための権限を持っている必要があります。データベースレベルの CDC を有効にするには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効にするには、特権アカウントが必要です。

    説明

    • Azure SQL Database コンソールで提供される最上位の特権アカウント (サーバー管理者) は、要件を満たしています。vCore モデルで購入したデータベースの場合、すべての仕様で CDC を有効にできます。DTU モデルで購入したデータベースの場合、CDC は S3 以上のサービス階層でのみ有効にできます。

    • Amazon RDS for SQL Server インスタンスの特権アカウントは要件を満たしており、ストアドプロシージャを介したデータベースレベルの CDC の有効化をサポートしています。

    • クラスター化列ストアインデックスを持つテーブルでは CDC を有効にできません。

    • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

  • DTS は、ソースデータベースの各テーブルの CDC インスタンスをポーリングおよびクエリして増分データを取得します。ソースデータベースから移行するテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。保存期間を調整するには、exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行します。

    説明

    • <time> は、保持期間を分単位で指定します。

    • 単一テーブルの 1 日あたりの増分 SQL 変更の平均数が 1,000 万を超える場合、<time> を 1440 に設定します。

  • 連続した列の追加または削除操作はサポートされていません (1 分以内に 2 回以上の ADD COLUMN または DROP COLUMN DDL 操作)。そうでない場合、タスクが失敗する可能性があります。

  • ソースデータベースの CDC インスタンスを変更しないでください。そうでない場合、データ移行タスクが失敗したり、データ損失が発生したりする可能性があります。

• 異なる SQL Server バージョン間でデータを移行する場合は、事前に互換性を確認してください。

• 増分データ移行のレイテンシを正確にレポートするために、DTS はソースデータベースにオブジェクトを作成します。ログベース解析モードでは、DTS は dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DDL ストレージテーブルを作成します。ハイブリッドログベース解析モードでは、DTS は同じオブジェクトを作成し、データベースレベルおよびテーブルレベルの CDC も有効にします。CDC が有効になっているテーブルでは、データ変更のレートが 1,000 RPS (1秒あたりの行数) を超えないようにしてください。

• データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間に実行してください。完全データ移行中、DTS はソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、それらの負荷を増加させる可能性があります。

• 完全データ移行中、同時 INSERT 操作によりターゲットテーブルに断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなることがあります。

• DTS が FLOAT または DOUBLE データ型の列を移行する際に使用する精度が、お客様のビジネス要件を満たしていることを確認してください。 DTS は、ROUND(COLUMN,PRECISION) 関数を使用してこれらの列から値を読み取ります。 精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。

• DTS は、失敗したタスクの再開を最大 7 日間試みます。ビジネスワークロードを宛先インスタンスに切り替える前に、移行タスクを終了またはリリースしてください。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消してください。これにより、再開されたタスクがソースのデータで宛先インスタンスのデータを上書きすることを防ぎます。

• 移行タスクに増分データ移行が含まれる場合、再インデックス操作を実行することはできません。これにより、タスクが失敗したり、データ損失が発生したりする可能性があります。

  説明

  CDC が有効になっているテーブルのプライマリキーは変更できません。

• 単一の移行タスクで CDC が有効なテーブルの数が、DTS がサポートする CDC が有効になっているテーブルの最大数の制限 パラメーターで設定された値を超えた場合、事前チェックは失敗します。

• タスクに増分移行が含まれ、書き込み対象の CDC 対応テーブルの単一フィールドに 64 KB を超えるデータが含まれる場合、事前に exec sp_configure 'max text repl size', -1; コマンドを実行してソースデータベースの構成を調整してください。

  説明

  デフォルトでは、CDC ジョブは単一フィールドに対して最大 64 KB のデータサイズを処理できます。

• 増分データ移行を実行するには、ターゲットデータベースで有効になっているトリガーと外部キーを無効にしてください。そうでない場合、タスクは失敗します。

• 複数の移行インスタンスが同じソース SQL Server データベースを使用する場合、それらの増分データ収集モジュールは独立して動作します。

• タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、そのパラメーターを調整したりすることがあります。

  説明

  変更されるのは DTS タスクパラメーターのみで、データベースパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれます。

• SQL Server は商用のクローズドソースデータベースです。そのログフォーマットは、既知または未知のフォーマット特性により、DTS での増分変更データキャプチャ (CDC) および解析中に避けられない問題を引き起こす可能性があります。本番環境で SQL Server ソースからの増分同期に DTS を有効にする前に、包括的な概念実証 (POC) テストを実施してください。このテストでは、すべてのビジネス変更シナリオ、スキーマ調整、およびピーク負荷ストレススストをカバーする必要があります。SQL Server のログフォーマットとその予測不可能性のため、本番環境のロジックと POC フェーズとの一貫性が、安定的かつ効率的な DTS 運用に不可欠です。

• 増分データ移行中、ソースデータベースでの部分的なトランザクションのロールバックはサポートされておらず、見逃される可能性があります。

特殊なケース

• ソースが ApsaraDB RDS for SQL Server インスタンスの場合、DTS はデータ移行用に、インスタンスに rdsdt_dtsacct という名前のシステムアカウントを作成します。 タスクの実行中は、このアカウントを削除したり、パスワードを変更したりしないでください。 そうしないと、タスクが失敗する可能性があります。 詳細については、「システムアカウント」をご参照ください。

• 宛先が ApsaraDB RDS for SQL Server インスタンスの場合、DTS は自動的にデータベースを作成します。ただし、データベース名が ApsaraDB RDS for SQL Server の命名規則に従っていない場合は、移行タスクを構成する前に宛先インスタンスにデータベースを作成する必要があります。詳細については、「データベースの作成」をご参照ください。

種類

説明

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

• ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度が低下します。

• 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータの重複が発生する可能性があります。

• 移行のために特定のテーブルを選択し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つの移行タスクで移行できるテーブルは最大 1,000 個です。この制限を超えると、タスクは送信時にエラーで失敗します。この場合、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを構成することを推奨します。

• 1 つの移行タスクでサポートされるデータベースは最大 10 個です。この制限を超えると、安定性やパフォーマンスの問題が発生するリスクがあります。この場合、移行を複数のタスクに分割することを推奨します。

• データベース全体ではなく特定のオブジェクトを移行するタスクを構成する場合、同じテーブル名でスキーマ名が異なるオブジェクトを、1 つのタスク内で同じターゲットデータベースに移行することはできません。

• 増分データ移行を実行する場合、トランザクションログは次の要件を満たす必要があります：

  • トランザクションログが有効になっており、バックアップモードが「完全」に設定され、フル物理バックアップが正常に実行されている必要があります。

  • 増分データ移行のみの場合、Data Transmission Service (DTS) はソースデータベースのトランザクションログを 24 時間以上保持する必要があります。タスクに完全データ移行と増分データ移行の両方が含まれる場合、ログは少なくとも 7 日間保持する必要があります。完全データ移行が完了した後、保持期間を 24 時間以上に短縮できます。そうでない場合、DTS がトランザクションログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、データの不整合やデータ損失が発生する可能性があります。ログ保持期間が必要より短いことが原因で発生した問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

• 移行対象のソーステーブルで変更データキャプチャ (CDC) を有効にする場合、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。

  • sys.sysservers ビューの srvname フィールドの値は、SERVERPROPERTY 関数の戻り値と同じである必要があります。

  • ソースデータベースがセルフマネージド SQL Server の場合、データベース所有者は sa である必要があります。ソースデータベースが ApsaraDB RDS for SQL Server インスタンスの場合、データベース所有者は sqlsa である必要があります。

  • ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。

  • ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。

  • ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、より新しいバージョンにアップグレードすることを推奨します。

• DTS は fn_log 関数を使用してソースデータベースからログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログを早まってクリアしないでください。そうでない場合、DTS タスクが失敗する可能性があります。

• ソースデータベースでの操作に関する制限：

  • スキーマ移行および完全データ移行のフェーズでは、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。

  • 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースデータベースとターゲットデータベースのデータに不整合が生じます。リアルタイムのデータ整合性を確保するには、[スキーマ移行]、[完全データ移行]、[増分データ移行] を選択してください。

• ソースデータベースが読み取り専用インスタンスの場合、DTS は DDL 操作を移行しません。

• ソースデータベースが Azure SQL Database の場合、1 つの移行インスタンスで移行できるデータベースは 1 つだけです。

• ソースデータベースが ApsaraDB RDS for SQL Server インスタンスで、移行タスクに増分データ移行が含まれる場合、タスクの安定性のために TDE (透過的データ暗号化) が無効になっていることを確認してください。詳細については、「TDE を無効にする」をご参照ください。

• スキーマ移行タスクの実行前に sp_rename コマンドを使用してストアドプロシージャなどのオブジェクトの名前を変更した場合、タスクが期待どおりに動作しないか、失敗する可能性があります。

  説明

  データベースオブジェクトの名前を変更するには、ALTER コマンドを使用します。

• ハイブリッドログベース解析モードでは、ソースデータベースは 10 分未満の間隔での連続した列の追加または削除操作をサポートしません。たとえば、次の SQL ステートメントを連続して実行すると、タスクは失敗します。

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');

• ソースデータベースが Web 版の ApsaraDB RDS for SQL Server インスタンスである場合は、タスクの設定時に SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定します。

• 完全なデータ移行中は、共有ロックの競合によるデータ書き込みへの影響を防ぐため、ソースデータベースの READ_COMMITTED_SNAPSHOT パラメーターを有効にします。そうしないと、データの不整合やタスクの失敗などの問題が発生する可能性があります。このような状況で発生した問題は、DTS SLA の対象外です。

その他の制限

• 移行は基本的なデータの型のみをサポートしており、CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY 型のデータ、または CREATE TYPE コマンドを使用して作成されたユーザー定義型はサポートしていません。

• DDL ステートメントがターゲットデータベースに書き込めなかった場合でも、DTS タスクは実行を継続します。タスクログを確認して、失敗した DDL ステートメントを見つける必要があります。タスクログの表示方法については、「タスクログの表示」をご参照ください。

• ターゲットデータベースにはカスタムプライマリキーが必要です。または、テーブル・列設定 ステップで、プライマリキー列の追加 を設定します。そうでない場合、移行が失敗することがあります。

• ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) ステップで オブジェクト設定 を SQL Server 増分同期モード に設定した場合、移行するテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。 このモードでは、DTS はヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、またはスパース列のあるテーブルの移行をサポートしていません。 これらの制限は、ハイブリッドログベースの解析モードでは適用されません。

  説明

  テーブルの詳細の表示方法については、「SQL Server でヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列を持つテーブル、スパース列を持つテーブルの情報を表示する方法」をご参照ください。

• クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) ステップで オブジェクト設定 を SQL Server 増分同期モード に設定した場合、以下の制限も適用されます:

  • DTS は増分移行のために CDC コンポーネントに依存します。ソースデータベースの CDC ジョブが期待どおりに実行されていることを確認してください。そうでない場合、DTS タスクは失敗します。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。保存期間を調整するには、exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行します。

    説明

    • <time> は、保持期間を分単位で指定します。

    • 単一テーブルあたりの 1 日の平均増分 SQL 変更数が 1,000 万を超える場合、 <time> を 1440 に設定します。

  • 1 つの移行タスクで、CDC を有効にするテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

• 増分同期のための CDC インスタンスのポーリングとクエリ ステップで、オブジェクト設定 を SQL Server 増分同期モード に設定した場合、以下の制限も適用されます:

  • DTS インスタンスが使用するソースデータベースアカウントには、CDC を有効にする権限が必要です。データベースレベルの CDC を有効にするには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効にするには、特権アカウントが必要です。

    説明

    • Azure SQL Database コンソールで提供される最上位の特権アカウント (サーバー管理者) は、要件を満たしています。 vCore モデルに基づいて購入したデータベースの場合、すべての仕様で CDC を有効にできます。 DTU モデルに基づいて購入したデータベースの場合、CDC は S3 以上のサービス階層でのみ有効にできます。

    • Amazon RDS for SQL Server インスタンスの特権アカウントは要件を満たしており、ストアドプロシージャを介したデータベースレベルの CDC の有効化をサポートしています。

    • クラスター化列ストアインデックスを持つテーブルでは CDC を有効にできません。

    • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

  • DTS は、ソースデータベースの各テーブルの CDC インスタンスをポーリングおよびクエリして増分データを取得します。ソースデータベースから移行するテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行して保持期間を調整できます。

    説明

    • <time> は保存期間を分単位で指定します。

    • 単一テーブルにおける 1 日あたりの平均増分 SQL 変更数が 1,000 万を超える場合、<time> を 1440 に設定します。

  • 連続した列の追加または削除操作はサポートされていません (1 分以内に 2 回以上の ADD COLUMN または DROP COLUMN DDL 操作)。そうでない場合、タスクが失敗する可能性があります。

  • ソースデータベースの CDC インスタンスを変更しないでください。そうでない場合、データ移行タスクが失敗したり、データ損失が発生したりする可能性があります。

• 増分データ移行のレイテンシを正確にレポートするために、DTS はソースデータベースにオブジェクトを作成します。ログベース解析モードでは、DTS は dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DDL ストレージテーブルを作成します。ハイブリッドログベース解析モードでは、DTS は同じオブジェクトを作成し、データベースレベルおよびテーブルレベルの CDC も有効にします。CDC が有効になっているテーブルでは、データ変更のレートが 1,000 RPS (1秒あたりの行数) を超えないようにしてください。

• AnalyticDB for MySQL の固有の制限により、AnalyticDB for MySQL ノードのディスク使用率が 80% を超えると、ターゲットデータベースへの書き込みパフォーマンスが低下し、DTS タスクに遅延が発生します。ディスク使用率が 90% を超えると、ターゲットデータベースにデータを書き込めなくなり、DTS タスクは失敗します。移行オブジェクトに基づいて必要なディスク領域を見積もり、宛先クラスターに十分なストレージ領域があることを確認する必要があります。

• DTS タスクの実行中に、宛先の AnalyticDB for MySQL 3.0 クラスターがバックアップ中の場合、タスクは失敗します。

• データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間に実行してください。完全データ移行中、DTS はソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、それらの負荷を増加させる可能性があります。

• 完全データ移行中、同時 INSERT 操作によりターゲットテーブルに断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなることがあります。

• DTS が FLOAT または DOUBLE データ型の列を移行する際の精度が、お客様のビジネス要件を満たしていることを確認してください。 DTS は、これらの列から値を読み取るために ROUND(COLUMN,PRECISION) 関数を使用します。 精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。

• DTS は、失敗したタスクを最大 7 日間再開しようと試みます。ビジネスワークロードを宛先インスタンスに切り替える前に、移行タスクを終了またはリリースしてください。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消してください。これにより、再開されたタスクがソースのデータで宛先インスタンスのデータを上書きするのを防ぎます。

• 移行タスクに増分データ移行が含まれる場合、再インデックス操作を実行することはできません。これにより、タスクが失敗したり、データ損失が発生したりする可能性があります。

  説明

  CDC が有効になっているテーブルのプライマリキーは変更できません。

• 単一の移行タスクで CDC が有効化されたテーブルの数が、DTS がサポートする CDC が有効になっているテーブルの最大数の制限 パラメーターに設定されている値を超えた場合、事前チェックは失敗します。

• タスクに増分移行が含まれており、CDC が有効なテーブルに書き込まれる単一フィールドに 64 KB を超えるデータが含まれている場合は、事前に exec sp_configure 'max text repl size', -1; コマンドを実行して、ソースデータベースの構成を調整してください。

  説明

  デフォルトでは、CDC ジョブは単一フィールドに対して最大 64 KB のデータサイズを処理できます。

• 複数の移行インスタンスが同じソース SQL Server データベースを使用する場合、それらの増分データ収集モジュールは独立して動作します。

• タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、そのパラメーターを調整したりすることがあります。

  説明

  変更されるのは DTS タスクパラメーターのみで、データベースパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれます。

• SQL Server は商用のクローズドソースデータベースです。そのログフォーマットは、既知または未知のフォーマット特性により、DTS での増分変更データキャプチャ (CDC) および解析中に避けられない問題を引き起こす可能性があります。本番環境で SQL Server ソースからの増分同期に DTS を有効にする前に、包括的な概念実証 (POC) テストを実施してください。このテストでは、すべてのビジネス変更シナリオ、スキーマ調整、およびピーク負荷ストレススストをカバーする必要があります。SQL Server のログフォーマットとその予測不可能性のため、本番環境のロジックと POC フェーズとの一貫性が、安定的かつ効率的な DTS 運用に不可欠です。

• 宛先データベースが AnalyticDB for MySQL の場合、DTS は AnalyticDB for MySQL がネイティブにサポートするデータ型のみの書き込みをサポートします。これには、基本データ型や、ARRAY、MAP、JSON などの複合データ型が含まれます。MULTIVALUE などの他の型はサポートされていません。

• 増分移行中のソースデータベースでの部分的なトランザクションのロールバックはサポートされておらず、失われる可能性があります。

特殊なケース

ソースが ApsaraDB RDS for SQL Server インスタンスの場合、DTS はデータ移行のために、インスタンスに rdsdt_dtsacct という名前のシステムアカウントを作成します。 タスクの実行中は、このアカウントを削除したり、パスワードを変更したりしないでください。 そうしないと、タスクが失敗する可能性があります。 詳細については、「システムアカウント」をご参照ください。

種類

説明

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

• ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度が低下します。

• 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータの重複が発生する可能性があります。

• 移行のために特定のテーブルを選択し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つの移行タスクで移行できるテーブルは最大 1,000 個です。この制限を超えると、タスクは送信時にエラーで失敗します。この場合、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを構成することを推奨します。

• 1 つの移行タスクでサポートされるデータベースは最大 10 個です。この制限を超えると、安定性やパフォーマンスの問題が発生するリスクがあります。この場合、移行を複数のタスクに分割することを推奨します。

• データベース全体ではなく特定のオブジェクトを移行するタスクを構成する場合、同じテーブル名でスキーマ名が異なるオブジェクトを、1 つのタスク内で同じターゲットデータベースに移行することはできません。

• 増分データ移行を実行する場合、トランザクションログは次の要件を満たす必要があります：

  • トランザクションログが有効になっており、バックアップモードが「完全」に設定され、フル物理バックアップが正常に実行されている必要があります。

  • 増分データ移行のみの場合、Data Transmission Service (DTS) はソースデータベースのトランザクションログを 24 時間以上保持する必要があります。タスクに完全データ移行と増分データ移行の両方が含まれる場合、ログは少なくとも 7 日間保持する必要があります。完全データ移行が完了した後、保持期間を 24 時間以上に短縮できます。そうでない場合、DTS がトランザクションログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、データの不整合やデータ損失が発生する可能性があります。ログ保持期間が必要より短いことが原因で発生した問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

• 移行対象のソーステーブルで変更データキャプチャ (CDC) を有効にする場合、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。

  • sys.sysservers ビューの srvname フィールドの値は、SERVERPROPERTY 関数の戻り値と同じである必要があります。

  • ソースデータベースがセルフマネージド SQL Server の場合、データベース所有者は sa である必要があります。ソースデータベースが ApsaraDB RDS for SQL Server インスタンスの場合、データベース所有者は sqlsa である必要があります。

  • ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。

  • ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。

  • ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、より新しいバージョンにアップグレードすることを推奨します。

• DTS は fn_log 関数を使用してソースデータベースからログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログを早まってクリアしないでください。そうでない場合、DTS タスクが失敗する可能性があります。

• ソースデータベースでの操作に関する制限：

  • スキーマ移行および完全データ移行のフェーズでは、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。

  • 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースデータベースとターゲットデータベースのデータに不整合が生じます。リアルタイムのデータ整合性を確保するには、[スキーマ移行]、[完全データ移行]、[増分データ移行] を選択してください。

• ソースデータベースが読み取り専用インスタンスの場合、DTS は DDL 操作を移行しません。

• ソースデータベースが Azure SQL Database の場合、1 つの移行インスタンスで移行できるデータベースは 1 つだけです。

• ソースデータベースが ApsaraDB RDS for SQL Server インスタンスで、移行タスクに増分データ移行が含まれる場合、タスクの安定性のために TDE (透過的データ暗号化) が無効になっていることを確認してください。詳細については、「TDE を無効にする」をご参照ください。

• スキーマ移行タスクが実行される前に sp_rename コマンドを使用してストアドプロシージャなどのオブジェクトの名前を変更すると、タスクが期待どおりに動作しないか、または失敗する可能性があります。

  説明

  データベースオブジェクトの名前を変更するには、ALTER コマンドを使用します。

• ハイブリッドログベース解析モードでは、ソースデータベースは 10 分未満の間隔での連続した列の追加または削除操作をサポートしません。たとえば、次の SQL ステートメントを連続して実行すると、タスクは失敗します。

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');

• ソースデータベースが Web 版の ApsaraDB RDS for SQL Server インスタンスである場合、タスクを設定する際に、SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定します。

• 完全なデータ移行中に、共有ロックの競合によるデータ書き込みへの影響を防ぐため、ソースデータベースの READ_COMMITTED_SNAPSHOT パラメーターを有効にしてください。そうしないと、データの不整合やタスクの失敗などの問題が発生する可能性があります。このような状況で発生した問題は、DTS SLA の対象外です。

その他の制限

• 移行は基本的なデータの型にのみ対応しており、CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY 型のデータ、または CREATE TYPE コマンドを使用して作成されたユーザー定義型には対応していません。

• DTS は、INDEX、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK、FULL_TEXT_INDEX、DATATYPE、DEFAULT、SYNONYM、CATALOG、PLAN_GUIDE、DEFAULT_CONSTRAINT、UK、CK、SEQUENCE の各データベースオブジェクトの移行をサポートしていません。

• 移行オブジェクトを選択する場合、サポートされる最小単位はテーブルです。列マッピングを変更できます。部分的なテーブル移行に列マッピングを使用する場合、またはソースとターゲットのテーブル構造が一致しない場合、ソーステーブルに存在するがターゲットテーブルには存在しない列のデータは失われます。

• ターゲットテーブルは、追加最適化 (AO) テーブルにすることはできません。

• 移行対象のテーブルにプライマリキーがある場合、ターゲットテーブルのプライマリキー列はソーステーブルと同じでなければなりません。移行対象のテーブルにプライマリキーがない場合、ターゲットテーブルのプライマリキー列は分散キーと同じでなければなりません。

• プライマリキー列を含むターゲットテーブルの一意キーは、分散キーのすべての列を含んでいる必要があります。

• ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) ステップで オブジェクト設定 を SQL Server 増分同期モード に設定した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。 このモードでは、DTS はヒープテーブル、プライマリキーのないテーブル、圧縮されたテーブル、計算列のあるテーブル、またはスパース列のあるテーブルの移行をサポートしていません。 これらの制限は、ハイブリッドログベースの解析モードでは適用されません。

  説明

  テーブルの詳細の表示方法については、「SQL Server でヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列を持つテーブル、スパース列を持つテーブルの情報を表示する方法」をご参照ください。

• クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) ステップで オブジェクト設定 を SQL Server 増分同期モード に設定した場合、以下の制限も適用されます。

  • DTS は増分移行のために CDC コンポーネントに依存します。ソースデータベースの CDC ジョブが期待どおりに実行されていることを確認してください。そうでない場合、DTS タスクは失敗します。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。保持期間を調整するには、exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行します。

    説明

    • <time> は、保持期間を分単位で指定します。

    • 単一テーブルの 1 日あたりの平均増分 SQL 変更数が 1,000 万を超える場合、<time> を 1440 にセットします。

  • 1 つの移行タスクで、CDC を有効にするテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

• 増分同期のための CDC インスタンスのポーリングとクエリ ステップで、オブジェクト設定 を SQL Server 増分同期モード に設定した場合、以下の制限も適用されます。

  • DTS インスタンスが使用するソースデータベースアカウントは、CDC を有効にするための権限を持つ必要があります。データベースレベルの CDC を有効にするには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効にするには、特権アカウントが必要です。

    説明

    • Azure SQL Database コンソールで提供される、最も権限の高いアカウント (サーバー管理者) が要件を満たしています。 vCore モデルで購入したデータベースの場合、すべての仕様で CDC を有効にできます。 DTU モデルで購入したデータベースの場合、CDC は S3 以上のサービスレベルでのみ有効にできます。

    • Amazon RDS for SQL Server インスタンスの特権アカウントは要件を満たしており、ストアドプロシージャを介したデータベースレベルの CDC の有効化をサポートしています。

    • クラスター化列ストアインデックスを持つテーブルでは CDC を有効にできません。

    • DTS 増分データ移行タスクの事前チェックモジュールは、ソースデータベースで CDC を有効にします。このプロセス中、SQL Server エンジンの内部的な制限により、ソースデータベースで一時的なテーブルロックが発生する可能性があります。

  • DTS は、ソースデータベースの各テーブルの CDC インスタンスをポーリングおよびクエリして増分データを取得します。ソースデータベースから移行するテーブルは 1,000 個以下にしてください。そうでない場合、タスクで高レイテンシが発生したり、不安定になったりする可能性があります。

  • デフォルトでは、CDC コンポーネントは増分データを 3 日間保存します。保持期間を調整するには、exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行します。

    説明

    • <time> には、保持期間を分単位で指定します。

    • 単一テーブルの 1 日あたりの増分 SQL 変更の平均数が 1,000 万を超える場合、<time> を 1440 に設定します。

  • 連続した列の追加または削除操作はサポートされていません (1 分以内に 2 回以上の ADD COLUMN または DROP COLUMN DDL 操作)。そうでない場合、タスクが失敗する可能性があります。

  • ソースデータベースの CDC インスタンスを変更しないでください。そうでない場合、データ移行タスクが失敗したり、データ損失が発生したりする可能性があります。

• 増分データ移行のレイテンシを正確にレポートするために、DTS はソースデータベースにオブジェクトを作成します。ログベース解析モードでは、DTS は dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DDL ストレージテーブルを作成します。ハイブリッドログベース解析モードでは、DTS は同じオブジェクトを作成し、データベースレベルおよびテーブルレベルの CDC も有効にします。CDC が有効になっているテーブルでは、データ変更のレートが 1,000 RPS (1秒あたりの行数) を超えないようにしてください。

• データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間に実行してください。完全データ移行中、DTS はソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、それらの負荷を増加させる可能性があります。

• 完全データ移行中、同時 INSERT 操作によりターゲットテーブルに断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなることがあります。

• DTS を使用して FLOAT または DOUBLE データの型の列を移行する際、その精度がお客様のビジネス要件を満たしていることを確認してください。DTS は、これらの列から値を読み取るために ROUND(COLUMN,PRECISION) 関数を使用します。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。

• DTS は、失敗したタスクを最大 7 日間再開しようと試みます。ビジネスワークロードを宛先インスタンスに切り替える前に、移行タスクを終了またはリリースしてください。あるいは、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消してください。これにより、再開されたタスクがソースのデータで宛先インスタンスのデータを上書きするのを防ぎます。

• 移行タスクに増分データ移行が含まれる場合、再インデックス操作を実行することはできません。これにより、タスクが失敗したり、データ損失が発生したりする可能性があります。

  説明

  CDC が有効になっているテーブルのプライマリキーは変更できません。

• 1 つの移行タスク内の CDC が有効なテーブルの数が DTS がサポートする CDC が有効になっているテーブルの最大数の制限 パラメーターで設定された値を超えた場合、事前チェックは失敗します。

• タスクに増分移行が含まれており、かつ書き込み対象の CDC 対応テーブル内の単一フィールドに 64 KB を超えるデータが含まれる場合は、事前に exec sp_configure 'max text repl size', -1; コマンドを実行して、ソースデータベースの構成を調整してください。

  説明

  デフォルトでは、CDC ジョブは単一フィールドに対して最大 64 KB のデータサイズを処理できます。

• 複数の移行インスタンスが同じソース SQL Server データベースを使用する場合、それらの増分データ収集モジュールは独立して動作します。

• タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、そのパラメーターを調整したりすることがあります。

  説明

  変更されるのは DTS タスクパラメーターのみで、データベースパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれます。

• SQL Server は商用のクローズドソースデータベースです。そのログフォーマットは、既知または未知のフォーマット特性により、DTS での増分変更データキャプチャ (CDC) および解析中に避けられない問題を引き起こす可能性があります。本番環境で SQL Server ソースからの増分同期に DTS を有効にする前に、包括的な概念実証 (POC) テストを実施してください。このテストでは、すべてのビジネス変更シナリオ、スキーマ調整、およびピーク負荷ストレススストをカバーする必要があります。SQL Server のログフォーマットとその予測不可能性のため、本番環境のロジックと POC フェーズとの一貫性が、安定的かつ効率的な DTS 運用に不可欠です。

• 増分移行中、DTS はソースデータベースでの部分的なトランザクションのロールバックをサポートしておらず、ロールバック操作が失われる可能性があります。

特殊なケース

ソースが ApsaraDB RDS for SQL Server インスタンスである場合、DTS はデータ移行のために、インスタンス上に rdsdt_dtsacct という名前のシステムアカウントを作成します。タスクの実行中は、このアカウントを削除したり、パスワードを変更したりしないでください。そうしないと、タスクが失敗する可能性があります。詳細については、「システムアカウント」をご参照ください。