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

ApsaraDB RDS:DTSを使用して、セルフマネージド型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスにデータを移行する

最終更新日:Jan 16, 2024

このトピックでは、data Transmission Service (DTS) を使用して、自己管理型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスにデータを移行する方法について説明します。 DTS はフルデータ移行と増分データ移行に対応しています。 セルフマネージドPostgreSQLデータベースからAlibaba Cloudにデータを移行する場合、サポートされているすべての移行タイプを選択して、サービスの継続性を確保できます。

前提条件

  • 移行元の自己管理型PostgreSQLデータベースと移行先のApsaraDB RDS for PostgreSQLインスタンスが作成されます。 ApsaraDB RDS For PostgreSQLインスタンスの作成方法の詳細については、「ApsaraDB RDS for PostgreSQLインスタンスの作成」をご参照ください。 サポートされているデータベースバージョンの詳細については、「データ移行シナリオの概要」をご参照ください。

    説明

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

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

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

使用上の注意

カテゴリ

説明

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

  • ソースデータベースが存在するサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が影響を受けます。

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

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

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

  • DTSは、ソースデータベースの一時テーブル、内部トリガー、またはCプログラミング言語で記述された一部の内部プロシージャと関数を移行できません。 DTSは、COMPOSITE、ENUM、およびRANGEタイプのカスタムパラメータを移行できます。 移行するテーブルには、PRIMARY KEY、FOREIGN KEY、UNIQUE、またはCHECK制約が必要です。

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

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

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

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

    • ソースの自己管理型PostgreSQLデータベースでプライマリ /セカンダリの切り替えを実行すると、データ移行タスクは失敗します。

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

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

その他の制限

  • 移行レイテンシのため、ソースデータベースのプライマリノードとセカンダリノードの間でデータが一致しない場合があります。 したがって、データを移行するときは、プライマリノードをデータソースとして使用する必要があります。

  • 単一のデータ移行タスクでは、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_classpublic.dts_pg_attributepublic.dts_pg_typepublic.dts_pg_enumpublic.dts_postgres_heartbeatpublic.dts_ddl_command、およびpublic.dts_args_session

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

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

    説明

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

    Amazon slot查询信息

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

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

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

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

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

移行タイプ

  • スキーマ移行

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

    説明

    DTSは、テーブル、トリガー、ビュー、シーケンス、関数、ユーザー定義型、ルール、ドメイン、操作、および集計のオブジェクトのスキーマ移行をサポートしています。

  • 完全なデータ移行

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

  • 増分データ移行

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

増分移行可能なSQL操作

操作タイプ

SQL文

DML

挿入、更新、および削除

DDL

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

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

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

  • ソースデータベースのデータベースアカウントは、特権アカウントである必要があります。 DTSは、データ移行タスクで次の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 (ソースPostgreSQLデータベースのデータベースエンジンバージョンはPostgreSQL 11以降である必要があります) 。

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

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

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

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

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

    • CREATE SEQUENCEステートメントはサポートされていません。

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

データベース

スキーマ移行

完全なデータ移行

増分データ移行

自己管理型 PostgreSQL データベース

pg_catalogに対するUSAGE権限。

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

スーパーユーザーロールの権限。

ApsaraDB RDS for PostgreSQLインスタンス

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

スキーマ所有者の権限。

スキーマ所有者の権限。

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

始める前に

説明

この例では、Linuxオペレーティングシステムのサーバー上で実行される自己管理型PostgreSQLデータベースが使用されます。

データ移行タスクを設定する前に、次の操作を実行します。

  1. 自己管理型PostgreSQLデータベースが属するサーバーにログオンします。

  2. postgresql.conf設定ファイルのwal_levelパラメーターをlogicalに設定します。

    设置wal_level

    説明

    設定ファイルを変更した後、SELECT pg_reload_conf(); ステートメントを実行するか、自己管理型PostgreSQLデータベースを再起動して、パラメーターを有効にします。

  3. DTSサーバーのCIDRブロックを、自己管理型PostgreSQLデータベースのpg_hba.conf構成ファイルに追加します。 ターゲットデータベースと同じリージョンにあるDTSサーバーのCIDRブロックのみを追加します。 詳細については、「DTSサーバーのCIDRブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。

    説明

    pg_hba.conf設定ファイルの詳細については、「pg_hba.confファイル」をご参照ください。 pg_hba.confファイルのIPアドレスを0.0.0.0/0に設定している場合は、この手順をスキップします。 次の図は、設定を示しています。

    IP

  4. 移行するオブジェクトのデータベースとスキーマ情報に基づいて、移行先のApsaraDB RDS for PostgreSQLインスタンスにデータベースとスキーマを作成します。 ソースデータベースとターゲットデータベースのスキーマ名は同じである必要があります。 詳細については、「データベースの作成」および「スキーマを使用したアカウントの管理」をご参照ください。

