Data Transmission Service (DTS) を使用して、自己管理 SQL Server データベースから ApsaraDB RDS for SQL Server にデータを移行します。DTS は、スキーマ移行、完全なデータ移行、増分データ移行をサポートしています。これら 3 つを組み合わせることで、ダウンタイムを最小限に抑えた移行が可能です。
データ移行のプロセス
オブジェクト間の依存関係を解決し、移行の成功率を高めるため、DTS は次の順序で SQL Server の構造とデータを移行します。
-
テーブル、ビュー、シノニム、ユーザー定義型、ルール、デフォルト、プランガイドの構造を移行します。
-
完全なデータ移行を実行します。
-
SQL ストアドプロシージャ、SQL 関数、トリガー、外部キーの構造を移行します。
-
増分データ移行を実行します。
課金
| 移行タイプ | インスタンス構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行 + 完全なデータ移行 | 無料 | [アクセス方法] が [パブリック IP アドレス] に設定されている場合に課金されます。詳細については、「課金概要」をご参照ください。 |
| 増分データ移行 | 課金されます。「課金概要」をご参照ください。 | — |
増分移行のためのソースデータベースの準備
完全移行のみを行う場合は、このセクションをスキップしてください。
複数のデータベースを移行する場合は、各データベースに対してステップ 1~3 を繰り返します。
-
復旧モデルを FULL に設定します。
use master; GO ALTER DATABASE <database_name> SET RECOVERY FULL WITH ROLLBACK IMMEDIATE; GO例:
use master; GO ALTER DATABASE mytestdata SET RECOVERY FULL WITH ROLLBACK IMMEDIATE; GO -
完全バックアップを実行します (すでに行っている場合はスキップします)。
BACKUP DATABASE <database_name> TO DISK='<backup_file_path>'; GO例:
BACKUP DATABASE mytestdata TO DISK='D:\backup\dbdata.bak'; GO -
トランザクションログをバックアップします。
BACKUP LOG <database_name> TO DISK='<backup_file_path>' WITH init; GO例:
BACKUP LOG mytestdata TO DISK='D:\backup\dblog.bak' WITH init; GO
移行タスクの作成と設定
-
DTS コンソールに移動します。
-
左側のナビゲーションウィンドウで [データ移行] をクリックし、上部でリージョンを選択します。
-
[タスクの作成] をクリックします。ソースデータベースとターゲットデータベースの接続情報を設定します。
ソースデータベース:
パラメーター 説明 タスク名 識別しやすいように、わかりやすい名前を入力します。一意である必要はありません。 既存の接続を選択 DTS データ接続管理ページでこのソースデータベースを保存している場合は、ここで選択すると手動入力をスキップできます。 データベースタイプ [SQL Server] を選択します。 アクセス方法 [パブリック IP アドレス] を選択します。自己管理データベースに必要な追加手順については、「準備の概要」をご参照ください。 インスタンスリージョン 自己管理 SQL Server データベースのリージョンを選択します。 ホスト名または IP アドレス 自己管理 SQL Server データベースのパブリック IP アドレスを入力します。 ポート番号 サービスポートを入力します。デフォルトは 1433 です。 データベースアカウント ソースデータベースのアカウントを入力します。詳細については、「必要な権限」をご参照ください。 データベースのパスワード データベースアカウントのパスワードを入力します。 暗号化 SSL が有効でない場合は [暗号化なし] を選択します。SSL が有効な場合は [SSL 暗号化] を選択します。DTS はデフォルトでサーバー証明書を信頼します。 ターゲットデータベース:
パラメーター 説明 既存の接続を選択 DTS データ接続管理ページでこのターゲットデータベースを保存している場合は、ここで選択すると手動入力をスキップできます。 データベースタイプ [SQL Server] を選択します。 アクセス方法 [Alibaba Cloud インスタンス] を選択します。 インスタンスリージョン ターゲットの ApsaraDB RDS for SQL Server インスタンスのリージョンを選択します。 インスタンス ID ターゲットインスタンスの ID を選択します。 データベースアカウント ターゲットデータベースのアカウントを入力します。詳細については、「必要な権限」をご参照ください。 データベースのパスワード データベースアカウントのパスワードを入力します。 暗号化 SSL が有効でない場合は [暗号化なし] を選択します。SSL が有効な場合は [SSL 暗号化] を選択します。DTS はデフォルトでサーバー証明書を信頼します。 -
[接続テストと次へ] をクリックします。[DTS サーバーの CIDR ブロック] ダイアログボックスで、[接続テスト] をクリックします。
重要テストの前に、DTS サーバーの IP アドレス範囲をソースデータベースのセキュリティ設定に追加してください。そうしないと、接続テストは失敗します。
-
移行するオブジェクトを設定します。ソースデータベースにソースログ解析モードと互換性のないテーブルがあるかどうかを確認するには、次の SQL ステートメントを実行します:ヒープテーブルの確認:
-
[次のステップ: データ検証] をクリックすると、オプションでデータ検証タスクを設定できます。詳細については、「データ検証タスクを設定する」をご参照ください。
パラメーター 説明 移行タイプ アプローチに基づいてタイプを選択します (「移行アプローチの選択」をご参照ください)。サポートされている操作については、「付録 1」および「付録 2」をご参照ください。[スキーマ移行] を選択しない場合は、ターゲットデータベースに必要なテーブルとスキーマがすでに含まれていることを確認してください。 ソースデータベースのトリガーを移行する方法 トリガーの処理方法を選択します。[スキーマ移行] と [増分データ移行] の両方が選択されている場合にのみ利用可能です。詳細については、「トリガーの同期または移行方法の設定」をご参照ください。 SQL Server 増分同期モード [増分データ移行] が選択されている場合にのみ利用可能です。以下に説明する 3 つのモードのいずれかを選択します。 増分同期モードのオプション:
モード 制限事項 メリット ハイブリッドログベースの解析 (非ヒープテーブルはログベース、ヒープテーブルは CDC ベース) CDC ジョブが正常に実行される必要があります。CDC データはデフォルトで 3 日間保持されます (1 日あたりの増分操作が 1,000 万を超える単一テーブルの場合は exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>;で調整します。<time>は分単位で、1440 に設定します)。CDC が有効なテーブルは最大 1,000 個です。CDC テーブルではSELECT INTO、TRUNCATE、RENAME COLUMNはサポートされていません。ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列をサポートします。リンクの安定性が高く、幅広い DDL シナリオをサポートします。 ソースログの解析 (ヒープテーブルはサポート対象外) テーブルにはプライマリキー列を含むクラスター化インデックスが必要です。ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列はサポートされていません。 ソースデータベースに侵入しません。 CDC ベースのポーリング ソースアカウントには、データベースレベルの CDC には sysadmin ロール、テーブルレベルの CDC には特権アカウントが必要です。クラスター化列ストアインデックスはサポートされていません。テーブルは最大 1,000 個です。連続した列の追加/削除操作はサポートされていません。 ソースとして Amazon RDS for SQL Server、Azure SQL Database、Azure SQL Managed Instance、Google Cloud SQL for SQL Server をサポートします。ネイティブ CDC を使用して効率的な増分データキャプチャを行います。 パラメーター 説明 DTS がサポートする CDC が有効なテーブルの最大数 この移行インスタンスで CDC が有効なテーブルの最大数を設定します。デフォルト:1,000。ソースログ解析モードを使用している場合は利用できません。 競合するテーブルの処理モード 事前チェックしてエラーを報告:DTS はターゲットデータベースに同じ名前のテーブルがあるかチェックします。見つかった場合、事前チェックは失敗し、移行は開始されません。競合するターゲットテーブルの名前を変更するか、オブジェクト名マッピングを使用して解決します。エラーを無視して続行:DTS は同名チェックをスキップします。完全移行中、ターゲットの既存のレコードは保持され、競合するソースのレコードはスキップされます。増分移行中、ターゲットのレコードが上書きされる可能性があります。注意して使用してください。 ソースオブジェクト オブジェクトを選択し、右矢印アイコンをクリックして [選択したオブジェクト] に移動します。列、テーブル、またはスキーマを選択できます。テーブルまたは列を選択すると、ビュー、トリガー、ストアドプロシージャは除外されます。 選択したオブジェクト オブジェクトを右クリックすると、名前を変更したり (詳細は「単一オブジェクトの名前をマッピングする」をご参照ください)、データフィルタリングのために WHERE 条件を設定したり、特定の SQL 操作を選択したりできます。[一括編集] をクリックすると、一度に複数のオブジェクトの名前を変更できます (詳細は「複数のオブジェクト名を一度にマッピングする」をご参照ください)。オブジェクト名のマッピングにより、依存オブジェクトの移行が失敗する可能性があります。 パラメーター 説明 タスクスケジューリング用の専用クラスター デフォルトでは、DTS は共有クラスターを使用します。より高い安定性を確保するには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。 接続失敗時の再試行時間 接続失敗後に DTS が再試行する時間。有効値:10~1,440 分。デフォルト:720 分。30 分以上に設定してください。複数のタスクが同じソースまたはターゲットデータベースを共有する場合、最後に設定された値が優先されます。再試行中も DTS インスタンスの料金は発生します。 その他の問題での再試行時間 DDL または DML の失敗後に DTS が再試行する時間。有効値:1~1,440 分。デフォルト:10 分。10 分以上に設定してください。[接続失敗時の再試行時間] より短くする必要があります。 完全データ移行の帯域幅調整を有効にする [ソースデータベースへの 1 秒あたりのクエリ数 (QPS)]、[完全データ移行の RPS]、および [完全移行のデータ移行速度 (MB/秒)] を設定することで、完全移行の読み取り/書き込みをスロットリングし、データベースの負荷を軽減します。[完全データ移行] が選択されている場合にのみ使用できます。 増分データ移行の帯域幅調整を有効にする 増分移行を調整します。[増分データ移行の RPS] と [増分移行のデータ移行速度 (MB/s)] を設定します。[増分データ移行] が選択されている場合にのみ利用可能です。 環境タグ 識別のために DTS インスタンスにタグを付けます。オプションです。 ETL の設定 抽出・変換・書き出し (ETL) 機能を有効にすると、移行中にデータを変換できます。詳細については、「ETL とは」および「ETL の設定」をご参照ください。 モニタリングとアラート タスクの失敗、またはレイテンシーがしきい値を超えた場合のアラートを設定します。 「モニタリングとアラートを設定する」をご参照ください。 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);プライマリキーのないテーブルの確認:
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');プライマリキー列がクラスター化インデックス列に含まれていないテーブルの確認:
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);圧縮テーブルの確認:
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;計算列を持つテーブルの確認:
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);オブジェクトの設定を続行します。
-
-
事前チェックを実行します。[次へ:タスク設定を保存して事前チェック] をクリックします。DTS は移行開始前に事前チェックを実行します。いずれかの項目が失敗した場合:
-
失敗した項目の横にある [詳細を表示] をクリックし、問題をトラブルシューティングしてから、[再度事前チェック] をクリックします。
-
アラート項目が重大でない場合は、[アラート詳細を確認] > [無視] > [OK] > [再度事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
API パラメーターをプレビューするには、[次へ:タスク設定を保存して事前チェック] にカーソルを合わせ、先に進む前に [OpenAPI パラメーターをプレビュー] をクリックします。
-
-
移行インスタンスを購入します。
-
[成功率] が 100% になるのを待ってから、[次へ:インスタンスの購入] をクリックします。
-
[インスタンスの購入] ページで、インスタンスクラスを設定します。
パラメーター 説明 リソースグループ 移行インスタンスのリソースグループ。デフォルト:デフォルトリソースグループResource Management とは インスタンスクラス 必要な移行速度に基づいてクラスを選択します。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。 -
チェックボックスを選択して、Data Transmission Service (従量課金) 利用規約に同意します。
-
[購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。
-
[データ移行] ページで移行の進捗を監視します。
-
完全のみの移行タスクは、完了すると自動的に停止します。ステータスは [完了] と表示されます。
-
増分移行タスクは継続的に実行され、自動的には停止しません。ステータスは [実行中] と表示されます。
トラフィックのターゲットインスタンスへの切り替え
ターゲットのデータがソースと一致することを確認した後:
-
ソースデータベースへの書き込みを停止します。
-
増分移行が追いつくのを待ちます (遅延がゼロに近づきます)。
-
自動回復によってターゲットデータが上書きされるのを防ぐため、DTS 移行タスクを停止またはリリースします。
-
アプリケーションの接続文字列を更新して、ターゲットの ApsaraDB RDS for SQL Server インスタンスを指すようにします。
完全なデータ移行中に共有ロックが書き込み操作に影響を与えるのを防ぐため、ソースデータベースで READ_COMMITTED_SNAPSHOT を有効にすることを推奨します。そうしないと、データの不整合、インスタンス実行の失敗、その他の異常な状況につながる可能性があります。これを有効にしなかったことによる障害は、DTS SLA の対象外です。
同時 INSERT 操作による断片化のため、完全移行完了後のターゲットのテーブルのストレージ容量は、ソースよりも大きくなる場合があります。
付録 1:増分移行でサポートされる SQL 操作
DML 操作
DML 操作:INSERT、UPDATE、DELETE
UPDATE 操作が大きなフィールドのみを変更する場合、DTS はその操作を移行しません。
DDL 操作
DDL 操作:
-
CREATE TABLE— パーティション化されたテーブルと関数を含むテーブルは移行されません。 -
ALTER TABLE— ADD COLUMN と DROP COLUMN のみをサポートします。 -
DROP TABLE -
CREATE INDEX、DROP INDEX
サポートされていない DDL 操作:
-
トランザクション DDL (1 つのステートメントでの複数の列操作または DDL+DML の組み合わせ) — データ損失の原因となる可能性があります。
-
ユーザー定義型を含む DDL 操作。
-
オンライン DDL 操作。
-
名前に予約キーワードを含むオブジェクトに対する DDL 操作。
-
システムストアドプロシージャで実行される DDL。
-
TRUNCATE TABLE
付録 2:スキーマ移行でサポートされるオブジェクト
サポートされているオブジェクトタイプ:テーブル、ビュー、トリガー、シノニム、SQL ストアドプロシージャ、SQL 関数、プランガイド、ユーザー定義型、ルール、デフォルト、シーケンス。
サポートされていないオブジェクト:アセンブリ、サービスブローカー、フルテキストインデックス、フルテキストカタログ、分散スキーマ、分散関数、CLR ストアドプロシージャ、CLR スカラー値関数、CLR テーブル値関数、内部テーブル、システムテーブル、集計関数。