すべてのプロダクト
Search

このプロダクト

    :DTSを使用したApsaraDB RDS for PostgreSQLインスタンス間のデータ移行

    ドキュメントセンター

    :DTSを使用したApsaraDB RDS for PostgreSQLインスタンス間のデータ移行

    最終更新日:Jan 16, 2024

    このトピックでは、data Transmission Service (DTS) を使用して、ApsaraDB RDS for PostgreSQLインスタンス間でスキーマ、フルデータ、および増分データを移行する方法について説明します。 ApsaraDB RDS for PostgreSQLインスタンス間でデータを移行する場合、サポートされているすべての移行タイプを選択して、サービスの継続性を確保できます。

    前提条件

    • ソースインスタンスとターゲットApsaraDB RDS for PostgreSQLインスタンスが作成されます。 詳細については、「ApsaraDB RDS For PostgreSQLインスタンスの作成」をご参照ください。

      説明

      互換性を確保するには、ターゲットデータベースのバージョンがソースデータベースのバージョンと同じかそれ以降である必要があります。

      ターゲットデータベースのバージョンがソースデータベースのバージョンよりも前の場合、データベースの互換性の問題が発生する可能性があります。

    • 移行先ApsaraDB RDS for PostgreSQLインスタンスの使用可能なストレージ容量が、移行元ApsaraDB RDS for PostgreSQLインスタンスのデータの合計サイズよりも大きいこと。

    制限事項

    カテゴリ

    説明

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

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

      ソースデータベースの名前にハイフン (-) を含めることはできません。 例: dts-testdata.

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

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

      • wal_levelパラメーターの値は、logicalに設定する必要があります。

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

    • ソースデータベースで実行する操作の制限:

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

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

    • ソースデータベースに1つ以上の実行時間の長いトランザクションがあり、データ移行タスクで増分データが移行される場合、実行時間の長いトランザクションがコミットされる前に生成されたWALログはクリアされないため、蓄積され、ソースデータベースのストレージ領域が不十分になります。

    その他の制限

    • ソースApsaraDB RDS for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えを実行する必要がある場合は、Logical Replication Slotフェールオーバー機能を有効にする必要があります。 これにより、論理サブスクリプションの中断を防ぎ、データ移行タスクを期待どおりに実行できます。 詳細については、「論理レプリケーションスロットフェールオーバー」をご参照ください。

    • 単一のデータ移行タスクでは、1つのデータベースからのみデータを移行できます。 複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。

    • データの増分移行中に、移行するオブジェクトとしてスキーマを選択し、スキーマにテーブルを作成するか、RENAMEステートメントを実行してスキーマ内のテーブルの名前を変更する場合は、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。

      説明

      上記のサンプルステートメントのスキーマとテーブルを、実際のスキーマ名とテーブル名に置き換えます。

    • DTSは、シーケンスなどのメタデータの有効性をチェックしません。 メタデータの有効性を手動で確認する必要があります。

    • ワークロードがターゲットデータベースに切り替えられた後、新しく書き込まれたシーケンスは、ソースデータベースのシーケンスの最大値から増加しません。 したがって、ワークロードをターゲットデータベースに切り替える前に、ソースデータベース内のシーケンスの最大値を照会する必要があります。 次に、クエリされた最大値をターゲットデータベースのシーケンスの初期値として指定する必要があります。 次のステートメントを実行して、ソースデータベース内のシーケンスの最大値を照会できます。 

      do language plpgsql $$
宣言
  nsp名;
  rel名;
  val int8;
始める
  select nspname、pg_class t2、pg_namespace t3のrelnameで、t2.relnamespace=t3.oidおよびt2.relkind='S'
  ループ
    実行形式 ($_$ select last_valueから % I.% I $_$, nsp, rel) をvalにします。
    通知 '%' を上げ、
    形式 ($_$ select setval('% I.% I'::regclass, % s);$_$, nsp, rel, val + 1);
  終わりのループ;
