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

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

最終更新日:Oct 18, 2024

このトピックでは、data Transmission Service (DTS) を使用して、自己管理型SQL ServerデータベースからAnalyticDB for PostgreSQLインスタンスにデータを移行する方法について説明します。 データ移行機能を使用すると、データを簡単に転送し、リアルタイムでデータを分析できます。

前提条件

  • 新しいDTSコンソールが使用されます。 このシナリオのデータ移行タスクは、新しいDTSコンソールでのみ設定できます。

  • 自己管理型SQL Serverデータベースのバージョンは、DTSでサポートされています。 詳細については、「データ移行」をご参照ください。

  • 移行先のAnalyticDB for PostgreSQLインスタンスが作成されました。 詳細については、「インスタンスの作成」をご参照ください。

  • 移行先のAnalyticDB for PostgreSQLインスタンスの使用可能なストレージ容量は、自己管理型SQL Serverデータベースのデータの合計サイズよりも大きくなっています。

  • ソースApsaraDB RDS for SQL Serverインスタンスが次のいずれかの条件を満たしている場合、移行タスクを複数のサブタスクに分割することを推奨します。

    • ソースインスタンスには10を超えるデータベースが含まれています。

    • ソースインスタンスの1つのデータベースは、1時間未満の間隔でログをバックアップします。

    • ソースインスタンスの1つのデータベースで、1時間に100を超えるDDLステートメントが実行されます。

    • ログは、ソースインスタンスの1つのデータベースに対して20メガバイト/秒の割合で書き込まれます。

    • ソースApsaraDB RDS for SQL Serverインスタンスの1,000を超えるテーブルに対して、変更データキャプチャ (CDC) 機能を有効にする必要があります。

制限事項

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

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

制限タイプ

説明

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

  • ソースデータベースがデプロイされるサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が低下します。

  • 移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 移行するオブジェクトとしてテーブルを選択し、テーブルや列の名前の変更など、移行先データベースのテーブルを編集する必要がある場合は、1つのデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルを移行するか、タスクを構成してデータベース全体を移行することをお勧めします。

  • 単一のデータ移行タスクを実行して、最大10個のデータベースを移行できます。 10を超えるデータベースを移行する場合は、複数のタスクを設定してデータベースを移行することを推奨します。 そうしないと、データ移行タスクのパフォーマンスと安定性が損なわれる可能性があります。

  • 増分データを移行する場合は、次の要件が満たされていることを確認してください。

    • データログ機能を有効にする必要があります。 バックアップモードをFullに設定し、完全物理バックアップを実行する必要があります。

    • 増分データ移行のみを実行する場合は、ソースデータベースのデータログを24時間以上保持する必要があります。 完全データ移行と増分データ移行の両方を実行する場合、ソースデータベースのデータログは少なくとも7日間保持する必要があります。 そうしないと、Data Transmission Service (DTS) がデータログの取得に失敗し、タスクが失敗する可能性があります。 場合によっては、データの不整合や損失が発生することもあります。 完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、データログの保持期間を設定してください。 それ以外の場合、DTSのサービスレベル契約 (SLA) はサービスの信頼性またはパフォーマンスを保証しません。

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

    • sys.sysserversビューのsrvnameフィールドの値は、SERVERPROPERTY関数の戻り値と同じです。

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

    • ソースデータベースがEnterpriseエディションの場合は、SQL Server 2008以降を使用する必要があります。

    • ソースデータベースがStandardエディションの場合は、SQL Server 2016 SP1以降を使用する必要があります。

    • ソースデータベースがStandardまたはEnterpriseエディションで、そのバージョンがSQL Server 2017の場合は、そのバージョンを更新することをお勧めします。

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

  • ソースデータベースに対する操作の制限:

    • スキーマ移行中および完全データ移行中は、DDL文を実行してデータベースまたはテーブルのスキーマを変更しないでください。 それ以外の場合、データ移行タスクは失敗します。

    • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。 そうしないと、ソースデータベースとターゲットデータベース間でデータの不一致が発生します。 データの一貫性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、および増分データ移行を選択することを推奨します。

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

  • ハイブリッドログベースの解析モードでは、複数の操作を実行して、ソースデータベースに列を追加したり、ソースデータベースから列を削除したりすることはできません。 たとえば、次のSQL文を10分以内に実行すると、タスクのエラーが報告されます。

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

