Data Transmission Service:SQL Server データベースの Alibaba Cloud への移行

準備チェックリスト

ソリューションを選択する前に：

1. バージョンの互換性の確認。 移行元と移行先の両方のインスタンスで次のクエリを実行し、移行先の 互換性レベル が移行元以上であることを確認します。

      SELECT name, compatibility_level FROM sys.databases;

2. ネットワークアクセスの確認。 移行元および移行先のデータベースが、DTS サーバーまたは他の移行ツールからの接続を受け付けることを確認します。

3. 移行元データベースの特性の評価。 ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブルを特定します。これらによって、利用可能な DTS のモードが決まります。 テーブルタイプの確認に関する FAQ。

4. 移行元エディションとバージョンの確認。 一部の移行モードでは、特定の SQL Server エディションとバージョンが必要です (詳細は後述の機能マトリックスをご参照ください)。

Object Storage Service (OSS) 経由の物理バックアップ (手動)

完全バックアップと増分バックアップを Object Storage Service (OSS) に手動でアップロードし、移行先インスタンスで復元します。

手順：

1. 移行元データベースで backup_type パラメーターを FULL に設定します。

2. 完全バックアップを作成し、OSS バケットにアップロードします。

3. スケジュールに基づいて増分ログをバックアップし、アップロードします。

4. 移行元データベースへの書き込みを停止します。最後の増分ログが正常にリプレイされた後、ワークロードを移行先に切り替えます。

移行元データベースが SQL Server 2008 R2 を実行している場合は、この操作を実行する前にデータベースのバージョンをアップグレードしてください。

リファレンス： 自己管理型 SQL Server インスタンスから ApsaraDB RDS for SQL Server インスタンスへのデータ移行

データディザスタリカバリと DTS 経由の物理バックアップ

物理ゲートウェイと DTS を使用して、バックアップのアップロードと復元を自動化します。

手順：

1. 物理ゲートウェイをデプロイします。

2. DTS を使用してデータを移行します。システムはバックアップデータを OSS に自動的にアップロードします。

3. 移行元データベースへの書き込みを停止します。最後の増分ログが正常にリプレイされた後、ワークロードを移行先に切り替えます。

リファレンス： 物理ゲートウェイを使用した自己管理型 SQL Server データベースから ApsaraDB RDS for SQL Server インスタンスへのデータ移行

DTS 論理移行：ログ解析モード

DTS は、移行元データベースのトランザクションログを読み取り、解析して変更をキャプチャします。

手順：

1. DTS データ移行タスクを作成します。 SQL Server 増分同期モード パラメーターを [移行元データベースのログに基づく増分同期 (ヒープテーブルはサポートされていません)] に設定します。

2. 移行元データベースへの書き込みを停止します。最後の増分ログが正常にリプレイされた後、ワークロードを移行先に切り替えます。

リファレンス： 自己管理型 SQL Server データベースから ApsaraDB RDS for SQL Server インスタンスへのデータ移行

DTS 論理移行：ハイブリッドログ解析モード

非ヒープテーブルに対するログベースの解析と、ヒープテーブルに対する変更データキャプチャ (CDC) を組み合わせることで、移行可能なテーブルタイプの範囲を拡大します。

手順：

1. DTS データ移行タスクを作成します。 SQL Server 増分同期モード パラメーターを [非ヒープテーブルのログベース解析とヒープテーブルの CDC ベース増分同期 (ハイブリッドログベース解析)] に設定します。

2. 移行元データベースへの書き込みを停止します。最後の増分ログが正常にリプレイされた後、ワークロードを移行先に切り替えます。

DTS 論理移行：CDC インスタンスポーリングモード

トランザクションログではなく、SQL Server のネイティブな CDC コンポーネントを使用して変更テーブルから増分変更をキャプチャします。これにより、ログの切り捨ての影響を受けず、より安定した低帯域幅での移行が可能になります。

手順：

1. DTS データ移行タスクを作成します。 SQL Server 増分同期モード パラメーターを [増分同期のための CDC インスタンスのポーリングとクエリ] に設定します。

2. 移行元データベースへの書き込みを停止します。最後の増分ログが正常にリプレイされた後、ワークロードを移行先に切り替えます。

SSMS 移行

