Data Transmission Service:ApsaraDB RDS for SQL Server インスタンスから AnalyticDB for PostgreSQL インスタンスへのデータ移行

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

• ソースデータベースをホストするサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると、移行速度が低下します。

• 移行対象のテーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約 (UNIQUE constraint) が設定されている必要があります。これらの制約がないテーブルは、宛先で重複レコードを生成する可能性があります。

• データベース全体ではなく個別のテーブルを移行する場合、1 つのタスクで最大 1,000 テーブルまでサポートされます。この上限を超えるとリクエストエラーが発生します。複数のタスクを構成するか、代わりにデータベース全体を移行してください。

• 1 つのタスクで最大 10 個のデータベースを移行できます。1 つのタスクで 10 個を超えるデータベースを移行すると、パフォーマンスおよび安定性が低下する可能性があります。

• ソースが読み取り専用インスタンスの場合、DDL 操作は移行できません。

増分移行の要件

増分データ移行を使用するには、ソースデータベースが以下の要件を満たしている必要があります。

• データログが有効化されており、バックアップモードが フル に設定され、フル物理バックアップが実行済みであること。

• ログ保持期間：ログが利用できない場合、DTS はそれらを読み取ることができず、タスクが失敗します。場合によっては、データの不整合または損失が発生する可能性があります。完全移行が完了した後、保持期間を 24 時間より長く設定できます。ただし、このログ保持要件を満たさないタスクについては、DTS のサービスレベルアグリーメント (SLA) は適用されません。

  • 増分移行のみの場合：24 時間より長い期間

  • 完全移行＋増分移行の場合：最低 7 日間

• タスクが完了する前にログをクリアしないでください。DTS は fn_log 関数を使用してログを読み取りますが、タスク実行中にログをクリアするとタスクが失敗します。

CDC の前提条件

CDC をソーステーブルに対して有効化する必要がある場合、タスク開始前に以下の条件を確認してください。これらの条件を満たさないと、事前チェックが失敗します。

• srvname フィールドの値が sys.sysservers ビュー内で、SERVERPROPERTY 関数の戻り値と一致すること。

• 自己管理 SQL Server データベースでは、データベース所有者は sa ユーザーである必要があります。ApsaraDB RDS for SQL Server データベースでは、データベース所有者は sqlsa ユーザーである必要があります。

• Enterprise Edition の場合：SQL Server 2008 以降が必要です。

• Standard Edition の場合：SQL Server 2016 SP1 以降が必要です。

• ソースが SQL Server 2017（Standard または Enterprise Edition）を実行している場合、既知の問題を回避するために、より新しいバージョンへ更新してください。

データ型の制限事項

以下のデータ型は移行されません：CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY。

その他の制限事項

• 宛先テーブルは、追加最適化 (AO) テーブルであってはなりません。

• スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL ステートメントを実行しないでください。これを実行すると、移行タスクが失敗します。

• 完全なデータ移行のみ（増分移行なし）を実行する場合、移行中はソースデータベースへのデータ書き込みを行わないでください。同時書き込みにより、ソースと宛先の間でデータの不整合が発生します。

• 完全なデータ移行中の同時 INSERT 操作により、宛先でテーブルの断片化が発生します。完全移行が完了した後、宛先の表領域はソースよりも大きくなります。

• 非完全テーブル移行で列マッピングを使用する場合、またはソースと宛先のテーブルスキーマが異なる場合、宛先に該当する列がないソースの列は失われます。

• DTS は、失敗したタスクを最大 7 日間再開しようと試みます。ワークロードを宛先へ切り替える前に、失敗したタスクを停止またはリリースするか、宛先データベース上の DTS アカウントに対する書き込み権限を REVOKE ステートメントで取り消してください。そうしないと、再開されたタスクが宛先データをソースデータで上書きします。

• タスクに増分移行が含まれる場合、インデックスの再作成 (reindexing) は許可されません。実行すると、タスクが失敗し、データ損失が発生する可能性があります。

• FLOAT または DOUBLE 列については、精度設定が要件を満たしていることを確認してください。DTS は ROUND(COLUMN,PRECISION) を使用して値を取得します：FLOAT のデフォルト精度は 38 桁、DOUBLE のデフォルト精度は 308 桁です。

• DTS は、CDC が有効化されたテーブルのプライマリキーに関する DDL 操作は移行しません。

• 1 つの移行タスクで CDC が有効化されたテーブルの数が 1,000 を超えると、事前チェックが失敗します。

増分同期モード別の制限事項

ソースデータベースのログに基づく増分同期（ヒープテーブルはサポートされません）

• ソースデータベースの設定を変更しません。

• ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列を含むテーブルはサポートされません。すべてのテーブルには、プライマリキー列を含むクラスター化インデックスが必要です。テーブルにこれらのいずれかのタイプが含まれる場合は、代わりにハイブリッドログベース解析モードを使用してください。

• ソースが SQL Server Web Edition を実行している場合、このモードが必須です。タスク構成時に、SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期（ヒープテーブルはサポートされません） に設定してください。

ヒープでないテーブル向けのログベース解析およびヒープテーブル向けの CDC ベース増分同期（ハイブリッドログベース解析）

• ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、および計算列を含むテーブルをサポートします。より高い安定性と、より広範な DDL ステートメントセットを提供します。

• DTS は、ソースデータベース内に以下のオブジェクトを作成します：トリガー dts_cdc_sync_ddl、ハートビートテーブル dts_sync_progress、DDL 履歴テーブル dts_cdc_ddl_history。また、ソースデータベースおよび特定のテーブルに対して CDC を有効化します。

• CDC が有効化されたテーブルに対して SELECT INTO または TRUNCATE を実行することはできません。DTS が作成したトリガーは手動で削除できません。

• 10 分以内に複数回の ADD COLUMN または DROP COLUMN 操作を実行することはできません。たとえば、以下の操作を 10 分以内に連続して実行するとエラーになります。

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) NOT NULL DEFAULT('');

• CDC が有効化されたテーブルの最大書き込みレートは、1 秒あたり 1,000 レコードに設定することを推奨します。

• ソースデータベース内の CDC ジョブが正常に実行されていることを確認してください。失敗すると、DTS タスクも失敗します。

CDC インスタンスのポーリングおよびクエリによる増分同期

• サポートされるソースデータベース：Amazon RDS SQL Server、Azure SQL Database、Google Cloud SQL for SQL Server。

• SQL Server のネイティブ CDC コンポーネントを使用します。増分移行はより安定しており、ネットワーク帯域幅の消費量が少ないです。

• ソースデータベースに使用する DTS アカウントには、CDC を有効化する権限が必要です。

  • データベースレベルの CDC を有効化するには：sysadmin ロールが割り当てられたアカウントを使用してください。

  • テーブルレベルの CDC を有効化するには：特権アカウントを使用してください。

  説明

  • Microsoft Azure SQL Database のサーバー管理者アカウントには必要な権限があります。vCore モデルに基づいて購入した Azure SQL Database のすべてのデータベースで、CDC を有効化できます。DTU（Database Transaction Unit）モデルに基づくデータベースでは、S3 以上のサービスティアが必要です。

  • Amazon RDS for SQL Server の特権アカウントには必要な権限があります。データベースレベルでストアドプロシージャの CDC を有効化できます。

• 増分データ移行の遅延は約 10 秒です。

• 移行対象のテーブル数は 1,000 を超えてはなりません。この上限を超えると、事前チェックが失敗し、遅延または不安定性が発生する可能性があります。

• 1 分間に 2 回を超える列の追加または削除の DDL ステートメントを実行しないでください。この上限を超えると、タスクが失敗する可能性があります。

• 移行中にソースデータベース内の CDC インスタンスを変更しないでください。これを実行すると、タスクが失敗したりデータ損失が発生したりする可能性があります。

ソース RDS インスタンス上の DTS アカウント

ソースが ApsaraDB RDS for SQL Server インスタンスの場合、DTS はそのインスタンス上に rdsdt_dtsacct という名前のアカウントを自動的に作成します。移行タスクが実行中の間は、このアカウントを削除したり、パスワードを変更したりしないでください。そうすると、タスクが失敗します。詳細については、「システム アカウント」をご参照ください。

外部キーの動作

• DTS は、スキーマ移行時に外部キーを移行します。

• 完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キーの制約チェックおよびカスケード操作を一時的に無効化します。移行中にソースでカスケード UPDATE または DELETE 操作を実行すると、データの不整合が発生する可能性があります。

ステップ 1：データ移行タスクページへ移動

1. Data Management (DMS) コンソール にログインします。

2. トップナビゲーションバーで、DTS の上にポインターを合わせます。

3. DTS (DTS) > データ移行 を選択します。

ステップ 2：リージョンの選択およびタスクの作成

1. データ移行タスク の右側にあるドロップダウンリストから、データ移行インスタンスが配置されているリージョンを選択します。

   説明

   新規 DTS コンソールでは、左上隅のリージョンを選択します。

2. タスクの作成 をクリックします。

ステップ 3：ソースおよび宛先データベースの構成

[タスクの作成] ページで、以下のパラメーターを構成します。

ステップ 4：接続性のテスト

接続性のテストと続行 をクリックします。

