すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:自己管理 SQL Server データベースから AnalyticDB for PostgreSQL への移行

最終更新日:Feb 07, 2026

Data Transmission Service (DTS) は、自己管理 SQL Server データベースから AnalyticDB for PostgreSQL にデータを移行します。これにより、リアルタイムのデータ分析が容易になります。

前提条件

  • この移行タスクは、新しいコンソールでのみ設定できます。

  • サポートされている自己管理 SQL Server データベースのバージョンについては、「移行ソリューション」をご参照ください。

  • ターゲットの AnalyticDB for PostgreSQL インスタンスを作成済みであること。作成していない場合は、「インスタンスの作成」をご参照ください。

  • ターゲットの AnalyticDB for PostgreSQL インスタンスのストレージ領域は、自己管理 SQL Server データベースが使用するストレージ領域よりも大きい必要があります。

  • ソースインスタンスが次のいずれかの条件を満たす場合は、移行を複数のタスクに分割する必要があります。

    • データベースの数が 10 を超える。

    • 単一のデータベースで 1 時間に 1 回以上ログバックアップが実行される。

    • 単一のデータベースで 1 時間に 100 回以上 DDL 操作が実行される。

    • 単一のデータベースのログボリュームが 20 MB/s を超える。

    • 1,000 を超えるテーブルで変更データキャプチャ (CDC) を有効にする必要がある。

注意事項

説明
  • スキーマ移行中、DTS はソースデータベースからターゲットデータベースに外部キーを移行します。

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

タイプ

説明

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

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

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

  • テーブルレベルのオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。

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

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

  • 増分移行の場合、データログは次の要件を満たす必要があります:

    • ログが有効になっていること。バックアップモードが「完全」に設定されていること。完全物理バックアップが正常に実行されていること。

    • 増分移行タスクの場合、Data Transmission Service (DTS) はソースデータベースのデータログを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースのデータログを少なくとも 7 日間保持することを要求します。完全移行が完了した後、ログの保持期間を 24 時間以上に変更できます。そうしないと、DTS がデータログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、データ不整合やデータ損失が発生する可能性があります。必要な期間より短いログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

  • ソースデータベースから移行するテーブルの変更データキャプチャ (CDC) を有効にするには、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。

    • `sys.sysservers` ビューの `srvname` フィールドの値は、`SERVERPROPERTY` 関数の戻り値と同じである必要があります。

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

    • ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。

    • ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。

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

  • DTS は `fn_log` 関数を使用してソースデータベースのログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログをあまり早くクリアしないでください。そうしないと、DTS タスクが失敗する可能性があります。

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

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

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

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

  • ソースデータベースが Azure SQL Database の場合、1 つの DTS インスタンスで移行できるデータベースは 1 つだけです。

  • ソースデータベースが RDS for SQL Server インスタンスで、移行タスクに増分移行が含まれる場合、DTS インスタンスの安定性を確保するために TDE (透過的データ暗号化) を無効にしてください。詳細については、「TDE の無効化」をご参照ください。

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

    説明

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

  • ハイブリッドログ解析モードでは、10 分未満の間隔でソースデータベースの列を追加または削除する複数の操作を連続して実行することはできません。たとえば、次の SQL 文を連続して実行すると、タスクはエラーを報告します。

    ALTER TABLE test_table DROP COLUMN Flag;
    ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');
  • ソースデータベースが Web Edition の RDS for SQL Server インスタンスの場合、タスクを設定する際に SQL Server 増分同期モードソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定する必要があります。

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