SSMS を使用してデータを手動でエクスポートおよびインポートします。

手順：

1. 移行元データベースへの書き込みを停止します。

2. SSMS を使用して移行元データベースからデータをエクスポートします。

3. エクスポートしたデータを移行先データベースにインポートします。

4. データ整合性を検証した後、ワークロードを移行先に切り替えます。

リファレンス： SSMS を使用したクラウドへのデータ移行

OSS 手動 (物理バックアップ)

• ログの手動バックアップとアップロードが必要です。

• 一度に 1 つのデータベースしか移行できません。

• 最終的なカットオーバー (書き込み停止、最後の増分ログのリプレイ待ち) 中に数分間のサービス中断が発生します。

• 移行先データベースのバージョンは、移行元データベースのバージョンより古くすることはできません。

• データベース、テーブル、列の名前マッピングはサポートされていません。

データディザスタリカバリ + DTS (物理バックアップ)

• バックアップログファイルの拡張子は trn である必要があります。

• 最終的なカットオーバー中に数分間のサービス中断が発生します。

• 移行元データベースサーバーに AliyunDBSAgent をインストールする必要があります。

• 移行先データベースのバージョンは、移行元データベースのバージョンより古くすることはできません。

• データベース、テーブル、列の名前マッピングはサポートされていません。

ログ解析モード (論理)

• 一部の DDL ステートメントのみ移行できます。1 時間あたり 100 を超える DDL ステートメントは、移行速度に影響します。

• 移行元データベースのログ書き込み速度が 10 MB/s、30 GB/時間、または 500 GB/日を超えると、タスクが遅延したり失敗したりする可能性があります。

• ログのバックアップ頻度が 1 時間に 1 回を超えると、DTS がローカルのバックアップログを取得できない場合があります。バックアップログはローカルディスクに 3 日間保持してください。

• DTS は、DDL の変更をキャプチャするために、移行元データベースにトリガーと DDL ストレージテーブルを作成します。

• 増分データ移行中は FOREIGN KEY 制約を無効にしてください。そうしないと、タスクが失敗する可能性があります。

• ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブルは移行できません。 テーブルタイプの確認に関する FAQ。

• PRIMARY KEY または UNIQUE 制約のないテーブルには、重複データが含まれる可能性があります。このようなテーブルを保持する必要がある場合は、このソリューションを使用しないでください。

• DTS は fn_log 関数を使用してログをプルし、解析します。この関数は安定していません。予期しない操作によってタスクが失敗する可能性があります。

• 1 つのデータ移行タスクで移行できるデータベースは最大 10 個です。この制限を超えると、安定性とパフォーマンスの問題が発生する可能性があります。

ハイブリッドログ解析モード (論理)

• 移行元エディション要件： SQL Server 2008 以降 (Enterprise Edition)、または SQL Server 2016 SP1 以降 (Standard Edition)。SQL Server 2017 はサポートされていません。

• 一部の DDL ステートメントのみ移行できます。1 時間あたり 100 を超える DDL ステートメントは、移行速度に影響します。

• 移行元データベースのログ書き込み速度が 10 MB/s、30 GB/時間、または 500 GB/日を超えると、タスクが遅延したり失敗したりする可能性があります。

• ログのバックアップ頻度が 1 時間に 1 回を超えると、DTS がローカルのバックアップログを取得できない場合があります。バックアップログはローカルディスクに 3 日間保持してください。

• DTS はデータベースと一部のテーブルに対して CDC を有効にします。また、DTS は DDL の変更をキャプチャするために、移行元データベースにトリガーと DDL ストレージテーブルを作成します。

• 増分データ移行中は FOREIGN KEY 制約を無効にしてください。そうしないと、タスクが失敗する可能性があります。

• 計算列のあるテーブルは移行できません。 テーブルタイプの確認に関する FAQ。

• PRIMARY KEY または UNIQUE 制約のないテーブルには、重複データが含まれる可能性があります。このようなテーブルを保持する必要がある場合は、このソリューションを使用しないでください。

• DTS は fn_log 関数を使用してログをプルし、解析します。この関数は安定していません。予期しない操作によってタスクが失敗する可能性があります。

• 1 つのデータ移行タスクで移行できるデータベースは最大 10 個です。この制限を超えると、安定性とパフォーマンスの問題が発生する可能性があります。

