すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:自己管理 SQL Server データベースから ApsaraDB RDS for SQL Server インスタンスへのデータ移行

    ドキュメントセンター

    ApsaraDB RDS:自己管理 SQL Server データベースから ApsaraDB RDS for SQL Server インスタンスへのデータ移行

    最終更新日:Nov 09, 2025

    このトピックでは、Data Transmission Service (DTS) コンソールを使用して、自己管理 SQL Server データベースから Alibaba Cloud ApsaraDB RDS for SQL Server インスタンスにデータを移行する方法について説明します。スキーマ移行、完全データ移行、増分データ移行を柔軟に設定できます。これら 3 つの移行タイプを一緒に設定すると、サービスを中断することなくデータを移行できます。

    前提条件

    宛先 ApsaraDB RDS for SQL Server インスタンスを作成済みであり、そのストレージ容量はソースデータベースよりも大きい必要があります。容量が不足している場合は、事前にインスタンスの容量を増やす必要があります。

    使用上の注意

    移行前に以下の重要な注意事項に注意してください。これらを無視すると、タスクの失敗やエラーが発生する可能性があります。

    • データベース数量の制限: 1 つの移行タスクで移行できるデータベースは 10 個までです。これを超えると、安定性やパフォーマンスのリスクが生じる可能性があります。

    • テーブル数量の制限: 増分移行が含まれる場合、ソースデータベースから同期するテーブルの数は 1000 を超えることはできません。これを超えると、タスクの遅延や不安定さが発生する可能性があります。

    • ソースデータベースの操作制限: スキーマ移行および完全移行の段階では、DDL 操作 (データベースやテーブル構造の変更など) を実行しないでください。実行すると、タスクは失敗します。

    • テーブル構造の要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドには一意性が必要です。そうでない場合、宛先データベースに重複データが出現する可能性があります。

    • 外部キーとトリガー: 移行タスクに増分データ移行が含まれる場合、宛先データベースで有効になっているトリガーと外部キーを無効にする必要があります。そうでない場合、タスクが失敗したり、データが失われたりする可能性があります。

    • データベース名の基準: 移行対象のデータベース名が RDS SQL Server の定義基準に準拠していない場合、事前に RDS SQL Server で手動でデータベースを作成する必要があります。そうでない場合、タスクが正常に実行されない可能性があります。

    • データログの保持期間: 増分移行タスクでは、ソースデータベースのデータログを 24 時間以上保持する必要があります。完全 + 増分移行タスクでは、データログを少なくとも 7 日間保持する必要があります。そうでない場合、タスクが失敗したり、データの不整合が発生したりする可能性があります。

    クリックしてすべての制限と注意事項を展開して表示

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

    • 帯域幅の要件

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

    • テーブル構造の要件

      移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドには一意性が必要です。そうでない場合、宛先データベースに重複データが出現する可能性があります。

    • 移行数量の制限

      • テーブルレベルの移行 (列名マッピングあり): 1 つのタスクでサポートされるテーブルは最大 1000 個です。この制限を超えた場合は、タスクを分割するか、データベースレベルの移行を設定する必要があります。そうでない場合、リクエストエラーが発生します。

      • データベース数量の制限: 1 つのタスクでサポートされるデータベースは最大 10 個です。この制限を超えた場合は、タスクを分割する必要があります。そうでない場合、安定性やパフォーマンスの問題が発生します。

    • 増分移行のログ要件

      • データログを有効にし、バックアップモードを FULL に設定し、関連するバックアップを実行する必要があります。

      • データログの保持期間: 増分移行タスクでは、ソースデータベースのデータログを 24 時間以上保持する必要があります。完全 + 増分移行タスクでは、データログを少なくとも 7 日間保持する必要があります。そうでない場合、タスクが失敗したり、データの不整合が発生したりする可能性があります。

        重要

        DTS が要求する時間よりも短いデータログ保持期間を設定したために問題が発生した場合、そのような状況は DTS サービスレベルアグリーメント (SLA) の対象外となります。

    • CDC 有効化の条件

      ソースデータベースから移行するテーブルに対して CDC を有効にする必要がある場合、以下の条件を満たす必要があります。そうでない場合、事前チェックは失敗します:

      • sys.sysservers ビューの srvname フィールドは、SERVERPROPERTY 関数の戻り値と一致している必要があります。

      • ソースデータベースが自己管理 SQL Server の場合、データベース所有者は sa である必要があります。

      • ソースデータベースのバージョン要件:

        • Enterprise Edition: バージョン 2008 以降である必要があります。

        • Standard Edition: バージョン 2016 SP1 以降である必要があります。

        • SQL Server 2017 バージョン (Standard および Enterprise エディションを含む): バージョンのアップグレードを推奨します。

    • ログのクリーンアップ時間

      DTS は fn_log 関数を介してソースデータベースのログを取得しますが、これにはパフォーマンスのボトルネックがあります。タスクの失敗を避けるために、ソースデータベースのログを早すぎないようにクリーンアップしてください。

    その他の制限

    • サポートされていないデータの型

      CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、および GEOGRAPHY のデータの型の移行はサポートされていません。

    • その他の増分移行の制限

      • インデックスの再構築操作はサポートされていません。そうでない場合、タスクの失敗やデータ損失が発生する可能性があります。CDC が有効になっているテーブルは、プライマリキー関連の変更をサポートしていません。

      • 1 つのタスクで CDC が有効になっているテーブルの数が DTS でサポートされている最大制限を超えると、事前チェックは失敗します。

      • インスタンスに増分タスクが含まれており、CDC テーブルが 64 KB を超える単一フィールドのデータを書き込む必要がある場合、事前に exec sp_configure 'max text repl size', -1; を使用してソースデータベースの構成を調整する必要があります。CDC ジョブの単一フィールドのデフォルトの最大処理長は 64 KB です。

    • 宛先データベースの制限

      増分移行が必要な場合、宛先データベースで有効になっているトリガーと外部キーを無効にする必要があります。そうでない場合、タスクは失敗します。

    • 複数の移行インスタンス

      同じ SQL Server データベースをソースデータベースとして使用する複数の移行インスタンスは、独立した増分データ収集モジュールを持っています。

    • インスタンスの回復

      • インスタンスの実行に失敗した場合、DTS の技術サポート担当者が 8 時間以内に回復を試みます。

      • 回復プロセス中に、インスタンスが再起動されたり、パラメーターが調整されたりすることがありますが、変更されるのはインスタンスのパラメーターのみで、データベースのパラメーターは変更されません。

    注意事項

    • スキーマ移行および完全移行フェーズの注意事項

      • DDL 操作の制限: スキーマ移行および完全移行フェーズ中は、データベースまたはテーブルの構造を変更する DDL 操作は禁止されています。そうしないと、データ移行タスクは失敗します。

      • 読み取り専用インスタンスの制限: ソースデータベースが読み取り専用インスタンスの場合、DDL 操作の移行はサポートされていません。

      • ハイブリッドログ解析モードでの DDL 制限: ソースデータベースは、複数の列の追加/削除操作の連続実行 (時間間隔が 10 分未満) をサポートしていません。たとえば、次の SQL を連続して実行すると、タスクエラーが発生します:

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

    • クロスバージョン移行

      クロスバージョン移行が必要な場合は、事前に互換性を確認してください。

    • ソースデータベースでの DTS 操作

      • 増分同期モードのソースログ解析: DTS は、ソースデータベースにトリガー dts_cdc_sync_ddl、ハートビートテーブル dts_sync_progress、および DDL ストレージテーブル dts_cdc_ddl_history を作成します。

      • ハイブリッド増分同期モード: DTS は、ソースデータベースにトリガー dts_cdc_sync_ddl、ハートビートテーブル dts_sync_progress、および DDL ストレージテーブル dts_cdc_ddl_history を作成します。また、データベースレベルの CDC と部分的なテーブル CDC も有効にします。ソースで CDC が有効になっているテーブルのデータ変更量は、1 秒あたり 1000 レコード (RPS) を超えないようにすることをお勧めします。

    • データ整合性と移行の安定性

      • 完全データ移行中のデータ整合性: 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先のデータに不整合が生じます。リアルタイムの整合性を維持するために、スキーマ移行、完全データ移行、および増分データ移行を選択することをお勧めします。

      • トランザクション処理モードのパラメーター要件: 完全データ移行タスク中に、共有ロックがデータ書き込みに与える影響を避けるため、ソースデータベースのトランザクション処理モードパラメーター READ_COMMITTED_SNAPSHOT が有効になっていることを確認することをお勧めします。そうしないと、データの不整合、インスタンス実行の失敗、その他の異常な状況につながる可能性があります。これによって引き起こされる異常な状況は、DTS SLA の対象外です。

      • タスク回復メカニズム: DTS は、7 日以内に失敗した移行タスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースするか、REVOKE コマンドを使用して宛先インスタンスアカウントへの DTS アクセスの書き込み権限を取り消し、タスクが自動的に回復された後にソースデータが宛先インスタンスのデータを上書きするのを防いでください。

    • パフォーマンスとリソースに関する注意事項

      • 移行前評価: 移行前にソースおよび宛先データベースのパフォーマンスを評価し、ビジネスのオフピーク時に移行を実行することをお勧めします。

      • 移行中のリソース占有: 完全移行中、DTS はソースおよび宛先データベースの読み取りおよび書き込みリソースを占有するため、データベースの負荷が増加する可能性があります。

      • 移行後のストレージ容量の変更: 完全移行が完了した後、同時 INSERT 操作によって断片化が増加するため、宛先データベースのテーブルのストレージ容量がソースデータベースよりも大きくなる場合があります。

    • FLOAT および DOUBLE 列の精度の説明

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

    • データベース名の基準

      移行対象のデータベース名が RDS SQL Server の定義基準に準拠していない場合、事前に RDS SQL Server で手動でデータベースを作成する必要があります。そうでない場合、タスクが正常に実行されない可能性があります。

    課金

    移行タイプ

    インスタンス構成料金

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

    スキーマ移行と完全データ移行

    無料。

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

    増分データ移行

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

    データベースアカウントに必要な権限

    データ移行タスクを正常に完了するには、ソースデータベースと宛先データベースのデータベースアカウントに次の権限があることを確認してください:

    説明

    データベース

    スキーマ移行

    完全移行

    増分移行

    自己管理 SQL Server データベース

    SELECT 権限

    SELECT 権限

    sysadmin

    ApsaraDB RDS for SQL Server インスタンス

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

    準備

    増分移行を実行する必要がある場合、データ移行タスクを正式に設定する前に、自己管理 SQL Server データベースで指定されたデータベースの復旧モードを完全モード (FULL) に設定して、トランザクションログが完全に記録されるようにする必要があります。また、論理バックアップとログバックアップをそれぞれ介して完全データと増分データを保存し、後続のデータ移行の基盤を提供する必要もあります。

    重要

    複数のデータベースを移行する必要がある場合は、準備作業のステップ 1 から 3 を繰り返す必要があります。そうしないと、データの不整合が発生する可能性があります。

    1. 自己管理 SQL Server データベースで次のコマンドを実行して、移行するデータベースの復旧モードを完全モードに変更します。

      use master;