その他の制限

  • DTSは、CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、およびGEOGRAPHYのデータタイプを移行しません。

  • 移行するオブジェクトとしてテーブルを選択した場合、列間のマッピング関係を変更できます。 列マッピングが完全でないテーブルの移行に使用されている場合、またはソーステーブルとターゲットテーブルのスキーマに一貫性がない場合、ターゲットデータベースに含まれていないソースデータベースの列のデータが失われます。

  • 宛先テーブルを追加最適化 (AO) テーブルにすることはできません。

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

  • オブジェクト設定 ステップで、SQL Server 増分同期モードパラメーターをクラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) に設定した場合、DTSはCDCコンポーネントを使用して増分データを移行します。 ソースデータベースのCDCジョブが期待どおりに実行されることを確認します。 それ以外の場合、DTSタスクは失敗します。

  • オブジェクト設定 の手順で、SQL Server 増分同期モード パラメーターを 増分同期のための CDC インスタンスのポーリングとクエリ に設定した場合、次の制限が適用されます。

    • DTSインスタンスで使用されるソースデータベースアカウントには、CDC機能を有効にする権限が必要です。 データベースレベルのCDCを有効にするには、sysadminロールが割り当てられているアカウントを使用する必要があります。 テーブルレベルのCDCを有効にするには、特権アカウントを使用する必要があります。

      説明
      • Microsoft Azure SQL Databaseのサーバー管理者アカウントに必要な権限があります。 CDCは、vCoreモデルに基づいてAzure SQL Databaseで購入したすべてのデータベースに対して有効にできます。 データベーストランザクション単位 (DTU) モデルに基づいてAzure SQL Databaseで購入したデータベースに対してCDCを有効にすることができるのは、データベースのサービス層がS3以上の場合のみです。

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

    • DTSは、ソースデータベースの各テーブルのCDCインスタンスに対してラウンドロビンクエリを実行することで、増分データを取得します。 したがって、ソースデータベースから移行するテーブルの数は1,000を超えることはできません。 そうしないと、データ移行タスクが遅延または不安定になる可能性があります。

    • DDLステートメントを実行して、1分以内に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が有効になっているテーブルの1秒あたりの最大レコード数を1,000に設定することを推奨します。

  • データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 完全データ移行中、DTSはソースデータベースとターゲットクラスターの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全データ移行が完了すると、移行先データベースの使用表領域のサイズが移行元データベースのサイズよりも大きくなります。

  • FLOATまたはDOUBLEデータ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。 DTSはROUND(COLUMN,PRECISION) 関数を使用して、FLOATまたはDOUBLEデータ型の列から値を取得します。 精度を指定しない場合、DTSはFLOATデータ型の列の精度を38桁に設定し、DOUBLEデータ型の列の精度を308桁に設定します。

  • DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。 ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止またはリリースする必要があります。 REVOKEステートメントを実行して、DTSがターゲットデータベースにアクセスするために使用するアカウントの書き込み権限を取り消すこともできます。 それ以外の場合、失敗したタスクが再開された後、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

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

    説明

    DTSは、CDCが有効になっているテーブルのプライマリキーに関連するDDL操作を移行できません。

  • 1回の移行タスクで移行するCDC対応テーブルの数が1,000を超えると、事前チェックは失敗します。

特別なケース

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

課金

移行タイプ

インスタンス設定料金

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

スキーマ移行とフルデータ移行

無料です。

インターネット経由でAlibaba Cloudからデータが移行された場合にのみ課金されます。 詳細については、「課金の概要」をご参照ください。

増分データ移行

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