その他の制限

  • 基本データ型のデータのみ移行できます。CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY、および CREATE TYPE コマンドを使用して作成されたユーザー定義データ型のデータは移行できません。

  • 次のタイプのオブジェクトは移行できません:INDEX、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK、INDEX、FULL_TEXT_INDEX、DATATYPE、DEFAULT、SYNONYM、CATALOG、PLAN_GUIDE、DEFAULT_CONSTRAINT、UK、CK、SEQUENCE。

  • 移行するテーブルを選択できます。列マッピングを変更することもできます。非完全テーブル移行に列マッピングを使用する場合、またはソーステーブルとターゲットテーブルのスキーマが一致しない場合、ソーステーブルに存在するがターゲットテーブルに存在しない列のデータは失われます。

  • 追記最適化 (AO) テーブルは、ターゲットテーブルとしてサポートされていません。

  • 移行するテーブルにプライマリキーがある場合、ターゲットテーブルのプライマリキー列はソーステーブルと同じでなければなりません。移行するテーブルにプライマリキーがない場合、ターゲットテーブルのプライマリキー列は分散キーと同じでなければなりません。

  • プライマリキー列を含む一意キーは、分散キーのすべての列を含んでいる必要があります。

  • オブジェクト設定 段階で SQL Server 増分同期モードソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) を選択した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。移行対象のテーブルは、ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、またはスパース列のあるテーブルであってはなりません。混合ログ解析モードでは、これらの制限は適用されません。

  • オブジェクト設定 ステップで SQL Server 増分同期モードクラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) に設定した場合、次の制限も適用されます:

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

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

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

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

    • 単一の移行タスクでは、1,000 を超えるテーブルで CDC を有効にしないことを推奨します。そうしないと、タスクの遅延や不安定さが発生する可能性があります。

    • 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされる可能性があります。

  • オブジェクト設定 ステップで SQL Server 増分同期モード増分同期のための CDC インスタンスのポーリングとクエリ に設定した場合、次の制限も適用されます:

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

      説明
      • Azure SQL Database コンソールが提供する特権アカウント (サーバー管理者) は要件を満たしています。vCore ベースのデータベースの場合、すべてのインスタンスタイプが CDC をサポートします。DTU ベースのデータベースの場合、S3 以降のインスタンスタイプのみが CDC をサポートします。

      • Amazon RDS for SQL Server の特権アカウントは要件を満たしており、ストアドプロシージャのデータベースレベルの CDC を有効にするために使用できます。

      • クラスター化列ストアインデックステーブルは CDC をサポートしていません。

      • 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされる可能性があります。

    • 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 分以内に列を追加または削除する DDL 操作を 2 回以上実行することはできません。そうしないと、タスクが失敗する可能性があります。

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

  • 増分データ移行の遅延の精度を確保するため、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 秒あたり 1,000 レコード (RPS) を超えないようにすることを推奨します。

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

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

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

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

  • 移行タスクに増分データ移行が含まれる場合、インデックスの再作成はできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。

    説明

    CDC が有効になっているテーブルのプライマリキーは変更できません。

  • 単一の移行タスクで CDC が有効になっているテーブルの数が DTS がサポートする CDC が有効になっているテーブルの最大数の制限 の値より大きい場合、事前チェックは失敗します。

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

    説明

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

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

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

    説明

    変更されるのは DTS タスクのパラメーターのみで、データベースのパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれます。

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

特殊なケース

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

課金

移行タイプ

インスタンス構成料金

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

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

無料。

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

増分データ移行

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

移行タイプ

  • スキーマ移行

    DTS は、移行オブジェクトのスキーマ定義をソースデータベースからターゲットデータベースに移行します。

    • サポートされるスキーマオブジェクト:Schema、Table、View、Function、Procedure。

    • サポートされないスキーマオブジェクト:Assemblies、Service Broker、Full-text Index、Full-text Catalog、Distributed Schema、Distributed Function、CLR Stored Procedure、CLR Scalar Function、CLR Table-valued Function、Internal Table、System、Aggregate Function。

    警告

    これは異種データベース移行です。データ型は 1 対 1 でマッピングされません。データ型マッピングがビジネスに与える影響を慎重に評価してください。詳細については、「異種データベース間のデータ型マッピング」をご参照ください。

  • 完全移行

    DTS は、指定された移行オブジェクトのすべての既存データをソースデータベースからターゲットデータベースに移行します。

  • 増分移行

    完全移行が完了した後、DTS はソースデータベースからターゲットデータベースに増分データ更新を移行します。増分移行により、自己管理アプリケーションを中断することなく、データをスムーズに移行できます。