自己管理型PostgreSQLデータベースのバージョンが9.4.8〜10.0の場合、データ移行タスクを設定する前に次の操作を実行する必要があります

  1. PostgreSQLソースコードを公式Webサイトからダウンロードし、ソースコードをコンパイルし、PostgreSQLをインストールします。

    1. 自己管理型PostgreSQLデータベースのバージョンに基づいて、PostgreSQL公式Webサイトからソースコードをダウンロードします。

    2. sudoを実行します。/configuresudo makesudo make installコマンドを順番に実行して、ソースコードを構成およびコンパイルし、PostgreSQL. をインストールします。

      重要
      • ソースコードをコンパイルしてPostgreSQLをインストールする場合、PostgreSQLのオペレーティングシステムバージョンはGNUコンパイラコレクション (GCC) バージョンと一致している必要があります。

      • sudoの実行時にエラーが発生した場合。/configureコマンドを使用すると、エラーメッセージに基づいてコマンドを変更できます。 たとえば、エラーメッセージがreadlineライブラリが見つかりません。 -- without-readlineを使用して、readlineサポートを無効にします。、コマンドをsudoに変更できます。/configure -- without-readline

      • 他の方法を使用してPostgreSQLをインストールする場合は、同じオペレーティングシステムバージョンとGCCバージョンを持つテスト環境でali_decodingプラグインをコンパイルする必要があります。

  2. DTSが提供するali_decodingプラグインをダウンロードし、プラグインをコンパイルしてインストールします。

    1. ali_decodingをダウンロードします。

    2. ali_decodingディレクトリを、コンパイルおよびインストールされているPostgreSQLのcontribディレクトリにコピーします。

      contrib目录

    3. ali_decodingディレクトリに移動し、Makefileファイルの内容を次のスクリプトに置き換えます。

      # contrib/ali_decoding/Makefile
      MODULE_big = ali_decoding
      モジュール=ali_decoding
      OBJS = ali_decoding.o
      
      DATA = ali_decoding -- 0.0.1.sql ali_decoding -- unpackaged -- 0.0.1.sql
      
      EXTENSION = ali_decoding
      
      NAME = ali_decoding
      
      # subdir = contrib/ali_decoding
      # top_builddir = ../..
      # include $(top_builddir)/src/Makefile.global
      # include $(top_srcdir)/contrib/contrib-global.mk
      
      # PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
      # pgsql_lib_dir := $(shell $(PG_CONFIG) -- libdir)
      # PGXS := $(シェル $(PG_CONFIG) -- pgxs)
      # include $(PGXS)
      
      # 次のコマンドを実行して、ali_decodingプラグインをインストールします。ifdef USE_PGXS
      PG_CONFIG = pg_config
      PGXS := $(shell $(PG_CONFIG) -- pgxs)
      含む $(PGXS)
      else
      subdir = contrib/ali_decoding
      top_builddir = ../..
      $(top_builddir)/src/Makefile.globalを含む
      include $(top_srcdir)/contrib/contrib-global.mk
      endif 
    4. ali_decodingディレクトリに移動し、sudo makeコマンドとsudo make installコマンドを順番に実行して、ソースコードをコンパイルし、ali_decodingプラグインのインストールに必要なファイルを取得します。

    5. 指定したディレクトリにファイルをコピーします。

      指定位置

  3. 移行するオブジェクトのデータベースとスキーマ情報に基づいて、移行先のApsaraDB RDS for PostgreSQLインスタンスにデータベースとスキーマを作成します。 ソースデータベースとターゲットデータベースのスキーマ名は同じである必要があります。 詳細については、「データベースの作成」および「スキーマを使用したアカウントの管理」をご参照ください。

手順

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

    警告

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

    セクション

    パラメーター

    説明

    N/A

    タスク名

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

    ソースデータベース

    データベースタイプ

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

    アクセス方法

    ソースデータベースのアクセス方法。 ソースデータベースの配置場所に基づいて値を選択します。 この例では、Cloud Enterprise Network (CEN) が選択されています。

    説明

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

    インスタンスリージョン

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

    CENインスタンスID

    自己管理型PostgreSQLデータベースをホストするCENインスタンスのID。

    接続済みVPC

    自己管理型PostgreSQLデータベースがデプロイされている仮想プライベートクラウド (VPC) 。

    IPアドレス (ドメイン名はサポートされていません)

    自己管理型PostgreSQLデータベースのサーバーIPアドレス。

    ポート番号

    自己管理型PostgreSQLデータベースのサービスポート番号。 デフォルト値: 5432

    データベース名

    オブジェクトを移行する自己管理型PostgreSQLデータベースの名前。

    データベースアカウント

    自己管理型PostgreSQLデータベースのアカウント。 必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。

    データベースパスワード

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

    宛先データベース

    データベースタイプ

    ターゲットデータベースのタイプ。 [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 MySQLApsaraDB 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操作を選択します。 詳細については、このトピックの「SQL操作を段階的に移行できる」をご参照ください。

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

    パラメーター

    説明

    Set Alerts

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

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

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

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

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

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

    失敗した接続のリトライ時間範囲。 データ移行タスクが失敗した場合、DTSは再試行時間範囲内ですぐに接続を再試行します。 有効な値: 10 ~ 1440 単位: 分。 デフォルト値: 120 パラメーターを30より大きい値に設定することを推奨します。 DTSが指定された時間範囲内にソースデータベースとターゲットデータベースに再接続すると、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. [購入と開始] をクリックして、データ移行タスクを開始します。 タスクリストでタスクの進行状況を確認できます。