GO
ALTER DATABASE <移行するデータベース名> SET RECOVERY FULL WITH ROLLBACK IMMEDIATE;
GO

      例:

      use master;
GO
ALTER DATABASE mytestdata SET RECOVERY FULL WITH ROLLBACK IMMEDIATE;
GO

    2. 次のコマンドを実行して、移行するデータベースの論理バックアップを実行します。すでに論理バックアップを実行している場合は、このステップをスキップできます。

      BACKUP DATABASE <移行するデータベース名> TO DISK='<バックアップファイルの保存パスとファイル名を指定>';
GO

      例:

      BACKUP DATABASE mytestdata TO DISK='D:\backup\dbdata.bak';
GO

    3. 次のコマンドを実行して、移行するデータベースのログをバックアップします。

      BACKUP LOG <移行するデータベース名> to DISK='<バックアップファイルの保存パスとファイル名を指定>' WITH init;
GO

      例:

      BACKUP LOG mytestdata TO DISK='D:\backup\dblog.bak' WITH init;
GO

    手順

    1. Data Transmission Service (DTS) コンソールにアクセスします。

    2. 左側のナビゲーションウィンドウで、データの移行 をクリックし、上部でリージョンを選択します。

    3. タスクの作成 をクリックし、ソースデータベースと宛先データベースの情報を設定します。

      カテゴリ

      パラメーター

      説明

      N/A

      タスク名

      後で識別しやすいように、ビジネス上の意味を持つ名前を設定します (一意性の要件はありません)。または、システムが生成したタスク名をそのまま使用します。

      ソースデータベース

      既存の接続情報の選択

      DTS データ接続管理ページでソースデータベース情報をすでに入力している場合は、ここで入力済みのデータベースを直接選択でき、後でソースデータベース情報を手動で入力する手間を省けます。

      データベースタイプ

      [SQL Server] を選択します。

      アクセス方法

      [パブリック IP アドレス] を選択します。

      説明

      自己管理データベースを選択する場合、対応する準備も行う必要があります。

      インスタンスリージョン

      自己管理 SQL Server データベースが属するリージョンを選択します。

      ホスト名または IP アドレス

      自己管理 SQL Server データベースのアクセスアドレスを入力します。この例では、パブリック IP アドレスを入力します。

      ポート番号

      自己管理 SQL Server データベースのサービスポートを入力します。デフォルトは 1433 です。

      データベースアカウント

      自己管理 SQL Server のデータベースアカウントを入力します。権限要件については、「データベースアカウントに必要な権限」をご参照ください。

      データベースパスワード

      データベースインスタンスへのアクセスに使用されるパスワード。

      暗号化

      • ソースデータベースで SSL 暗号化が有効になっていない場合は、非暗号化 を選択します。

      • ソースデータベースで SSL 暗号化が有効になっている場合は、SSL 暗号化 を選択すると、DTS はデフォルトでサーバー証明書を信頼します。

      宛先データベース

      既存の接続情報の選択

      DTS データ接続管理ページで宛先データベース情報をすでに入力している場合は、ここで入力済みのデータベースを直接選択でき、後で宛先データベース情報を手動で入力する手間を省けます。

      データベースタイプ

      [SQL Server] を選択します。

      アクセス方法

      [Alibaba Cloud インスタンス] を選択します。

      インスタンスリージョン

      宛先の ApsaraDB RDS for SQL Server インスタンスが属するリージョンを選択します。

      インスタンス ID

      宛先の ApsaraDB RDS for SQL Server インスタンス ID を選択します。

      データベースアカウント

      宛先の ApsaraDB RDS for SQL Server インスタンスのデータベースアカウントを入力します。権限要件については、「データベースアカウントに必要な権限」をご参照ください。

      データベースパスワード

      データベースインスタンスへのアクセスに使用されるパスワード。

      暗号化

      • 宛先データベースで SSL 暗号化が有効になっていない場合は、非暗号化 を選択します。

      • 宛先データベースで SSL 暗号化が有効になっている場合は、SSL 暗号化 を選択すると、DTS はデフォルトでサーバー証明書を信頼します。

    4. 設定が完了したら、ページ下部の 接続をテストして続行 をクリックします。表示される DTS サーバーの CIDR ブロック ダイアログボックスで、接続テスト をクリックします。

      重要

      DTS サービス の IP アドレス範囲をソースデータベースのセキュリティ設定に追加して、DTS サーバーからのアクセスを許可していることを確認してください。

    5. 移行するオブジェクトを設定します。

      1. オブジェクト設定 ページで、移行するオブジェクトを設定します。

        パラメーター

        説明

        移行タイプ

        • 完全データ移行の場合: スキーマ移行 と 完全データ移行 を選択することをお勧めします。

        • ダウンタイムなしの移行の場合: スキーマ移行、完全データ移行、および 増分データ移行 を選択することをお勧めします。

        説明

        • 詳細については、「付録 1: 増分データ移行をサポートする SQL 操作」および「付録 2: スキーマ移行をサポートするオブジェクト」をご参照ください。

        • スキーマ移行 を選択しない場合は、データを受け取るデータベースとテーブルが宛先データベースに存在することを確認してください。ビジネス要件に基づいて、選択中のオブジェクト セクションの列マッピング機能を使用できます。

        • 増分データ移行 を選択しない場合は、データの一貫性を確保するために、データ移行中にソースデータベースに新しいデータを書き込まないでください。

        移行元データベースのトリガーを移行する方法

        必要に応じてトリガーを移行する方法を選択します。移行するオブジェクトにトリガーが含まれていない場合は、このパラメーターを設定する必要はありません。詳細については、「トリガーを同期または移行する方法を設定する」をご参照ください。

        説明

        このパラメーターは、移行タイプ と スキーマ移行 および 増分データ移行 の両方を選択した場合にのみ設定できます。

        SQL Server 増分同期モード

        • クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析)

          制限

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

          • CDC 増分データはデフォルトで 3 日間保持されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行して保持期間を調整することをお勧めします。<time> は分単位で測定されます。ソースデータベースの単一テーブルの増分 SQL 操作の数が 1 日あたり 1,000 万を超える場合は、値を 1440 に設定することをお勧めします。

          • 1 つの移行タスクで最大 1,000 個のテーブルに対して CDC を有効にできます。そうしないと、遅延や不安定さが発生する可能性があります。

          • 増分移行モジュールは、ソースデータベースに対して CDC を有効にします。SQL Server データベースカーネルの制限により、テーブルは一時的にロックされます。

          • DTS は、ソースデータベースに dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DD テーブルを作成します。DTS は、一部のテーブルに対してデータベースレベルの CDC とテーブルレベルの CDC も有効にします。

          • ソースデータベースで CDC が有効になっているテーブルに対して、SELECT INTO、TRUNCATE、または RENAME COLUMN 文を実行することはできません。ソースデータベースで DTS が作成するトリガーを手動で削除することはできません。

          利点

          • このモードは、ソースデータベースのヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、および計算列のあるテーブルをサポートします。

          • このモードは、高いリンク安定性を提供します。完全な DDL 文を取得でき、幅広い DDL シナリオがサポートされます。

        • ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応)

          制限

          • 移行するテーブルにはクラスター化インデックスが必要であり、クラスター化インデックスにはプライマリキー列が含まれている必要があります。

          • このモードは、ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、または計算列のあるテーブルをサポートしていません。次の SQL 文を実行して、ソースデータベースにそのようなテーブルが存在するかどうかを確認できます:

            1. ソースデータベースでヒープテーブルを確認します:

              SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.indexes WHERE index_id = 0);

            2. プライマリキーのないテーブルを確認します:

              SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id NOT IN (SELECT parent_object_id FROM sys.objects WHERE type = 'PK');

            3. ソースデータベースでクラスター化インデックス列に含まれていないプライマリキー列を確認します:

              SELECT s.name schema_name, t.name table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id WHERE t.type = 'U' AND s.name NOT IN('cdc', 'sys') AND t.name NOT IN('systranschemas') AND t.object_id IN ( SELECT pk_colums_counter.object_id AS object_id FROM (select pk_colums.object_id, sum(pk_colums.column_id) column_id_counter from (select sic.object_id object_id, sic.column_id FROM sys.index_columns sic, sys.indexes sis WHERE sic.object_id = sis.object_id AND sic.index_id = sis.index_id AND sis.is_primary_key = 'true') pk_colums group by object_id) pk_colums_counter inner JOIN ( select cluster_colums.object_id, sum(cluster_colums.column_id) column_id_counter from (SELECT sic.object_id object_id, sic.column_id FROM sys.index_columns sic, sys.indexes sis WHERE sic.object_id = sis.object_id AND sic.index_id = sis.index_id AND sis.index_id = 1) cluster_colums group by object_id ) cluster_colums_counter ON pk_colums_counter.object_id = cluster_colums_counter.object_id and pk_colums_counter.column_id_counter != cluster_colums_counter.column_id_counter);

            4. ソースデータベースで圧縮テーブルを確認します:

              SELECT s.name AS schema_name, t.name AS table_name FROM sys.objects t, sys.schemas s, sys.partitions p WHERE s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id = p.object_id AND p.data_compression != 0;

            5. 計算列を含むテーブルを確認します:

              SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.columns WHERE is_computed = 1);

            6. スパース列を含むテーブルを確認します:

              SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.columns WHERE is_sparse = 1);

          利点

          このモードはソースデータベースに侵入しません。

        • 増分同期のための CDC インスタンスのポーリングとクエリ

          制限

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

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

          • 増分移行モジュールは、ソースデータベースに対して CDC を有効にします。SQL Server データベースカーネルの制限により、テーブルは一時的にロックされます。

          • ソースデータベースから移行するテーブルの数は 1,000 を超えることはできません。そうしないと、遅延や不安定さが発生する可能性があります。

          • CDC 増分データはデフォルトで 3 日間保持されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを実行して保持期間を調整することをお勧めします。<time> は分単位で測定されます。単一テーブルの増分 SQL 操作の数が 1 日あたり 1,000 万を超える場合は、値を 1440 に設定することをお勧めします。

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

          • ソースデータベースの CDC インスタンスへの変更はサポートされていません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。

          利点

          • このモードは、ソースデータベースが Amazon RDS for SQL Server、Azure SQL Database、Azure SQL Managed Instance、Azure SQL Server on Virtual Machine、または Google Cloud SQL for SQL Server の場合に、完全データ移行と増分データ移行をサポートします。

          • このモードは、SQL Server のネイティブ CDC コンポーネントを使用して増分データを取得するため、増分移行がより安定し、ネットワーク帯域幅の消費が少なくなります。

        説明

        このパラメーターは、移行タイプ に 増分データ移行 が含まれている場合にのみ使用できます。

        DTS がサポートする CDC が有効になっているテーブルの最大数の制限

        現在の移行インスタンスに対して CDC を有効にできるテーブルの数を適切に設定してください。デフォルト値は 1000 です。

        説明

        SQL Server 増分同期モード が ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定されている場合、この設定項目は表示されません。

        競合するテーブルの処理モード

        • エラーの事前チェックと報告: DTS は、宛先データベースに同じ名前のテーブルが存在するかどうかをチェックします。宛先データベースに同じ名前のテーブルが存在しない場合、事前チェックは合格し、データ移行タスクが開始されます。それ以外の場合、事前チェック中にエラーが返され、データ移行タスクは開始されません。

          解決策: 宛先データベースの同じ名前のテーブルを削除または名前変更できない場合は、オブジェクト名マッピングを設定して、宛先データベースのテーブルの名前を変更できます。

        • エラーを無視して続行: DTS は、宛先データベースの同じ名前のテーブルの事前チェックをスキップします。

          警告

          エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスにリスクが及ぶ可能性があります。例:

          • ソーステーブルと宛先テーブルのスキーマが同じで、宛先テーブルのレコードがソーステーブルのレコードと同じプライマリキー値を持つ場合:

            • 完全データ移行中、DTS は宛先テーブルの既存のレコードを保持し、ソーステーブルから同じプライマリキー値を持つレコードを宛先テーブルに移行しません。

            • 増分データ移行中、宛先テーブルのデータがソーステーブルの新しいデータで上書きされ、宛先テーブルのデータが失われる可能性があります。

          • ソーステーブルと宛先テーブルのスキーマが異なる場合、一部の列しか移行できないか、データ移行タスクが失敗する可能性があります。注意して進めてください。

        ソースオブジェクト

        ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択します。向右小箭头 アイコンをクリックして、オブジェクトを 選択中のオブジェクト セクションに追加します。

        説明

        移行するオブジェクトとして、列、テーブル、またはスキーマを選択できます。移行するオブジェクトとしてテーブルまたは列を選択した場合、DTS はビュー、トリガー、ストアドプロシージャなどの他のオブジェクトを宛先データベースに移行しません。

        選択中のオブジェクト

        • 宛先インスタンスに移行するオブジェクトの名前を変更するには、[選択したオブジェクト] セクションでオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前をマッピングする」をご参照ください。

        • 一度に複数のオブジェクトの名前を変更するには、[選択したオブジェクト] セクションの右上隅にある [一括編集] をクリックします。詳細については、「一度に複数のオブジェクト名をマッピングする」をご参照ください。

        説明

        • オブジェクト名マッピング機能を使用すると、名前が変更されたオブジェクトに依存するオブジェクトの移行が失敗する可能性があります。

        • データをフィルタリングするために WHERE 条件を設定するには、選択中のオブジェクト で移行するテーブルを右クリックし、表示されるダイアログボックスでフィルター条件を設定します。

        • データベースまたはテーブルレベルで移行する SQL 操作を選択するには、選択中のオブジェクト で移行するオブジェクトを右クリックし、表示されるダイアログボックスで移行する SQL 操作を選択します。

      2. 次へ：詳細設定 をクリックして詳細設定を行います。

        パラメーター

        説明

        タスクのスケジュールに使用する専用クラスターの選択

        デフォルトでは、専用クラスターを指定しない場合、DTS はデータ移行タスクを共有クラスターにスケジュールします。データ移行タスクの安定性を向上させたい場合は、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。

        失敗した接続の再試行時間

        失敗した接続のリトライ時間範囲。データ移行タスクが開始された後、ソースまたは宛先データベースへの接続に失敗した場合、DTS はリトライ時間範囲内で直ちに接続をリトライします。有効な値: 10 から 1,440。単位: 分。デフォルト値: 720。パラメーターを 30 より大きい値に設定することをお勧めします。指定されたリトライ時間範囲内に DTS がソースおよび宛先データベースに再接続されると、DTS はデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。

        説明

        • 同じソースまたは宛先データベースを共有する複数のデータ移行タスクに異なるリトライ時間範囲を指定した場合、後で指定された値が優先されます。

        • DTS が接続をリトライする場合、DTS インスタンスに対して課金されます。ビジネス要件に基づいてリトライ時間範囲を指定することをお勧めします。また、ソースデータベースと宛先インスタンスが解放された後、できるだけ早く DTS インスタンスを解放することもできます。

        移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。

        その他の問題のリトライ時間範囲。たとえば、データ移行タスクが開始された後に DDL または DML 操作の実行に失敗した場合、DTS はリトライ時間範囲内で直ちに操作をリトライします。有効な値: 1 から 1440。単位: 分。デフォルト値: 10。パラメーターを 10 より大きい値に設定することをお勧めします。指定されたリトライ時間範囲内に失敗した操作が正常に実行されると、DTS はデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。

        重要

        移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 パラメーターの値は、失敗した接続の再試行時間 パラメーターの値より小さくする必要があります。

        完全移行率を制限するかどうか

        完全データ移行のスロットリングを有効にするかどうかを指定します。完全データ移行中、DTS はソースデータベースと宛先データベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。ビジネス要件に基づいて、完全データ移行のスロットリングを有効にできます。スロットリングを設定するには、1 秒あたりのソースデータベースのクエリ率 QPS、1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS パラメーターを設定する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

        説明

        このパラメーターは、移行タイプ パラメーターで 完全データ移行 を選択した場合にのみ設定できます。

        増分移行率を制限するかどうか

        増分データ移行のスロットリングを有効にするかどうかを指定します。スロットリングを設定するには、1 秒あたりの増分移行の行数 RPS および 1 秒あたりの増分移行データ量 (MB) BPS パラメーターを設定する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

        説明

        このパラメーターは、移行タイプ パラメーターで 増分データ移行 を選択した場合にのみ設定できます。

        環境タグ

        DTS インスタンスを識別するために使用される環境タグ。ビジネス要件に基づいて環境タグを選択できます。この例では、このパラメーターを設定する必要はありません。

        ETL の設定

        ETL (抽出·変換·書き出し) 機能を有効にするかどうかを指定します。詳細については、「ETL とは」をご参照ください。有効な値:

        監視アラート

        データ移行タスクのアラートを設定するかどうかを指定します。タスクが失敗した場合、または移行の遅延が指定されたしきい値を超えた場合、アラート連絡先は通知を受け取ります。有効な値:

        • [いいえ]: アラートを設定しません。

        • [はい]: アラートを設定します。この場合、アラートのしきい値とアラート通知設定も設定する必要があります。詳細については、「モニタリングとアラートの設定」トピックの「DTS タスク作成時のモニタリングとアラートの設定」セクションをご参照ください。

      3. [次のステップ: データ検証] をクリックして、データ検証タスクを設定します。

        データ検証機能の使用方法の詳細については、「データ検証タスクの設定」をご参照ください。

    6. タスク設定を保存して事前チェックを実行します。

      • 関連する API 操作を呼び出して DTS タスクを設定する際に指定するパラメーターを表示するには、次：タスク設定の保存と事前チェック にポインターを合わせ、OpenAPI パラメーターのプレビュー をクリックします。

      • パラメーターを表示する必要がない場合、または表示済みの場合は、ページ下部の 次：タスク設定の保存と事前チェック をクリックします。

      説明

      • データ移行タスクを開始する前に、DTS は事前チェックを実行します。タスクが事前チェックに合格した後にのみ、データ移行タスクを開始できます。

      • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にある [詳細の表示] をクリックします。チェック結果に基づいて原因を分析した後、問題をトラブルシューティングします。その後、再度事前チェックを実行します。

      • 事前チェック中に項目のアラートがトリガーされた場合:

        • アラート項目を無視できない場合は、失敗した項目の横にある [詳細の表示] をクリックして問題をトラブルシューティングします。その後、再度事前チェックを実行します。

        • アラート項目を無視できる場合は、[アラート詳細の確認] をクリックします。[詳細の表示] ダイアログボックスで、[無視] をクリックします。表示されるメッセージで、[OK] をクリックします。その後、[再度事前チェック] をクリックして再度事前チェックを実行します。アラート項目を無視すると、データの不整合が発生し、ビジネスに潜在的なリスクが及ぶ可能性があります。

    7. インスタンスの購入

      1. [成功率] が 100% になるまで待ちます。その後、[次へ: インスタンスの購入] をクリックします。

      2. [インスタンスの購入] ページで、データ移行インスタンスの [インスタンスクラス] パラメーターを設定します。次の表にパラメーターを示します。

        セクション

        パラメーター

        説明

        新しいインスタンスクラス

        リソースグループ

        データ移行インスタンスが属するリソースグループ。デフォルト値: デフォルトリソースグループ。詳細については、「Resource Management とは」をご参照ください。

        インスタンスクラス

        DTS は、移行速度が異なるインスタンスクラスを提供します。ビジネスシナリオに基づいてインスタンスクラスを選択できます。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

      3. チェックボックスをオンにして、[Data Transmission Service (従量課金) サービス規約] を読んで同意します。

      4. [購入して開始] をクリックします。表示されるメッセージで、[OK] をクリックします。

        [データ移行] ページでタスクの進行状況を表示できます。

        説明

        • データ移行タスクを使用して増分データを移行できない場合、タスクは自動的に停止します。[ステータス] セクションに [完了] が表示されます。

        • データ移行タスクを使用して増分データを移行できる場合、タスクは自動的に停止しません。増分データ移行タスクは停止したり完了したりすることはありません。[ステータス] セクションに [実行中] が表示されます。

    付録 1: 増分移行をサポートする SQL 操作

    DML 操作

    INSERT、UPDATE、DELETE

    説明

    UPDATE 操作が大きなフィールドのみを更新する場合、DTS はその操作を移行しません。

    DDL 操作

    • CREATE TABLE

      説明

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

    • ALTER TABLE

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

    • DROP TABLE

    • CREATE INDEX、DROP INDEX

    説明

    • トランザクション DDL 文は移行できません。たとえば、DTS は複数の列に対する DDL 操作を含む SQL 操作や、DDL 操作と DML 操作の両方を含む SQL 操作を移行しません。このような SQL 操作が移行された後、データ損失が発生する可能性があります。

    • DTS は、ユーザー定義型を含む DDL 操作を移行しません。

    • DTS は、オンライン DDL 操作を移行しません。

    • DTS は、予約キーワードを含む名前のオブジェクトに対して実行される DDL 操作を移行しません。

    • DTS は、システムストアドプロシージャで実行される DDL 操作を移行しません。

    • DTS は、TRUNCATE TABLE 操作を移行しません。

    付録 2: 構造移行をサポートするオブジェクト

    • DTS は、テーブル、ビュー、トリガー、シノニム、SQL ストアドプロシージャ、SQL 関数、プランガイド、ユーザー定義型、ルール、デフォルト、およびシーケンスのオブジェクトタイプのスキーマ移行をサポートします。

    • DTS は、アセンブリ、サービスブローカー、フルテキストインデックス、フルテキストカタログ、分散スキーマ、分散関数、共通言語ランタイム (CLR) ストアドプロシージャ、CLR スカラー値関数、CLR テーブル値関数、内部テーブル、システム、または集計関数のスキーマを移行しません。