Data Transmission Service:AWS から RDS for SQL Server への SQL Server の移行

種別

説明

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

• ソースデータベースのバージョンには以下の制限があります：

  • ソースデータベースが Enterprise Edition インスタンスの場合、バージョンは 2008 以降である必要があります。

  • ソースデータベースが Standard Edition インスタンスの場合、バージョンは 2016 SP1 以降である必要があります。

  • ソースデータベースが SQL Server 2017 インスタンス（Standard Edition または Enterprise Edition）の場合、インスタンスをアップグレードしてください。

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

• 移行対象のテーブルにはプライマリキーまたは一意制約（UNIQUE constraint）が設定されており、フィールド値が一意である必要があります。そうでない場合、ターゲットデータベースに重複データが発生する可能性があります。

• 単一のデータ移行タスクでは、最大 10 個のデータベースをサポートします。この上限を超えると、安定性およびパフォーマンスの問題が発生する可能性があります。その場合は、データベースを複数の移行タスクに分割してください。

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

• 増分移行タスクでは、DTS がソースデータベースのデータログを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクでは、DTS がソースデータベースのデータログを最低 7 日間保持することを要求します。完全移行完了後にログ保持期間を 24 時間以上に変更できます。それ以外の場合、DTS がデータログを取得できないため、DTS タスクが失敗する可能性があります。極端なケースでは、データ不整合やデータ損失が発生する可能性があります。ログ保持期間が所定の期間より短いことによって引き起こされる問題は、DTS の SLA の対象外となります。

• ソースデータベースの操作制限：

  • 初期スキーマ同期および完全なデータ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。

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

• 読み取り専用インスタンスは、ソースデータベースとしてサポートされていません。

• 初期スキーマ同期タスクの実行前に、ソースデータベースでストアドプロシージャなどのオブジェクトを sp_rename コマンドで名前変更すると、タスクが期待通りに動作しない、または失敗する可能性があります。

  説明

  データベース内のオブジェクトの名前変更には、ALTER コマンドを使用してください。

• 完全なデータ移行中は、ソースデータベースの READ_COMMITTED_SNAPSHOT トランザクション処理モードパラメーターが有効になっていることを確認してください。これにより、共有ロックによるデータ書き込みへの影響を防ぎます。そうでない場合、データ不整合やインスタンス障害などの例外が発生する可能性があります。この問題によって引き起こされる例外は、DTS の SLA の対象外となります。

その他の制限事項

• CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY データ型のデータは移行できません。

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

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

• 増分移行タスクの前提モジュールでは、ソースデータベースに対して CDC を有効化します。この処理中、SQL Server データベースのカーネル制限により、ソースデータベースが一時的にロックされる可能性があります。

• 増分移行タスクでは、CDC インスタンスをポーリングすることで増分データを移行します。したがって、以下の制限が適用されます：

  • DTS は、ソースデータベース内の各テーブルの CDC インスタンスをポーリングして増分データを取得します。したがって、ソースデータベースから 1,000 個を超えるテーブルを同期することはできません。それ以外の場合、タスクの遅延または不安定性が発生する可能性があります。

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

    説明

    • <time> は、分単位の時間を指定します。

    • ソースデータベースの単一テーブルにおける増分変更 SQL 文の 1 日あたりの数が 1,000 万件を超える場合、<time> を 1440 に設定することを推奨します。

  • 列の追加または削除を連続して実行することはできません。たとえば、1 分間に 2 回を超える DDL 操作（列の追加または削除）を実行すると、タスクが失敗する可能性があります。

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

  • 複数のデータベースおよびテーブルを移行するシナリオでは、安定性およびパフォーマンスの問題が発生する可能性があります。

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

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

• 移行タスクに増分データ移行が含まれる場合、再インデックス化は実行できません。また、ターゲットデータベースで有効化されているトリガーおよび外部キーも無効化する必要があります。そうしないと、タスクが失敗したり、データが失われる可能性があります。

  説明

  CDC が有効化されたテーブルのプライマリキーを変更することはできません。

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

• タスクに増分移行が含まれ、CDC が有効化されたテーブルの単一フィールドに書き込むデータが 64 KB を超える場合、事前にソースデータベースの構成を exec sp_configure 'max text repl size', -1; コマンドで調整する必要があります。

  説明

  デフォルトでは、CDC ジョブは単一フィールドの最大長を 64 KB として処理できます。

• DTS は、RDS for SQL Server インスタンス内に自動的にデータベースを作成します。移行対象のデータベース名が 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 を有効化します。ソースデータベースで CDC が有効化されたテーブルのデータ変更率は、1,000 RPS を超えないようにすることを推奨します。

• データ移行を開始する前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。ピーク時間帯を避けてデータ移行を実施することを推奨します。そうしないと、完全なデータ移行中に DTS がソースおよびターゲットデータベースの読み取り・書き込みリソースを消費し、データベースの負荷が増加する可能性があります。

• 完全なデータ移行では、並列 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。したがって、完全なデータ移行完了後、ターゲットデータベースのテーブルストレージ領域は、ソースインスタンスよりも大きくなります。

• DTS が FLOAT または DOUBLE データ型のカラムに対して提供する移行精度が、業務要件を満たすかどうかを確認してください。DTS はこれらのカラムの値を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度を指定しない場合、DTS は FLOAT 値を精度 38、DOUBLE 値を精度 308 で移行します。

• DTS は、失敗した移行タスクを 7 日間以内に再開しようと試みます。したがって、業務をターゲットインスタンスに切り替える前に、タスクを終了または解放するか、revoke コマンドを使用して、DTS がターゲットインスタンスにアクセスするために使用するアカウントの書き込み権限を取り消す必要があります。これにより、タスクが自動的に再開された後にソースデータがターゲットインスタンスのデータを上書きするのを防ぎます。

• 複数の DTS インスタンスが同一の SQL Server データベースをソースとして使用する場合、それらの増分データ取り込みモジュールは相互に独立しています。

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

  説明

  DTS タスクのパラメーターのみが変更され、データベースのパラメーターは変更されません。 調整可能なパラメーターの一覧については、「インスタンスパラメーターの変更」をご参照ください。

• SQL Server は商用のクローズドソースデータベースです。既知または未知のフォーマット固有の制限により、DTS が SQL Server のログに対して CDC および解析を実行する際に問題が発生する可能性があります。したがって、本番環境で SQL Server ソースの増分同期または増分移行を有効化する前に、包括的な概念実証（POC）テストを実施することを推奨します。このテストでは、すべての業務変更タイプ、テーブルスキーマ変更、および業務ピーク時のストレステストをカバーする必要があります。SQL Server のログフォーマットは予測不可能であるため、本番環境の業務ロジックが POC テストのものと一致していることを保証する必要があります。これは、DTS の高効率および高安定性を確保する上で極めて重要です。

移行タイプ

インスタンス構成料金

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

スキーマ移行および完全なデータ移行

無料です。

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

増分データ移行

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

操作タイプ

SQL 文

DML

INSERT、UPDATE、DELETE

DDL

• CREATE TABLE

• ALTER TABLE

  ADD COLUMN および DROP COLUMN のみがサポートされます。

• DROP TABLE

• CREATE INDEX、DROP INDEX

データベース

スキーマ移行

完全移行

増分移行

権限の作成および付与方法

Amazon RDS for SQL Server

SELECT 権限

SELECT 権限

db_owner 権限

具体的な手順については、AWS にお問い合わせください。

RDS for SQL Server インスタンス

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

標準アカウント、特権アカウント、グローバル読み取り専用アカウントの作成 および アカウント権限の変更。