移行タイプ

  • スキーマ移行

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

    • DTSは、スキーマ、テーブル、ビュー、関数、およびプロシージャのタイプのオブジェクトのスキーマ移行をサポートしています。

    • DTSは、アセンブリ、サービスブローカー、フルテキストインデックス、フルテキストカタログ、分散スキーマ、分散関数、共通言語ランタイム (CLR) ストアドプロシージャ、CLRスカラー値関数、CLRテーブル値関数、内部テーブル、システム、または集計関数のスキーマを移行しません。

    警告

    SQL ServerとAnalyticDB for PostgreSQLは異種データベースです。 サポートするデータ型には、1対1の対応がありません。 データ型マッピングがビジネスに与える影響を評価することを推奨します。 詳細については、「異種データベース間のデータ型マッピング」をご参照ください。

  • 完全なデータ移行

    DTSは、必要なオブジェクトの履歴データをソースデータベースからターゲットデータベースに移行します。

  • 増分データ移行

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

増分移行可能なSQL操作

操作タイプ

SQL文

DML

挿入、更新、および削除

DDL

  • CREATE TABLE

    説明

    CREATE TABLE操作でパーティションテーブルまたは関数を含むテーブルが作成された場合、DTSは操作を移行しません。

  • テーブルの変更

    COLUMNとDROP COLUMNの追加

  • DROP TABLE

  • CREATE INDEXとDROP INDEX

説明
  • DTSは、ユーザー定義型を含むDDL操作を移行しません。

  • DTSはトランザクションDDL操作を移行しません。

データベースアカウントに必要な権限

データベース

スキーマ移行

完全なデータ移行

増分データ移行

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

SELECT権限

SELECT権限

sysadmin

AnalyticDB for PostgreSQLインスタンス

  • ログイン権限

  • 宛先テーブルに対するSELECT、CREATE、INSERT、UPDATE、およびDELETE権限

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

  • 宛先スキーマに対するCREATE権限

  • COPY権限 (メモリベースのバッチコピー操作を実行する権限)

説明

AnalyticDB for PostgreSQLインスタンスの初期アカウントを使用できます。

データベースアカウントを作成し、データベースアカウントに権限を付与する方法の詳細については、以下のトピックを参照してください。

準備

説明

増分データを移行するタスクを構成する前に、自己管理型SQL Serverデータベースでログ設定を構成し、クラスター化インデックスを作成する必要があります。

重要