増分移行でサポートされる SQL 操作

操作タイプ

SQL 文

DML

INSERT、UPDATE、DELETE

説明
  • ラージオブジェクト列のみを変更する UPDATE 文はサポートされていません。

  • データがターゲットの AnalyticDB for PostgreSQL インスタンスに書き込まれるとき、UPDATE 文は自動的に REPLACE INTO 文に変換されます。プライマリキーが更新される場合、文は DELETE と INSERT 文に変換されます。

DDL

  • CREATE TABLE

  • ALTER TABLE

    ADD COLUMN と DROP COLUMN のみがサポートされています。

  • DROP TABLE

  • CREATE INDEX、DROP INDEX

説明
  • カスタムデータ型を使用した DDL 操作はサポートされていません。

  • トランザクション DDL 操作はサポートされていません。たとえば、1 つの文で複数の列を追加したり、1 つの文で DDL と DML を混在させたりすると、データ損失が発生する可能性があります。

  • オンライン DDL 操作はサポートされていません。

  • 予約キーワードをプロパティ名として使用する DDL 操作はサポートされていません。

  • システムストアドプロシージャによって実行される DDL 操作はサポートされていません。

  • TRUNCATE TABLE 操作はサポートされていません。

  • 関数を含むパーティションまたはテーブル定義はサポートされていません。

データベースアカウントの権限

データベース

スキーマ移行

完全移行

増分移行

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

SELECT 権限

SELECT 権限

sysadmin

AnalyticDB for PostgreSQL インスタンス

  • LOGIN 権限。

  • ターゲットテーブルに対する SELECT、CREATE、INSERT、UPDATE、DELETE 権限。

  • ターゲットデータベースに対する CONNECT および CREATE 権限。

  • ターゲットスキーマに対する CREATE 権限。

  • COPY 権限 (メモリベースのバッチコピー用)。

説明

AnalyticDB for PostgreSQL の初期アカウントも使用できます。

データベースアカウントの権限を作成および付与するには:

事前準備

説明

増分移行を実行するには、データ移行タスクを設定する前に、自己管理 SQL Server データベースでトランザクションログ設定を行い、クラスター化インデックスを作成してください。

重要

複数のデータベースを移行するには、このセクションのステップ 1 から 3 を繰り返してください。そうしないと、データ不整合が発生する可能性があります。

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

    use master;
    GO
    ALTER DATABASE <database_name> SET RECOVERY FULL WITH ROLLBACK IMMEDIATE;
    GO

    パラメーター:

    <database_name>:移行するデータベースの名前。

    例:

    use master;
    GO
    ALTER DATABASE mytestdata SET RECOVERY FULL WITH ROLLBACK IMMEDIATE;
    GO
  2. 次のコマンドを実行して、移行するデータベースの論理バックアップを実行します。論理バックアップが既に実行されている場合は、このステップをスキップしてください。

    BACKUP DATABASE <database_name> TO DISK='<physical_backup_device_name>';
    GO

    パラメーター:

    • <database_name>:移行するデータベースの名前。

    • <physical_backup_device_name>:バックアップファイルのパスとファイル名。

    例:

    BACKUP DATABASE mytestdata TO DISK='D:\backup\dbdata.bak';
    GO
  3. 次のコマンドを実行して、移行するデータベースのトランザクションログをバックアップします。

    BACKUP LOG <database_name> to DISK='<physical_backup_device_name>' WITH init;
    GO

    パラメーター:

    • <database_name>:移行するデータベースの名前。

    • <physical_backup_device_name>:バックアップファイルのパスとファイル名。

    例:

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

