Data Transmission Service:Microsoft Azure 上の SQL Server データベースから ApsaraDB RDS for SQL Server にデータを移行する

カテゴリ

説明

移行元データベースの制限

• 移行元データベースが SQL Server Enterprise Edition を実行する Microsoft Azure VM の場合、そのバージョンは SQL Server 2008 以降である必要があります。 移行元データベースが SQL Server Standard Edition を実行する Microsoft Azure VM の場合、そのバージョンは SQL Server 2016 SP1 以降である必要があります。 SQL Server 2017 はサポートされていません。

• 移行元データベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が低下します。

• 移行するテーブルには、PRIMARY KEY または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。 そうしないと、移行先データベースに重複したデータレコードが含まれる可能性があります。

• 1 つのデータ移行タスクを実行して、最大 10 個のデータベースを移行できます。 10 個を超えるデータベースを移行する場合は、複数のタスクを設定してデータベースを移行することをお勧めします。 そうしないと、データ移行タスクのパフォーマンスと安定性が損なわれる可能性があります。

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

• 移行元データベースで実行される操作の制限:

  • スキーマ移行とフルデータ移行中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。 そうしないと、データ移行タスクは失敗します。

  • フルデータ移行のみを実行する場合は、データ移行中に移行元データベースにデータを書き込まないでください。 そうしないと、移行元データベースと移行先データベース間でデータの不整合が発生します。 データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。

• 読み取り専用インスタンスを移行元データベースとして使用することはできません。

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

• フルデータ移行中は、移行元データベースの READ_COMMITTED_SNAPSHOT のトランザクション処理モードパラメータを有効にすることをお勧めします。 そうしないと、共有ロックが原因でデータ書き込みに影響が出たり、データの不整合が発生したり、インスタンスが実行に失敗したりする可能性があります。 このような状況で発生する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

その他の制限

• DTS は、CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY などのタイプのデータは移行しません。

• DTS の増分データ移行タスクのプレモジュールは、移行元データベースで CDC を有効にします。 このプロセスでは、SQL Server データベースの制限により、移行元データベースで数秒間続くロックされたテーブルが発生します。

• DTS は、CDC インスタンスをクエリすることによって増分データを移行します。 増分データ移行を実行する場合は、次の制限事項に注意してください。

  • DTS は、移行元データベースの各テーブルの CDC インスタンスをクエリすることによって増分データを取得します。 したがって、移行元データベースから移行されるテーブルの数は 1,000 を超えることはできません。 そうしないと、データ移行タスクが遅延したり、不安定になったりする可能性があります。

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

    説明

    • <time> は保存時間を示します。 単位: 分。

    • SQL Server データベースの増分データの 1 日あたりの平均数が 1,000 万を超える場合は、<time> パラメータを 1,440 に設定することをお勧めします。

  • 1 分間に 2 回を超えて列を追加または削除する DDL 文を実行することはできません。 そうしないと、データ移行タスクが失敗する可能性があります。

  • データ移行中は、移行元データベースの CDC インスタンスを変更することはできません。 そうしないと、データ移行タスクが失敗したり、データが失われたりする可能性があります。

  • 複数のデータベースの複数のテーブルを移行するようにタスクを設定すると、安定性とパフォーマンスの問題が発生する可能性があります。

  • 増分データ移行には約 10 秒の遅延があります。

• 異なるバージョンのデータベース間でデータを移行する場合は、データベースのバージョンに互換性があることを確認してください。

• データ移行タスクに増分データ移行が含まれている場合、インデックス再作成操作を実行することはできず、移行先データベースのトリガーと外部キーを無効にする必要があります。 そうしないと、データ移行タスクが失敗したり、データが失われたりする可能性があります。

  説明

  DTS は、CDC が有効になっているテーブルのプライマリキーに関連する DDL 操作を移行できません。

• 1 つの移行タスクで移行する CDC が有効なテーブルの数が 1,000 を超える場合、または DTS がサポートする [CDC が有効になっているテーブルの最大数] を超える場合、事前チェックは失敗します。

• タスクに増分データ移行が含まれており、CDC が有効になっているテーブルで 1 つのフィールドに 64 KB を超えるサイズのデータが必要な場合は、事前に exec sp_configure 'max text repl size', -1; コマンドを実行して移行元データベースを設定します。

  説明

  デフォルトでは、CDC ジョブは最大 64 KB のデータを処理できます。

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

• 移行元データベースのログに基づく増分同期モードでは、DTS は移行元データベースに dts_cdc_sync_ddl という名前のトリガー、dts_sync_progress という名前のハートビートテーブル、dts_cdc_ddl_history という名前の DDL 履歴テーブルを作成して、データ移行の遅延が正確であることを保証します。 ハイブリッドログベースの解析増分同期モードでは、DTS は dts_cdc_sync_ddl という名前のトリガー、dts_sync_progress という名前のハートビートテーブル、dts_cdc_ddl_history という名前の DDL 履歴テーブルを作成し、移行元データベースと特定のテーブルに対して CDC を有効にします。 移行元データベースの CDC が有効になっているテーブルの 1 秒あたりの最大レコード数を 1,000 に設定することをお勧めします。

• データを移行する前に、データ移行が移行元データベースと移行先クラスタのパフォーマンスに与える影響を評価してください。 データ移行は、オフピーク時に実行することをお勧めします。 フルデータ移行中、DTS は移行元データベースと移行先データベースの読み取りリソースと書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

• フルデータ移行中、同時 INSERT 操作によって移行先データベースのテーブルに断片化が発生します。 フルデータ移行が完了すると、移行先データベースの表領域は移行元データベースの表領域よりも大きくなります。

• FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。 DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。 精度を指定しない場合、DTS は FLOAT データ型の精度を 38 桁、DOUBLE データ型の精度を 308 桁に設定します。

• DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。 ワークロードを移行先クラスタに切り替える前に、失敗したタスクを停止または解放する必要があります。 また、REVOKE 文を実行して、DTS が移行先データベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。 そうしないと、データ移行タスクが再開された後、移行元データベースのデータによって移行先データベースのデータが上書きされます。

• 移行元 SQL Server データベースを共有する複数のデータ移行インスタンスの増分データ収集モジュールは、互いに独立しています。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。 復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。 データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

移行タイプ

インスタンス構成料金

インターネットトラフィック料金

スキーマ移行とフルデータ移行

無料。

ターゲットデータベースの アクセス方法 パラメーターが パブリック IP アドレス に設定されている場合、インターネットトラフィックに対して課金されます。詳細については、「請求の概要」をご参照ください。

増分データ移行

課金されます。詳細については、「請求の概要」をご参照ください。

操作タイプ

SQL 文

DML

INSERT、UPDATE、DELETE

DDL

• CREATE TABLE

  説明

  CREATE TABLE 操作でパーティションテーブルまたは関数を含むテーブルが作成される場合、DTS はその操作を移行しません。

• ALTER TABLE

  ALTER TABLE 操作には、ADD COLUMN と DROP COLUMN のみ含まれます。

• DROP TABLE

• CREATE INDEX と DROP INDEX

データベースタイプ

スキーマ移行

フルデータ移行

増分データ移行

参考資料

Microsoft Azure 上の SQL Server データベース

SELECT 権限

SELECT 権限

sysadmin ロールの権限

詳細については、「Microsoft Azure」をご参照ください。

ApsaraDB RDS for SQL Server インスタンス

読み取りおよび書き込み権限

特権アカウントまたは標準アカウントを作成する と アカウントの権限を変更する