複数のデータベースから増分データを移行する場合は、各データベースに対して手順1〜3を繰り返します。 DDL 操作を実行すると、データの不整合が発生する可能性があります。

  1. 自己管理型SQL Serverデータベースで次のステートメントを実行して、復旧モデルを完全に変更します。

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

    パラメーター :

    <database_name>: ソースデータベースの名前。

    例:

    use master;
    GO
    ALTER DATABASE <database_name> SET RECOVERY FULL WITH ROLLBACK IMMEDIATE;
    GO
  2. 次のステートメントを実行して、ソースデータベースの論理バックアップを作成します。 すでに論理バックアップを作成している場合は、この手順をスキップします。

    バックアップデータベース <database_name>

    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> をDISK='<physical_backup_device_name>' WITH initに

    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. [データ移行タスク] ページに移動します。

    1. データ管理 (DMS) コンソール にログインします。

    2. 上部のナビゲーションバーで、DTS.ポインタの上に移動します。

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

    説明
  2. の右側にあるドロップダウンリストからデータ移行タスク、データ移行インスタンスが存在するリージョンを選択します。

    説明

    新しいDTSコンソールを使用する場合は、左上隅にデータ移行インスタンスが存在するリージョンを選択する必要があります。

  3. [タスクの作成] をクリックします。 [データ移行タスクの作成] ページで、ソースデータベースとターゲットデータベースを設定します。 次の表にパラメーターを示します。

    警告

    ソースデータベースとターゲットデータベースを設定した後、ページの上部に表示される制限を読むことを推奨します。 そうしないと、タスクが失敗したり、データの不一致が発生します。

    セクション

    パラメーター

    説明

    非該当

    タスク名

    タスクの名前。 タスク名は自動生成されます。 タスクを識別するために、有益な名前を指定することを推奨します。 一意のタスク名を指定する必要はありません。

    ソースデータベース

    データベースタイプ

    移行元ディスクのタイプを設定します。 [SQL Server] を選択します。

    アクセス方法

    ソースデータベースのアクセス方法。 [ECS上の自己管理データベース] を選択します。

    説明

    ソースデータベースが自己管理データベースの場合、データベースのネットワーク環境を展開する必要があります。 詳細については、「Preparation overview」をご参照ください。

    インスタンスリージョン

    自己管理型SQL Serverデータベースが存在するリージョン。

    インスタンスID

    自己管理型SQL ServerデータベースをホストするElastic Compute Service (ECS) インスタンスのID。

    ポート番号

    自己管理型SQL Serverデータベースのサービスポート番号。 デフォルトのポート番号は1433です。

    データベースアカウント

    自己管理型SQL Serverデータベースへのログインに使用されるアカウント。 アカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。

    データベースパスワード

    データベースインスタンスへのアクセスに使用されるパスワード。

    宛先データベース

    データベースタイプ

    ターゲットデータベースのタイプ。 [AnalyticDB for PostgreSQL] を選択します。

    アクセス方法

    ターゲットデータベースのアクセス方法。 [Alibaba Cloudインスタンス] を選択します。

    インスタンスリージョン

    移行先のAnalyticDB for PostgreSQLインスタンスが存在するリージョン。

    インスタンスID

    移行先のAnalyticDB for PostgreSQLインスタンスのID。

    データベース名

    移行先AnalyticDB for PostgreSQLインスタンスの移行先データベースの名前。

    データベースアカウント

    移行先のAnalyticDB for PostgreSQLインスタンスのデータベースアカウント。 アカウントに必要な権限については、「データベースアカウントに必要な権限」をご参照ください。

    データベースパスワード

    データベースインスタンスへのアクセスに使用されるパスワード。

  4. 自己管理データベースにIPアドレスホワイトリストが設定されている場合は、DTSサーバーのCIDRブロックをIPアドレスホワイトリストに追加します。 次に、接続テスト をクリックします。

    警告

    DTSサーバーのパブリックCIDRブロックがデータベースインスタンスのホワイトリストまたはECSインスタンスのセキュリティグループルールに自動的または手動で追加されると、セキュリティリスクが発生する可能性があります。 したがって、DTSを使用してデータを移行する前に、潜在的なリスクを理解して認識し、ユーザー名とパスワードのセキュリティの強化、公開されるポートの制限、API呼び出しの認証、ホワイトリストまたはセキュリティグループルールの定期的なチェック、CIDRブロックの禁止、またはExpress Connectを使用したデータベースインスタンスのDTSへの接続、VPNゲートウェイ、またはSmart Access Gateway。

  5. 移行するオブジェクトと詳細設定を設定します。

    パラメーター

    説明

    移行タイプ

    • フルデータ移行のみを実行するには、[スキーマ移行][フルデータ移行] を選択します。

    • データ移行中のサービスの継続性を確保するには、[スキーマ移行][フルデータ移行] 、および [増分データ移行] を選択します。

    説明

    増分データ移行を選択しない場合、データ移行中にソースデータベースにデータを書き込まないことを推奨します。 これにより、ソースデータベースとターゲットデータベース間のデータの整合性が確保されます。

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

    • エラーの事前チェックと報告: ターゲットデータベースに、ソースデータベースのテーブルと同じ名前を使用するテーブルが含まれているかどうかを確認します。 ソースデータベースとターゲットデータベースに同じテーブル名のテーブルが含まれていない場合は、事前チェックに合格します。 それ以外の場合、事前チェック中にエラーが返され、データ移行タスクを開始できません。

      説明

      ソースデータベースとターゲットデータベースに同じ名前のテーブルが含まれていて、ターゲットデータベース内のテーブルを削除または名前変更できない場合は、オブジェクト名マッピング機能を使用して、ターゲットデータベースに移行されるテーブルの名前を変更できます。 詳細については、「マップオブジェクト名」をご参照ください。

    • エラーを無視して続行: ソースデータベースとターゲットデータベースの同じテーブル名の事前チェックをスキップします。

      警告

      エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスが次の潜在的なリスクにさらされる可能性があります。

      • ソースデータベースとターゲットデータベースが同じスキーマを持ち、データレコードがターゲットデータベースの既存のデータレコードと同じプライマリキーを持つ場合、次のシナリオが発生する可能性があります。

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

        • 増分データ移行中に、DTSはデータレコードを移行先データベースに移行します。 ターゲットデータベースの既存のデータレコードが上書きされます。

      • ソースデータベースとターゲットデータベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。 作業は慎重に行ってください。

    SQL Server増分同期モード

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

      • 利点:

        • このモードでは、ヒープテーブル、主キーのないテーブル、圧縮テーブル、計算列のあるテーブルをサポートします。

        • このモードは、より高い安定性とさまざまな完全なDDLステートメントを提供します。

      • 短所:

        • DTSは、トリガーdts_cdc_sync_ddl、ハートビートテーブルdts_sync_progress、およびDDLストレージテーブルdts_cdc_ddl_historyをソースデータベースに作成し、ソースデータベースと特定のテーブルの変更データキャプチャ (CDC) を有効にします。

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

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

      • 利点:

        このモードでは、ソースデータベースの設定は変更されません。

      • 短所:

        このモードでは、ヒープテーブル、主キーのないテーブル、圧縮テーブル、または計算列のあるテーブルはサポートされません。

    • 増分同期のための CDC インスタンスのポーリングとクエリ:

      • 利点:

        • ソースデータベースがAmazon RDS for SQL Serverインスタンス、Microsoft Azure SQL databaseのデータベース、Microsoft Azure SQL Managed instance、Microsoft Azure SQL Server on Virtual Machine、またはGoogle Cloud SQL for SQL Serverインスタンスである場合、完全なデータ移行と増分データ移行がサポートされます。

        • SQL ServerのネイティブCDCコンポーネントを使用して増分データを取得すると、増分移行の安定性が高まり、ネットワーク帯域幅が少なくなります。

      • 短所:

        • DTSインスタンスで使用されるソースデータベースアカウントには、CDCを有効にする権限が必要です。 増分データ移行には約10秒かかります。

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

    DDL操作とDML操作の同期

    インスタンスレベルで移行するSQL操作。 詳細については、このトピックの「SQL操作を段階的に移行できる」をご参照ください。

    説明

    特定のデータベースまたはテーブルで実行されたSQL操作を選択するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。 表示されるダイアログボックスで、段階的に移行するSQL操作を選択します。

    ソースオブジェクト

    ソースオブジェクト セクションから1つ以上のオブジェクトを選択します。 向右小箭头アイコンをクリックして、選択中のオブジェクト セクションにオブジェクトを追加します。

    説明

    このシナリオでは、異種データベース間でデータ移行が実行されます。 したがって、移行できるのはテーブルのみです。 ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトは、ターゲットデータベースに移行されません。

    選択中のオブジェクト

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

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

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

    • データをフィルタリングするWHERE条件を指定するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。 表示されるダイアログボックスで、条件を指定します。 条件の指定方法の詳細については、「フィルター条件の指定」をご参照ください。

    • 特定のデータベースまたはテーブルで実行されたSQL操作を選択するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。 表示されるダイアログボックスで、移行するSQL操作を選択します。 詳細については、このトピックの「SQL操作を段階的に移行できる」をご参照ください。

  6. クリック次へ:詳細設定詳細設定を設定します。

    パラメーター

    説明

    Set Alerts

    データ移行タスクのアラートを設定するかどうかを指定します。 タスクが失敗するか、移行の待ち時間が指定されたしきい値を超えると、アラート送信先は通知を受け取ります。 有効な値:

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

    失敗した接続のリトライ時間範囲。 データ移行タスクの開始後にソースデータベースまたはターゲットデータベースの接続に失敗した場合、DTSはその時間範囲内ですぐに接続を再試行します。 有効な値: 10 ~ 1440 単位は分です。 デフォルト値: 720 パラメーターを30より大きい値に設定することを推奨します。 DTSが指定された時間範囲内にソースデータベースとターゲットデータベースに再接続すると、DTSはデータ移行タスクを再開します。 それ以外の場合、データ移行タスクは失敗します。

    説明
    • ソースまたはターゲットデータベースが同じである複数のデータ移行タスクに対して異なるリトライ時間範囲を設定した場合、設定された最短のリトライ時間範囲が優先されます。

    • DTSが接続を再試行すると、DTSインスタンスに対して課金されます。 業務要件に基づいて再試行時間範囲を指定することを推奨します。 ソースインスタンスとターゲットインスタンスがリリースされた後、できるだけ早くDTSインスタンスをリリースすることもできます。

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

    その他の問題の再試行時間範囲。 たとえば、データ移行タスクの開始後にDDLまたはDML操作の実行に失敗した場合、DTSは再試行時間範囲内ですぐに操作を再試行します。 有効な値: 1 ~ 1440 単位は分です。 デフォルト値は 10 です。 パラメーターを10より大きい値に設定することを推奨します。 指定された再試行時間内に失敗した操作が正常に実行された場合、DTSはデータ移行タスクを再開します。 それ以外の場合、データ移行タスクは失敗します。

    重要

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

    ETLの設定

    抽出、変換、および読み込み (ETL) 機能を有効にするかどうかを指定します。 詳細については、「」をご参照ください。ETLとは何ですか? 有効な値:

  7. 移行先に移行するテーブルの主キー列と配布キー列を指定します。AnalyticDB for PostgreSQLインスタンスを作成します。

  8. ページの下部で、次:タスク設定の保存と事前チェック をクリックします。

    ポインタを 次:タスク設定の保存と事前チェック に移動し、[OpenAPIパラメーターのプレビュー] をクリックして、関連するAPI操作を呼び出してDTSタスクを設定するときに指定するパラメーターを表示できます。

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

    • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にある [詳細の表示] をクリックします。 チェック結果に基づいて原因を分析した後、問題のトラブルシューティングを行います。 次に、もう一度プレチェックを実行します。

    • 事前チェック中にアイテムに対してアラートがトリガーされた場合:

      • アラートアイテムを無視できない場合は、失敗したアイテムの横にある [詳細の表示] をクリックして問題のトラブルシューティングを行います。 次に、もう一度プレチェックを実行します。

      • アラート項目を無視できる場合は、[アラート詳細の確認] をクリックします。 [詳細の表示] ダイアログボックスで、[無視] をクリックします。 表示されたメッセージボックスで、[OK] をクリックします。 次に、[再度事前チェック] をクリックして、事前チェックを再度実行します。 アラート項目を無視すると、データの不整合が発生し、ビジネスが潜在的なリスクにさらされる可能性があります。

  9. 成功率100% になるまで待ちます。 次に、[次へ: インスタンスの購入] をクリックします。

  10. [インスタンスの購入] ページで、データ移行インスタンスのインスタンスクラスパラメーターを設定します。 下表にパラメーターを示します。

    セクション

    パラメーター

    説明

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

    リソースグループ

    データ移行インスタンスが属するリソースグループ。 デフォルト値: Default resource group 詳細については、「」をご参照ください。リソース管理とは

    インスタンスクラス

    DTSは、移行速度が異なるインスタンスクラスを提供します。 ビジネスシナリオに基づいてインスタンスクラスを選択できます。 詳細については、「データ移行仕様」をご参照ください。

  11. 読んで同意するデータ伝送サービス (従量課金) サービス規約チェックボックスを選択します。

  12. [購入して開始] をクリックします。 表示されるメッセージで、 [OK] をクリックします。

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