CDC インスタンスポーリングモード (論理)

• 移行元が Azure VM の場合のエディション要件： SQL Server 2008 以降 (Enterprise Edition)、または SQL Server 2016 SP1 以降 (Standard Edition)。SQL Server 2017 はサポートされていません。

• アカウント権限： DTS アクセスアカウントには、データベースレベルおよびテーブルレベルで CDC を有効にする権限が必要です。データベースレベルの CDC には sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC には特権アカウントが必要です。

  • Azure SQL Database： サーバー管理者アカウントは必要な権限を持っています。vCore モデルで購入したすべてのデータベースで CDC を有効にできます。DTU モデルの場合、データベースのサービス階層は S3 以上である必要があります。

  • Amazon RDS for SQL Server： 特権アカウントは必要な権限を持っています。ストアドプロシージャを使用してデータベースレベルで CDC を有効にできます。

  • クラスター化列ストアインデックスに対して CDC を有効にすることはできません。

  • DTS プレモジュールは移行元データベースで CDC を有効にします。このプロセスは、SQL Server の制限により、数秒間のテーブルロックを引き起こします。

• 1 つのタスクで移行できるテーブルは最大 1,000 です。この制限を超えると、遅延や不安定さが発生する可能性があります。

• 1 つのデータ移行タスクで移行できるデータベースは最大 10 個です。この制限を超えると、安定性とパフォーマンスの問題が発生する可能性があります。

• PRIMARY KEY または UNIQUE 制約のないテーブルには、重複データが含まれる可能性があります。このようなテーブルを保持する必要がある場合、重複データが許容できるかどうかを評価する必要があります。

• 増分データ移行には約 10 秒のレイテンシーがあります。

• 1 分以内に DDL を使用して列を追加または削除する操作を 2 回以上行わないでください。そうしないと、データ移行タスクが失敗する可能性があります。

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

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

SSMS 移行

• 移行を開始する前に、移行元データベースへの書き込みを停止する必要があります。そうしないと、データ不整合が発生する可能性があります。

• すべての移行手順は SSMS を通じて手動で実行する必要があります。

自己管理型 SQL Server

このアプローチは、物理バックアップの速度と DTS コンソールの利便性を組み合わせ、単一タスクでの複数データベースの移行をサポートします。 物理ゲートウェイを使用した自己管理型 SQL Server データベースから ApsaraDB RDS for SQL Server インスタンスへのデータ移行。

Azure SQL Database

どちらも、手動手順を最小限に抑えたガイド付きワークフローを提供します。 Microsoft Azure 上の SQL Server データベースから ApsaraDB RDS for SQL Server へのデータ移行。

Azure SQL Managed Instance および SQL Server on Azure Virtual Machines

Amazon RDS for SQL Server

Amazon RDS for SQL Server インスタンスから ApsaraDB RDS for SQL Server インスタンスへのデータ移行。

Huawei Cloud RDS for SQL Server

自己管理型 SQL Server インスタンスの完全バックアップデータを、SQL Server 2008 R2 (クラウドディスク使用) または SQL Server 2012 以降を実行する ApsaraDB RDS インスタンスに移行する。

• 移行元データベースが SQL Server 2008 R2 を実行している場合は、この操作を実行する前にデータベースのバージョンをアップグレードしてください。

• バックアップデータの取得手順については、手動バックアップの作成およびバックアップファイルのダウンロードをご参照ください。

TencentDB for SQL Server

増分サポートあり：

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

増分サポートなし： SSMS 移行を使用します。

Google Cloud SQL for SQL Server

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

データ整合性の検証

移行後、すべてのデータが移行先インスタンスに正しく転送されたことを確認します。

-- 移行元データベース
SELECT TOP 10 OrderID, OrderDate, CustomerID, TotalAmount
FROM Orders
ORDER BY OrderDate DESC;

-- 移行先データベース
SELECT TOP 10 OrderID, OrderDate, CustomerID, TotalAmount
FROM Orders
ORDER BY OrderDate DESC;

データベース統計の更新

データ分布の変化により、移行先インスタンスでのクエリパフォーマンスが低下する可能性があります。移行したデータベースのすべての統計を更新して、パフォーマンスを回復します。 データベース統計の更新。