DTS は、Alibaba Cloud データベースインスタンスの IP アドレスホワイトリストおよび ECS でホストされるデータベースのセキュリティグループルールに、自動的に自サーバーの CIDR ブロックを追加します。データセンターやサードパーティのクラウドにデプロイされた自己管理データベースの場合は、手動で DTS サーバーの CIDR ブロックをデータベースのホワイトリストに追加する必要があります。詳細については、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。

ステップ 5：オブジェクトおよび移行設定の構成

以下のパラメーターを構成します。

パラメーター	説明
移行タイプ	ご使用のシナリオに応じて移行タイプを選択します：一度限りの移行の場合は スキーマ移行 ＋ 完全なデータ移行、移行中の継続的同期の場合は スキーマ移行 ＋ 完全なデータ移行 ＋ 増分データ移行。もし 増分データ移行 を選択しない場合、データ整合性を確保するため、移行中はソースデータベースへのデータ書き込みを行わないでください。
SQL Server 増分同期モード	ソースデータベースに適合するモードを選択します。「増分同期モード別の制限事項」で各モードの要件および制約について詳しくご確認ください。このパラメーターは、完全なデータ移行 が選択されている場合にのみ表示されます。
同期対象の DDL および DML 操作	インスタンスレベルで移行する SQL 操作です。「増分移行でサポートされる SQL 操作」をご参照ください。特定のデータベースまたはテーブルに対して操作を選択するには、選択済みオブジェクト 内のオブジェクトを右クリックします。
競合するテーブルの処理モード	事前チェックおよびエラー報告：宛先にソーステーブルと同じ名前のテーブルがある場合、事前チェックが失敗します。競合を解決するには、オブジェクト名マッピングを使用してください。エラーを無視して続行：チェックをスキップします。完全移行中は、DTS が競合するレコードをスキップし、既存の宛先データを保持します。増分移行中は、DTS が競合するレコードを上書きします。注意して使用してください。
宛先インスタンスにおけるオブジェクト名の大文字小文字の扱い	宛先におけるデータベース名、テーブル名、列名の大文字小文字の扱いを制御します。デフォルトは DTS デフォルトポリシー宛先インスタンスにおけるオブジェクト名の大文字/小文字の指定 です。「」をご参照ください。
ソースオブジェクト	移行対象のオブジェクトを選択し、 をクリックして 選択済みオブジェクト に追加します。この異種データベース間移行シナリオでは、テーブルのみが移行可能です。ビュー、トリガー、ストアドプロシージャは宛先へ移行されません。
選択済みオブジェクト	移行済みオブジェクトの名前を変更するには、そのオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前をマップする」をご参照ください。複数のオブジェクトを一度に名前変更するには、[一括編集] をクリックします。詳細については、「複数のオブジェクト名を一度にマップする」をご参照ください。WHERE 条件を使用して行をフィルターするには、テーブルを右クリックし、条件を指定します。詳細については、「フィルター条件を指定する」をご参照ください。

ステップ 6：高度な設定の構成

次へ：高度な設定 をクリックし、以下の設定を構成します。

データ検証設定

移行後のデータ検証を有効化するには、「データ検証タスクの設定」をご参照ください。

高度な設定

ステップ 7（任意）：データベースおよびテーブルフィールドの構成

次へ：データベースおよびテーブルフィールドの構成 をクリックして、AnalyticDB for PostgreSQL へ移行されるテーブルの タイプ、プライマリキー列、および ディストリビューションキー を設定します。

ステップ 8：設定の保存および事前チェックの実行

次へ：タスク設定の保存および事前チェック をクリックします。

DTS は、移行タスクを開始する前に事前チェックを実行します。事前チェックが成功した場合にのみ、タスクが開始されます。

• いずれかの項目が失敗した場合、その項目の横にある 詳細の表示 をクリックして問題を解決し、その後 再チェック をクリックします。

• アラートがトリガーされた場合：

  • 無視できないアラートの場合は、問題を修正して再チェックを実行してください。

  • 無視できるアラートの場合は、アラート詳細の確認 をクリックし、ダイアログボックスで 無視 をクリックして OK をクリックして確認します。その後、再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 9：インスタンスの購入

成功率 が 100% になるまで待機し、その後 次へ：インスタンスの購入 をクリックします。

[インスタンスの購入] ページで、以下の設定を構成します。

ステップ 10：タスクの開始

1. Data Transmission Service（従量課金）サービス利用規約 を読み、チェックボックスをオンにして承諾します。

2. 購入および開始 をクリックし、ダイアログボックスで OK をクリックします。

タスクはタスクリストに表示されます。そこで進行状況を監視できます。