終了;
$$;

    • DTSは、増分データのDDLステートメント、増分テーブルのスキーマ、およびハートビート情報を取得するために、ソースデータベースに次の一時テーブルを作成します。 データ移行中は、ソースデータベースの一時テーブルを削除しないでください。 そうでなければ、例外が生じる。 DTSインスタンスがリリースされると、一時テーブルは自動的に削除されます。

      public.dts_pg_class、public.dts_pg_attribute、public.dts_pg_type、public.dts_pg_enum、public.dts_postgres_heartbeat、public.dts_ddl_command、およびpublic.dts_args_session。

    • 完全または増分データ移行タスクを実行する場合、移行元データベースから移行するテーブルに外部キー、トリガー、またはイベントトリガーが含まれ、移行先データベースのアカウントが特権アカウントまたはスーパーユーザーロールの権限を持つアカウントである場合、DTSは、完全または増分データ移行中にセッションレベルで一時的にsession_replication_roleパラメーターをレプリカに設定します。 ターゲットデータベースのアカウントに権限がない場合は、手動でsession_replication_roleパラメーターをターゲットデータベースのレプリカに設定する必要があります。 完全移行または増分移行中にsession_replication_roleパラメーターをレプリカに設定した後、ソースデータベースでカスケード更新または削除操作が実行されると、データの不整合が発生する可能性があります。 DTS移行タスクがリリースされた後、session_replication_roleパラメーターの値をoriginに変更できます。

    • 増分データ移行のレイテンシを正確にするために、DTSはソースデータベースにdts_postgres_heartbeatという名前のハートビートテーブルを作成します。

    • 増分データ移行中、DTSはソースデータベースのレプリケーションスロットを作成します。 レプリケーションスロットの先頭にdts_sync_ があります。 このレプリケーションスロットを使用すると、DTSは過去15分以内にソースデータベースの増分ログを取得できます。

      説明

      • DTSインスタンスがリリースされると、レプリケーションスロットは自動的に削除されます。 ソースデータベースのパスワードを変更するか、DTSのIPアドレスホワイトリストを削除すると、レプリケーションスロットを自動的に削除することはできません。 その場合、複製スロットが積み重ならないように、複製スロットをソースデータベースから手動で削除する必要があります。

      • データ移行タスクがリリースされたか失敗した場合、DTSは自動的にレプリケーションスロットをクリアします。 ソースApsaraDB for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えが実行された場合、セカンダリインスタンスにログインしてレプリケーションスロットをクリアする必要があります。

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

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

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

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

    特別なケース

    データ移行中は、ソースApsaraDB RDS for PostgreSQLインスタンスのエンドポイントまたはゾーンを変更しないでください。 それ以外の場合、データ移行タスクは失敗します。

    移行タイプ

    • スキーマ移行

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

    • 完全なデータ移行

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

    • 増分データ移行

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

    増分移行可能なSQL操作

    操作タイプ

    SQL文

    DML

    挿入、更新、および削除

    DDL

    • DDL操作は、2020年10月1日以降に作成されたデータ移行タスクでのみ移行できます。

      重要

      • 2023年5月12日より前に作成されたデータ移行タスクの場合、データ移行タスクを設定する前に、ソースデータベースにトリガーと関数を作成してDDL情報を取得する必要があります。 詳細については、「トリガーと関数を使用してPostgreSQLデータベースの増分DDL移行を実装する」をご参照ください。

      • 増分データ移行は、BITタイプのデータをサポートしていません。

    • ソースデータベースのデータベースアカウントが特権アカウントであり、ソースApsaraDB RDS for PostgreSQLインスタンスのマイナーエンジンバージョンが20210228以降の場合、データ移行タスクで次のDDLステートメントを移行できます。 インスタンスのマイナーエンジンバージョンを更新する方法については、「マイナーエンジンバージョンの更新」をご参照ください。

      • テーブルとドロップテーブルの作成

      • ALTER TABLE (RENAME TABLE、ADD COLUMN、ADD COLUMN DEFAULT、ALTER COLUMN TYPE、DROP COLUMN、ADD CONSTRAINT、ADD CONSTRAINT CHECK、およびALTER COLUMN DROP DEFAULTを含む)

      • TRUNCATE TABLE (ソースApsaraDB RDS for PostgreSQLインスタンスのバージョンは、PostgreSQL V11以降である必要があります) 。

      • テーブルにインデックスを作成する

      重要

      • CASCADEやRESTRICTなど、DDLステートメントの追加情報を移行することはできません。

      • SET session_replication_role = replicaステートメントを実行するセッションからDDLステートメントを移行することはできません。

      • ソースデータベースによって一度に送信されたSQL文にDML文とDDL文の両方が含まれている場合、DTSはDDL文を移行しません。

      • ソースデータベースによって一度に送信されたSQL文に、移行されないオブジェクトに関するDDL文が含まれている場合、DTSはDDL文を移行しません。

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

    データベース

    スキーマ移行

    完全なデータ移行

    増分データ移行

    ApsaraDB RDS for PostgreSQLインスタンスのソース

    pg_catalogスキーマに対するUSAGE権限

    移行するオブジェクトに対するSELECT権限

    特権アカウントの権限。 アカウントはデータベースの所有者である必要があります。

    説明

    ソースApsaraDB RDS for PostgreSQLインスタンスのデータベースエンジンバージョンが9.4で、DML操作のみを移行する場合、データベースアカウントにはREPLICATION権限のみが必要です。

    ApsaraDB RDS for PostgreSQLインスタンス

    移行するオブジェクトに対するCREATEおよびUSAGE権限

    スキーマに対する所有者の権限

    ApsaraDB RDS For PostgreSQLインスタンスのデータベースアカウントを作成し、このアカウントに権限を付与する方法の詳細については、「アカウントの作成」および「データベースの作成」をご参照ください。

    手順

    1. [データ移行タスク] ページに移動します。
      1. にログインします。 データ管理 (DMS) コンソール
      2. 上部のナビゲーションバーで、[DTS] をクリックします。
      3. 左側のナビゲーションウィンドウで、[DTS (DTS)] > [データ移行] を選択します。
      説明
    2. [データ移行タスク] の横にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。
      説明 新しいDTSコンソールを使用する場合は、左上隅にデータ移行インスタンスが存在するリージョンを選択する必要があります。

    3. [タスクの作成] をクリックします。 タスクの作成ウィザードで、ソースデータベースとターゲットデータベースを設定します。

      警告

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

      セクション

      パラメーター

      説明

      N/A

      タスク名

      タスクの名前。 DTSはタスクに名前を自動的に割り当てます。 タスクを簡単に識別できるように、わかりやすい名前を指定することをお勧めします。 一意のタスク名を指定する必要はありません。

      ソースデータベース

      既存のDMSデータベースインスタンスの選択

      使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを選択するかどうかを選択できます。

      • 既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。

      • 既存のインスタンスを選択しない場合は、データベースのパラメーターを手動で設定する必要があります。

      データベースタイプ

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

      アクセス方法

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

      インスタンスリージョン

      ソースApsaraDB RDS for PostgreSQLインスタンスが存在するリージョン。

      インスタンスID

      ソースApsaraDB RDS for PostgreSQLインスタンスのID。

      データベース名

      ソースApsaraDB RDS for PostgreSQLインスタンスでオブジェクトを移行するデータベースの名前。

      データベースアカウント

      ソースApsaraDB RDS for PostgreSQLインスタンスのデータベースアカウント。 アカウントに必要な権限の詳細については、「データベースアカウントに必要な権限」をご参照ください。

      データベースパスワード

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

      宛先データベース

      既存のDMSデータベースインスタンスの選択

      使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを選択するかどうかを選択できます。

      • 既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。

      • 既存のインスタンスを選択しない場合は、データベースのパラメーターを手動で設定する必要があります。

      データベースタイプ

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

      アクセス方法

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

      インスタンスリージョン

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

      インスタンスID

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

      データベース名

      移行先ApsaraDB RDS for PostgreSQLインスタンスでオブジェクトが移行されるデータベースの名前。

      データベースアカウント

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

      データベースパスワード

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

    4. ページの下部で、[接続のテストと続行] をクリックします。

      、ソースまたはターゲットデータベースがAlibaba Cloudデータベースインスタンス (ApsaraDB RDS for MySQL、ApsaraDB for MongoDBインスタンスなど) の場合、DTSは自動的にDTSサーバーのCIDRブロックをインスタンスのIPアドレスホワイトリストに追加します。 ソースデータベースまたはターゲットデータベースがElastic Compute Service (ECS) インスタンスでホストされている自己管理データベースの場合、DTSサーバーのCIDRブロックがECSインスタンスのセキュリティグループルールに自動的に追加されます。ECSインスタンスがデータベースにアクセスできることを確認する必要があります。 自己管理データベースが複数のECSインスタンスでホストされている場合、DTSサーバーのCIDRブロックを各ECSインスタンスのセキュリティグループルールに手動で追加する必要があります。 ソースデータベースまたはターゲットデータベースが、データセンターにデプロイされているか、サードパーティのクラウドサービスプロバイダーによって提供される自己管理データベースである場合、DTSサーバーのCIDRブロックをデータベースのIPアドレスホワイトリストに手動で追加して、DTSがデータベースにアクセスできるようにする必要があります。 詳細については、「DTSサーバーのCIDRブロックをオンプレミスデータベースのセキュリティ設定に追加する」トピックの「DTSサーバーのCIDRブロック」をご参照ください。

      警告

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

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

      パラメーター

      説明

      移行タイプ

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

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

      説明

      • [スキーマ移行] を選択した場合、移行するテーブルのスキーマ (外部キーを含む) を移行元データベースから移行先データベースに移行します。

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

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

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

        説明

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

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

        警告

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

        • ソースデータベースとターゲットデータベースのスキーマが同じである場合、DTSは、ターゲットデータベースのデータレコードと同じ主キー値を持つデータレコードを移行しません。

        • ソースデータベースとターゲットデータベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。 注意して進めてください。

      ソースオブジェクト

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

      説明

      移行するオブジェクトとして、列、テーブル、またはスキーマを選択できます。 移行するオブジェクトとしてテーブルまたは列を選択した場合、DTSは、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトを移行先データベースに移行しません。

      選択中のオブジェクト

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

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

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

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

    6. [次へ: 詳細設定] をクリックして詳細設定を構成します。

      パラメーター

      説明

      Set Alerts

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

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

      • Yes: アラートを設定します。 [はい] を選択した場合、アラートしきい値とアラート連絡先も指定する必要があります。 詳細については、「モニタリングとアラートの設定」をご参照ください。

      宛先インスタンスでのオブジェクト名の大文字化

      ターゲットインスタンスのデータベース名、テーブル名、および列名の大文字化。 デフォルトでは、DTSデフォルトポリシーが選択されています。 他のオプションを選択して、オブジェクト名の大文字化がソースまたはターゲットデータベースの大文字化と一致していることを確認できます。 詳細については、「ターゲットインスタンスのオブジェクト名の大文字化の指定」をご参照ください。

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

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

      説明

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

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

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

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

      重要

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

      ETL の設定

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

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

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

      説明

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

      • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にある [詳細の表示] をクリックします。 エラーメッセージに基づいて問題をトラブルシューティングした後、事前チェックを再度実行できます。

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

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

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

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

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

      セクション

      パラメーター

      説明

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

      リソースグループ

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

      インスタンスクラス

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

    10. チェックボックスをオンにして、Data Transmission Service (Pay-as-you-go) Service Termsを読み、同意します。

    11. [購入と開始] をクリックして、データ移行タスクを開始します。 タスクリストでタスクの進行状況を確認できます。