操作手順

  1. 次のいずれかの方法で、ターゲットリージョンの移行タスクリストページに移動します。

    DTS コンソールから

    1. Data Transmission Service (DTS) コンソールにログインします。

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

    3. ページの左上隅で、移行インスタンスが配置されているリージョンを選択します。

    DMS コンソールから

    説明

    実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。詳細については、「シンプルモードコンソール」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。

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

    2. トップメニューバーで、[データ + AI] > [データ転送 (DTS)] > [データ移行] を選択します。

    3. データ移行タスク の右側で、移行インスタンスが配置されているリージョンを選択します。

  2. タスクの作成 をクリックして、タスク設定ページに移動します。

  3. ソースデータベースとターゲットデータベースを設定します。

    警告

    ソースインスタンスとターゲットインスタンスを選択した後、ページの上部に表示される制限を注意深くお読みになることを推奨します。そうしないと、タスクが失敗したり、データ不整合が発生したりする可能性があります。

    カテゴリ

    設定

    説明

    なし

    タスク名

    DTS は自動的にタスク名を生成します。簡単に識別できるように、わかりやすい名前を指定することを推奨します。名前は一意である必要はありません。

    ソースデータベース情報

    データベースタイプ

    [SQL Server] を選択します。

    アクセス方法

    ECS 上の自己管理データベース を選択します。

    説明

    自己管理データベースを選択する場合は、対応する事前準備を完了してください。詳細については、「事前準備の概要」をご参照ください。

    インスタンスリージョン

    自己管理 SQL Server データベースが配置されているリージョンを選択します。

    [ECS インスタンス ID]

    自己管理 SQL Server データベースの ECS インスタンス ID を入力します。

    ポート

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

    データベースアカウント

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

    データベースパスワード

    データベースアカウントのパスワードを入力します。

    暗号化

    ご利用の環境に応じて 非暗号化 または SSL 暗号化 を選択します。

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

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

    ターゲットデータベース情報

    データベースタイプ

    [AnalyticDB PostgreSQL] を選択します。

    アクセス方法

    [クラウドインスタンス] を選択します。

    インスタンスリージョン

    ターゲットの AnalyticDB PostgreSQL インスタンスが配置されているリージョンを選択します。

    [インスタンス ID]

    ターゲットの AnalyticDB PostgreSQL インスタンスのインスタンス ID を選択します。

    データベース名

    ターゲットの AnalyticDB PostgreSQL インスタンスで、移行するオブジェクトを含むデータベースの名前を入力します。

    データベースアカウント

    ターゲットの AnalyticDB PostgreSQL インスタンスのデータベースアカウントを入力します。権限要件については、「データベースアカウントの権限」をご参照ください。

    データベースパスワード

    データベースアカウントのパスワードを入力します。

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

    説明

    DTS サーバーからのアクセスを許可するために、DTS サービスの IP アドレスセグメントがソースデータベースとターゲットデータベースのセキュリティ設定に自動または手動で追加されていることを確認してください。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

  5. タスクオブジェクトを設定します。

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

      設定

      説明

      移行タイプ

      • 完全移行のみを実行する必要がある場合は、スキーマ移行完全データ移行 の両方を選択します。

      • ダウンタイムなしで移行を実行するには、スキーマ移行完全データ移行、および 増分データ移行 を選択します。

      説明
      • スキーマ移行 を選択しない場合は、ターゲットデータベースにデータを受け取るためのデータベースとテーブルが存在することを確認する必要があります。必要に応じて、選択中のオブジェクト ボックスのオブジェクト名マッピング機能も使用できます。

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

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

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

        説明

        ターゲットデータベースのテーブルが同じ名前で、簡単に削除または名前変更できない場合は、ターゲットデータベースのテーブルの名前を変更できます。詳細については、「オブジェクト名マッピング」をご参照ください。

      • エラーを無視して続行:同じ名前のテーブルのチェックをスキップします。

        警告

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

        • テーブルスキーマが一致し、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキー値を持つ場合:

          • 完全移行中、DTS はターゲットデータベースのレコードを保持します。ソースデータベースからのレコードは移行されません。

          • 増分移行中、DTS はターゲットデータベースのレコードを保持しません。ソースデータベースからのレコードがターゲットデータベースのレコードを上書きします。

        • テーブルスキーマが一致しない場合、一部の列のデータのみが移行されるか、移行が失敗する可能性があります。注意して進めてください。

      SQL Server 増分同期モード

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

        • 利点:

          • ソースのヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、または計算列のあるテーブルを含むシナリオをサポートします。

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

        • 欠点:

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

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

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

        • 利点:

          このモードはソースデータベースに対して非侵入型です。

        • 欠点:

          このモードは、ソースのヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、または計算列のあるテーブルを含むシナリオをサポートしません。

      • 増分同期のための 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 を有効にする権限が必要です。増分データ移行には約 10 秒の遅延があります。

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

      説明

      この設定は、移行タイプ増分データ移行 が含まれている場合にのみ表示されます。

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

      この移行インスタンスで CDC を有効にできるテーブルの最大数を指定します。デフォルト値は 1,000 です。

      説明

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

      DDL操作とDML操作の同期

      インスタンスレベルで増分移行のための SQL 操作を選択します。サポートされる操作は、「増分移行でサポートされる SQL 操作」に記載されています。

      説明

      データベースまたはテーブルレベルで増分移行のための SQL 操作を選択するには、選択中のオブジェクト ボックスで移行オブジェクトを右クリックし、目的の SQL 操作を選択します。

      ストレージエンジンタイプ

      必要に応じて、ターゲットテーブルのストレージエンジンタイプを選択します。デフォルト値は Beam です。

      説明

      この設定項目は、ターゲットの AnalyticDB for PostgreSQL インスタンスのカーネルバージョンが v7.0.6.6 以降で、移行タイプスキーマ移行 を選択した場合にのみ利用できます。

      ソースオブジェクト

      ソースオブジェクト ボックスで、移行するオブジェクトをクリックし、Right arrow をクリックして 選択中のオブジェクト ボックスに移動します。

      説明

      このシナリオは異種データベース間の移行であるため、移行オブジェクトを選択する粒度はテーブルです。ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに移行されません。

      選択中のオブジェクト

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

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

      説明
      • オブジェクト名マッピングを使用すると、依存オブジェクトの移行が失敗する可能性があります。

      • WHERE 句を使用してデータをフィルタリングするには、[選択したオブジェクト] で移行するテーブルを右クリックし、ダイアログボックスでフィルター条件を設定します。手順については、「フィルター条件の設定」をご参照ください。

      • データベースまたはテーブルレベルで SQL 操作を選択するには、[選択したオブジェクト] で移行オブジェクトを右クリックし、ダイアログボックスで必要な操作を選択します。

    2. 詳細設定へ をクリックして、詳細パラメーターを設定します。

      設定

      説明

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

      デフォルトでは、DTS は共有クラスターでタスクをスケジュールします。選択する必要はありません。より安定したタスクが必要な場合は、専用クラスターを購入して DTS 移行タスクを実行できます。

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

      移行タスクが開始された後、ソースまたはターゲットデータベースへの接続が失敗した場合、DTS はエラーを報告し、直ちに接続のリトライを開始します。デフォルトのリトライ時間は 720 分です。リトライ時間を 10 から 1440 分の範囲でカスタマイズできます。30 分以上に設定することを推奨します。指定された時間内に DTS がソースおよびターゲットデータベースに再接続した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

      説明
      • 同じソースまたはターゲットを共有する複数の DTS インスタンスの場合、ネットワークリトライ時間は最後に作成されたタスクの設定によって決まります。

      • 接続リトライ期間中もタスクは課金されるため、ビジネスニーズに基づいてリトライ時間をカスタマイズするか、ソースおよびターゲットデータベースインスタンスがリリースされた後、できるだけ早く DTS インスタンスをリリースすることを推奨します。

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

      移行タスクが開始された後、DDL または DML の実行例外など、接続以外の問題がソースまたはターゲットデータベースで発生した場合、DTS はエラーを報告し、直ちに操作のリトライを開始します。デフォルトのリトライ時間は 10 分です。リトライ時間を 1 から 1440 分の範囲でカスタマイズできます。10 分以上に設定することを推奨します。指定されたリトライ時間内に関連操作が成功した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

      重要

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

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

      完全移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。必要に応じて、完全移行タスクの速度制限を有効にできます。1 秒あたりのソースデータベースのクエリ率 QPS1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

      説明
      • この設定項目は、移行タイプ完全データ移行 を選択した場合にのみ利用できます。

      • 移行インスタンスの実行後に 完全移行速度を調整することもできます。

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

      必要に応じて、増分移行タスクの速度制限を設定することもできます。1 秒あたりの増分移行の行数 RPS1 秒あたりの増分移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

      説明
      • この設定項目は、移行タイプ増分データ移行 を選択した場合にのみ利用できます。

      • 移行インスタンスの実行後に 増分移行速度を調整することもできます。

      環境タグ

      インスタンスを識別するための環境ラベルを選択します。この例では必須ではありません。

      ETL 機能の設定

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

      監視アラート

      ビジネスニーズに応じて、アラートを設定し、アラート通知を受け取るかどうかを選択します。

      • ×:アラートを設定しません。

      • アラートのしきい値アラート通知を設定してアラートを構成します。移行が失敗した場合や遅延がしきい値を超えた場合、システムはアラート通知を送信します。

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

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

    4. オプション:上記の設定を完了した後、次:データベースおよびテーブルのフィールド設定 をクリックして、ターゲットの AnalyticDB for PostgreSQL に移行するテーブルの タイププライマリキー列の追加、および 配布キー を設定します。

      説明
      • このステップは、移行タイプスキーマ移行 が含まれている場合にのみ表示されます。すべて定義ステータス を選択して設定を変更します。

      • プライマリキー列の追加 は、複数の列からなる複合キーにすることができます。プライマリキー列の追加 から 1 つ以上の列を選択して 配布キー として使用します。詳細については、「データテーブルの管理」および「テーブル分散の定義」をご参照ください。

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

    • API 操作を呼び出す際にこのインスタンスを設定するためのパラメーターを表示するには、次:タスク設定の保存と事前チェック ボタンにポインターを合わせ、表示されるバブルで OpenAPI パラメーターのプレビュー をクリックします。

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

    説明
    • 移行タスクが開始される前に、DTS は事前チェックを実行します。タスクは事前チェックに合格した後にのみ開始されます。

    • 事前チェックが失敗した場合は、失敗したチェック項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行します。

    • 事前チェック中に警告が報告された場合:

      • 無視できないチェック項目については、失敗した項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行します。

      • 無視できるチェック項目については、アラートの詳細を確認無視OK、および 再度事前チェックを実行 をクリックして、警告項目をスキップし、再度事前チェックを実行できます。警告を無視することを選択した場合、データ不整合などの問題が発生し、ビジネスにリスクをもたらす可能性があります。

  7. インスタンスを購入します。

    1. 成功率 が 100% になったら、次:インスタンスの購入 をクリックします。

    2. 購入 ページで、データ移行インスタンスのリンク仕様を選択します。詳細については、次の表をご参照ください。

      カテゴリ

      パラメーター

      説明

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

      リソースグループの設定

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

      インスタンスクラス

      DTS は、さまざまなパフォーマンスレベルの移行仕様を提供します。リンク仕様は移行速度に影響します。ビジネスシナリオに基づいて仕様を選択できます。詳細については、「データ移行リンク仕様」をご参照ください。

    3. 設定が完了したら、Data Transmission Service (従量課金) 利用規約 を読み、選択します。

    4. 購入して起動 をクリックします。表示される OK ダイアログボックスで、[OK] をクリックします。

      データ移行タスク リストページで移行タスクの進捗状況を確認できます。

      説明
      • 移行タスクに増分移行が含まれていない場合、完全移行が完了すると自動的に停止します。タスクが停止すると、その ステータス完了 に変わります。

      • 移行タスクに増分移行が含まれている場合、自動的に停止しません。増分移行タスクは実行を続けます。増分移行タスクの実行中、タスクの ステータス実行中 です。