Amazon RDS for Oracle から PolarDB for PostgreSQL（Oracle 互換）へのデータ移行 - Data Transmission Service

Data Transmission Service（DTS）を使用して、Amazon RDS for Oracle インスタンスから PolarDB for PostgreSQL（Compatible with Oracle）クラスターへデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしているため、ダウンタイムを最小限に抑えながら移行を完了できます。

前提条件

開始する前に、以下の点を確認してください。

Amazon RDS for Oracle インスタンスでパブリックアクセスが有効化されており、DTS がインターネット経由で接続可能である
Amazon RDS for Oracle インスタンスが Oracle 9i、10g、11g、または 12c 以降（非マルチテナントアーキテクチャ）を実行している
移行先の PolarDB for PostgreSQL（Compatible with Oracle）クラスターに、ソースインスタンスからの全データを格納できる十分な空きストレージ容量がある
DTS の Oracle 移行に関する機能と制限事項を理解している。移行前に、Advanced Database & Application Migration（ADAM）を使用してデータベースを評価してください。詳細については、「Oracle データベースの準備」および「概要」をご参照ください。

課金

移行タイプ	インスタンス構成料金	データ転送料金
スキーマ移行および完全なデータ移行	無料	無料
増分データ移行	課金対象です。詳細については、「課金概要」をご参照ください。	—

移行タイプ

移行タイプ	説明
スキーマ移行	スキーマを移行先クラスターに移行します。サポートされるオブジェクトタイプ：テーブル、ビュー、シノニム、トリガー、ストアドプロシージャ、ストアドファンクション、パッケージ、およびユーザー定義型。説明このシナリオでは、DTS はトリガーのスキーマ移行をサポートしていません。データの不整合を防ぐため、移行前にソースデータベースからすべてのトリガーを削除してください。詳細については、「ソースデータベースにトリガーが含まれる場合のデータ同期タスクの設定」をご参照ください。
完全なデータ移行	Amazon RDS for Oracle インスタンスから移行先クラスターへ既存の全データを移行します。スキーマ移行または完全なデータ移行の実行中は、移行済みオブジェクトに対して DDL 操作を実行しないでください。その場合、対象オブジェクトの移行に失敗する可能性があります。
増分データ移行	完全なデータ移行が完了した後、DTS はソースから継続的にリドログファイルをポーリングし、増分変更を移行先に適用します。これにより、ソースアプリケーションを中断することなく、移行先を同期状態に保つことができます。

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

タイプ	サポートされる文
DML	INSERT、UPDATE、DELETE
DDL	CREATE TABLE（パーティション句、サブパーティション句、関数を含む文および CREATE TABLE AS SELECT はサポートされません）、ALTER TABLE（ADD COLUMN、ADD INDEX、DROP COLUMN、DROP INDEX、MODIFY COLUMN、RENAME COLUMN）、DROP TABLE、RENAME TABLE、TRUNCATE TABLE、CREATE INDEX

必要な権限

データベース	スキーマ移行	完全なデータ移行	増分データ移行
Amazon RDS for Oracle インスタンス	スキーマオーナー	スキーマオーナー	Master ユーザー
PolarDB for PostgreSQL（Compatible with Oracle）クラスター	スキーマオーナー	—	—

アカウント作成および権限付与の手順については、以下をご参照ください。

Amazon RDS for Oracle：「データベースアカウントの準備」、「CREATE USER」および「GRANT」
PolarDB for PostgreSQL（Compatible with Oracle）クラスター：「データベースアカウントの作成」

制限事項

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

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

ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。
Express Connect 経由で接続された Oracle Real Application Cluster（RAC）データベースの場合：Single Client Access Name（SCAN）IP アドレスの代わりに仮想 IP アドレス（VIP）を指定してください。VIP を指定した後は、ノードフェイルオーバーはサポートされません。
Express Connect、VPN Gateway、Smart Access Gateway、Database Gateway、または Cloud Enterprise Network（CEN）経由で接続された Oracle RAC データベースの場合：ソースデータベースの構成時に SCAN IP アドレスの代わりに単一の VIP を使用できます。VIP を指定した後は、Oracle RAC データベースのノードフェイルオーバーはサポートされません。
ソースデータベースの VARCHAR2 フィールドに空文字列（Oracle では NULL として評価）が含まれており、対応する移行先フィールドに非 NULL 制約（NOT NULL constraint）が設定されている場合、移行タスクは失敗します。
移行対象のテーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約（UNIQUE constraint）が必要です。それ以外の場合、移行先に重複レコードが生成される可能性があります。
代替手段として、タスク構成時に非表示のプライマリキーを追加オプションを有効化できます。DTS は、プライマリキーまたは一意制約がないテーブルに対して ROWID カラムを非表示のプライマリキーとして使用します。
Oracle 12c 以降の場合：テーブル名は 30 バイトを超えてはなりません。
移行中にテーブルまたはカラムの名前を変更する場合（テーブルレベルの移行）：1 つのタスクでは最大 1,000 個のテーブルをサポートします。1,000 個を超える場合は、複数のタスクをバッチ単位で構成するか、データベース全体を移行してください。
増分データ移行の場合：
- ソースでリドログおよびアーカイブログが有効化されている必要があります。
- 増分のみの移行の場合：リドログおよびアーカイブログを 24 時間以上保持してください。
- 完全＋増分移行の場合：ログを少なくとも 7 日間保持してください。完全移行が完了した後は、保持期間を 24 時間以上に短縮できます。
重要
DTS がリドログまたはアーカイブログを取得できない場合、タスクは失敗します。最悪の場合、データ損失または不整合が発生する可能性があります。ログ保持要件を満たさない場合、DTS のサービスレベル合意（SLA）は適用されません。
スキーマ移行および完全なデータ移行中は、ソースデータベースに対して DDL 操作を実行しないでください。移行中にスキーマが変更された場合、タスクは失敗します。
完全移行のみ（増分なし）の場合：ソースへのデータ書き込みを行わないでください。整合性を保証するには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に実行してください。
移行中に LONGTEXT フィールドを更新しないでください。LONGTEXT フィールドが変更された場合、タスクは失敗します。

その他の制限事項

ピーク時間帯を避けて移行を実行してください。DTS はソースおよび移行先の両方で読み取りおよび書き込みリソースを使用するため、データベース負荷が増加する可能性があります。
完全移行後、移行先クラスターの表領域（tablespace）は、同時 INSERT 操作による断片化（fragmentation）の影響で、ソースデータベースよりも大きくなります。
DTS は失敗したタスクを最大 7 日間自動的に再試行します。ワークロードを移行先に切り替える前に、失敗したタスクを停止またはリリースしてください。そうしないと、再開されたタスクが移行先のデータをソースのデータで上書きする可能性があります。あるいは、移行先の DTS アカウントに対する書き込み権限を取消すために、REVOKE 文を実行してください。
移行先クラスターは、ROWID 値に対応する一意なインデックス（例：pg_oid_1498503_index）を自動生成します。そのため、移行先にはソースよりも多くのインデックスが存在します。
移行先クラスターは文字列終端子 \0 をサポートしていません。DTS はこの文字を書き込み時にスキップするため、ソースと移行先の間に不整合が発生します。
ソース Oracle データベースの CHECK 制約は、移行先クラスターでは非 NULL 制約（NOT NULL constraint）に変換されます。
ソースおよび移行先データベースの文字セット（character set）は互換性がある必要があります。互換性がない場合、不整合またはタスク失敗が発生します。
DTS のスキーマ移行機能を使用してください。スキーマ移行をスキップすると、データ型の不適合によりタスクが失敗する可能性があります。
ソースおよび移行先データベースのタイムゾーンは同一である必要があります。
カスタム型オブジェクトは移行可能です。組み込み Oracle オブジェクトは移行できませんが、PolarDB for PostgreSQL（Compatible with Oracle）は Oracle の組み込みオブジェクトをネイティブで既にサポートしています — 手動での移行は不要です。
DTS はシーケンスなどのメタデータを検証しません。移行後にシーケンスを手動で検証してください。
ワークロードを移行先に切り替えた後、新しく書き込まれるシーケンスは、ソースの最大シーケンス値から自動的に継続しません。切り替え前に、ソースの最大シーケンス値を照会し、それを移行先の開始値として設定してください。以下の PL/SQL ブロックをソースデータベースで実行して、setval 文を生成します。
出力には、ソースデータベース内のすべてのシーケンスに対する setval 文が含まれます。ご自身の移行に該当する文のみを実行してください。
```
DECLARE
  CURSOR cur_data IS
    SELECT SEQUENCE_NAME, LAST_NUMBER FROM user_sequences;
  v_column1_value varchar(1000);
  v_column2_value number(20);
BEGIN
  OPEN cur_data;
  LOOP
    FETCH cur_data INTO v_column1_value, v_column2_value;
    EXIT WHEN cur_data%NOTFOUND;
    DBMS_OUTPUT.PUT_LINE('select setval(''' || lower(v_column1_value) || ''', ' || v_column2_value || ');');
  END LOOP;
  CLOSE cur_data;
END;
/
```

データ型マッピング

Oracle と PolarDB for PostgreSQL (Compatible with Oracle) 間のデータ型マッピングについては、「異種データベース間のデータ型マッピング」をご参照ください。

ソースデータベースの構成

DTS 移行タスクを作成する前に、以下の手順を完了してください。

ステップ 1：セキュリティグループに DTS サーバーの CIDR ブロックを追加

Amazon RDS Management Console にログインします。
Amazon RDS for Oracle インスタンスの基本情報ページに移動します。
セキュリティグループルールセクションで、既存のインバウンドルールを含むセキュリティグループの名前をクリックします。
移行先データベースのリージョンに対応する DTS サーバーの CIDR ブロック（ポート 1521）をインバウンドルールに追加します。「DTS サーバーの CIDR ブロックの追加」をご参照ください。
移行先データベースが配置されているリージョンの CIDR ブロックのみを追加してください。たとえば、ソースがシンガポールにあり、移行先が中国（杭州）にある場合、中国（杭州）の CIDR ブロックのみを追加します。必要な CIDR ブロックは一度にすべて追加できます。

ステップ 2：ログ設定の構成（増分移行のみ）

増分データ移行を実行しない場合は、このステップをスキップしてください。

ご使用の Oracle バージョンに応じた構成を選択してください。

Oracle 12c 以降（非マルチテナントアーキテクチャ）

Master ユーザーアカウントおよび SQL*Plus を使用して Amazon RDS for Oracle インスタンスに接続します。
アーカイブログが有効化されているかどうかを確認します。
```
SELECT LOG_MODE FROM v$database;
```
結果が ARCHIVELOG の場合、アーカイブログはすでに有効化されています。そうでない場合は、続行する前に有効化してください。

アーカイブログの保持期間を最低 72 時間に設定します。

-- 現在の構成を確認
exec rdsadmin.rdsadmin_util.show_configuration;

-- 72 時間に保持期間を設定
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours', 72);

補足ログ（supplemental logging）を有効化します。データベースレベルまたはテーブルレベルの補足ログを選択できます。

データベースレベル（フルデータベース移行に推奨）：

-- 現在の補足ログステータスを確認
SELECT supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_ui FROM v$database;
-- プライマリキーおよび一意キーの補足ログを有効化
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'PRIMARY KEY');
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'UNIQUE');

テーブルレベル（いずれかのオプションを選択）：

-- オプション 1：すべてのカラムに対して補足ログを有効化
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'ALL');
-- オプション 2：プライマリキーの補足ログのみを有効化
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'PRIMARY KEY');

データベースアカウントを作成し、必要な権限を付与します。以下の例では、RDSDT_DTSACCT という名前のアカウントを作成します。

-- DTS アカウントの作成
create user RDSDT_DTSACCT IDENTIFIED BY RDSDT_DTSACCT;
grant create session to RDSDT_DTSACCT;
grant connect to RDSDT_DTSACCT;
grant resource to RDSDT_DTSACCT;

-- ログマイニングビューの読み取り権限
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR','RDSDT_DTSACCT','EXECUTE');

-- オブジェクトのメタデータ読み取り権限
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY','RDSDT_DTSACCT','SELECT');
grant select any table to RDSDT_DTSACCT;
grant select any transaction to RDSDT_DTSACCT;

-- ログ関連ビューの読み取り権限
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ACTIVE_INSTANCES','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$INSTANCE','RDSDT_DTSACCT','SELECT');

-- 内部辞書テーブルの読み取り権限
exec rdsadmin.rdsadmin_util.grant_sys_object('USER$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('COL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('IND$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ICOL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('CDEF$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('CCOL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABPART$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABSUBPART$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABCOMPART$','RDSDT_DTSACCT','SELECT');

-- 追加の特権
grant LOGMINING TO RDSDT_DTSACCT;
grant EXECUTE_CATALOG_ROLE to RDSDT_DTSACCT;
grant select on v$database to rdsdt_dtsacct;
grant select on dba_objects to rdsdt_dtsacct;
grant select on DBA_TAB_COMMENTS to rdsdt_dtsacct;
grant select on dba_tab_cols to rdsdt_dtsacct;
grant select_catalog_role TO rdsdt_dtsacct;

Oracle 9i、10g、11g

Master ユーザーアカウントおよび SQL*Plus を使用して Amazon RDS for Oracle インスタンスに接続します。
インスタンスが ARCHIVELOG モードで実行されているかどうかを確認します。
```
archive log list;
```
インスタンスが NOARCHIVELOG モードの場合、続行する前に ARCHIVELOG モードに切り替えてください。「アーカイブされたリドログの管理」をご参照ください。

強制ログ（force logging）を有効化します。

exec rdsadmin.rdsadmin_util.force_logging(p_enable => true);

プライマリキーおよび一意キーの補足ログを有効化します。

begin rdsadmin.rdsadmin_util.alter_supplemental_logging(p_action => 'ADD',p_type => 'PRIMARY KEY');end;/
begin rdsadmin.rdsadmin_util.alter_supplemental_logging(p_action => 'ADD',p_type => 'UNIQUE');end;/

アーカイブログの保持期間を最低 24 時間に設定します。

begin rdsadmin.rdsadmin_util.set_configuration(name => 'archivelog retention hours', value => '24');end;/

変更をコミットします。
```
commit;
```

移行タスクの作成

データ移行タスクページに移動します。
1. Data Management（DMS）コンソールにログインします。
2. トップナビゲーションバーで、DTS をクリックします。
3. 左側ナビゲーションウィンドウで、DTS（DTS） ＞ データ移行 を選択します。
また、新しい DTS コンソールのデータ移行タスクページに直接アクセスすることもできます。コンソールのナビゲーションに関する詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルのカスタマイズ」をご参照ください。
データ移行タスクの横にあるドロップダウンリストから、データ移行インスタンスが配置されているリージョンを選択します。
新しい DTS コンソールでは、左上隅のリージョンを選択します。

タスクの作成 をクリックします。データ移行タスクの作成 ウィザードで、ソースおよび移行先データベースを構成します。

警告

ソースおよび移行先データベースの構成後、次に進む前にページ上部に表示される制限事項を必ず確認してください。このステップをスキップすると、タスクの失敗やデータの不整合が発生する可能性があります。

ソースデータベースのパラメーター

パラメーター	説明
タスク名	タスクの説明的な名前。DTS が自動的に名前を生成します。名前の重複は許可されます。
既存の DMS データベースインスタンスを選択	任意。接続パラメーターを自動入力するために登録済みのインスタンスを選択するか、手動で構成してください。
データベースタイプ	Oracle を選択します。
アクセス方法	パブリック IP アドレスを選択します。
インスタンスリージョン	Amazon RDS for Oracle インスタンスが配置されているリージョン。リストにない場合は、地理的に最も近いリージョンを選択してください。
ドメイン名または IP	Amazon RDS for Oracle インスタンスのエンドポイント。
ポート番号	サービスポート。デフォルト： 1521。
Oracle タイプ	非 RAC インスタンスを選択して SID パラメーターを構成するか、RAC または PDB インスタンスを選択してサービス名パラメーターを構成します。本例では非 RAC インスタンスを使用します。
データベースアカウント	ソースインスタンスのデータベースアカウント。詳細については、「必要な権限」をご参照ください。
データベースパスワード	データベースアカウントのパスワード。

移行先データベースのパラメーター

パラメーター	説明
既存の DMS データベースインスタンスを選択	任意。接続パラメーターを自動入力するために登録済みのインスタンスを選択するか、手動で構成してください。
データベースタイプ	PolarDB（Oracle 互換）を選択します。
アクセス方法	Alibaba Cloud インスタンスを選択します。
インスタンスリージョン	移行先の PolarDB for PostgreSQL（Compatible with Oracle）クラスターが配置されているリージョン。
インスタンス ID	移行先クラスターの ID。
データベース名	クラスター内の移行先データベースの名前。
データベースアカウント	移行先クラスターのデータベースアカウント。詳細については、「必要な権限」をご参照ください。
データベースパスワード	データベースアカウントのパスワード。

接続テストと続行 をクリックします。ソースデータベースに IP アドレスホワイトリストが設定されている場合は、DTS サーバーの CIDR ブロックをホワイトリストに追加したうえで、接続テストと続行 をクリックします。
警告
DTS サーバーの CIDR ブロックを IP アドレスホワイトリストまたはセキュリティグループルールに追加すると、ネットワークへの露出が発生します。予防措置として、以下の点を実施してください：アカウント認証情報の強化、公開ポートの制限、API 呼び出しの認証、ホワイトリストルールの定期監査、不正な CIDR ブロックの削除。プライベート接続を利用する場合は、Express Connect、VPN Gateway、または Smart Access Gateway を検討してください。

移行対象のオブジェクトおよび移行設定を構成します。

パラメーター	説明
移行タイプ	実行する移行タイプを選択します。ダウンタイムなしで移行するには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に選択します。ワンタイムのカットオーバー移行の場合は、スキーマ移行および完全なデータ移行のみを選択します。説明増分移行を実行しない場合、移行中にソースへのデータ書き込みを行わないでください。
プライマリキー／一意キーのないテーブルに非表示のプライマリキーを追加	移行対象のオブジェクトにプライマリキーまたは一意キーのないテーブルが含まれる場合は、はいに設定します。DTS は、重複データを防止するために ROWID カラムを非表示のプライマリキーとして使用します。このオプションは、すべての 3 つの移行タイプが選択されている場合にのみ利用可能です。
競合テーブルの処理モード	事前チェックおよびエラー報告：開始前にソースおよび移行先で同名のテーブルがあるかをチェックします。競合が見つからない場合にのみタスクが開始されます。エラーを無視して続行：事前チェックをスキップします。警告このオプションを選択すると、データの不整合が発生する可能性があります。具体的には：ソースおよび移行先データベースのスキーマが同一の場合、DTS は移行先に既に存在するプライマリキーと同じデータレコードを移行しません；ソースおよび移行先データベースのスキーマが異なる場合、特定のカラムのみが移行されるか、タスクが失敗します。慎重にご判断ください。
ソースオブジェクト	カラム、テーブル、またはデータベースを選択し、アイコンをクリックして選択済みオブジェクトに移動します。
選択済みオブジェクト	単一のオブジェクトの名前を変更するには、右クリックします。「単一オブジェクトの名前マッピング」をご参照ください。複数のオブジェクトを一度に名前変更するには、一括編集をクリックします。「複数オブジェクトの名前マッピング」をご参照ください。説明オブジェクトの名前変更により、依存オブジェクトの移行が失敗する可能性があります。条件付きで行をフィルターするには、テーブルを右クリックして WHERE 条件を指定します。「フィルター条件の設定」をご参照ください。

次へ：高度な設定 をクリックし、高度なオプションを構成します。

パラメーター	説明
データ検証設定	移行後にソースと送信先の間で一貫性を確認するため、データ検証を設定します。詳細については、「データ検証の設定」をご参照ください。
タスクのスケジュールに使用する専用クラスターの選択	デフォルトでは、DTS は共有クラスター上でタスクをスケジュールします。専用クラスターを使用する場合は、事前に購入しておく必要があります。詳細については、「DTS 専用クラスターとは
接続失敗時のリトライ時間	ソースまたは送信先に到達不能な状態が発生した場合に、DTS が再試行を続ける時間を設定します。有効値：10～1440 分。デフォルト：720。この値は少なくとも 30 分以上に設定してください。リトライ時間内に DTS が再接続できた場合、タスクは再開されます。それ以外の場合は、タスクは失敗します。説明複数のタスクで同じソースまたは送信先を共有している場合、最も最近設定された値が優先されます。リトライ時間は DTS インスタンスの課金対象となります。
ソースおよび送信先データベースでその他の問題が発生した場合のリトライ前の待機時間	DDL または DML の失敗後に DTS が再試行を続ける時間を設定します。有効値：1～1440 分。デフォルト：10。この値は少なくとも 10 分以上に設定し、かつ接続失敗時のリトライ時間の値より小さく設定してください。
完全データ移行のスロットリングを有効化	完全移行中に、秒間クエリ数 (QPS)、秒間リクエスト数 (RPS)、および移行速度 (MB/s) を制限して、送信先への負荷を軽減します。完全データ移行が選択されている場合のみ利用可能です。
増分データ移行のスロットリングを有効化	増分移行中に、RPS および移行速度 (MB/s) を制限します。増分データ移行が選択されている場合のみ利用可能です。
環境タグ	DTS インスタンスを環境（例：本番環境やステージング環境）ごとに識別するための任意のラベルです。
実際の書き込みコード	送信先にデータを書き込む際に使用されるエンコード形式です。送信先データベースの文字セットに基づいて選択してください。
ETL の設定	はいを選択すると、抽出・変換・書き出し (ETL) が有効になり、データ処理文を入力できます。詳細については、「データ移行またはデータ同期タスクでの ETL の設定」および「ETL とは
モニタリングとアラート機能	はいを選択すると、タスクが失敗した場合や移行遅延がしきい値を超えた場合にアラートを受け取れます。しきい値および通知設定を構成してください。詳細については、「DTS タスク作成時のモニタリングとアラートの設定」をご参照ください。

次へ：タスク設定の保存および事前チェック をクリックします。
DTS は、移行タスクを開始する前に事前チェック（precheck）を実行します。事前チェックが失敗した場合は、各失敗項目の横にある詳細の表示をクリックし、問題を解決したうえで再チェックをクリックしてください。無視可能なアラートが発生した場合は、アラートの詳細の確認をクリックし、詳細ダイアログで無視を選択したうえで、再度再チェックをクリックしてください。ただし、アラートを無視するとデータの不整合が発生する可能性があることにご注意ください。このタスク構成の OpenAPI パラメーターをプレビューするには、次へ：タスク設定の保存および事前チェック 上にカーソルを合わせて、OpenAPI パラメーターのプレビュー をクリックしてください。
事前チェックの成功率が100%になるまで待ち、その後次へ：インスタンスの購入 をクリックします。

インスタンスの購入 ページで、インスタンスクラスを構成します。

パラメーター	説明
リソースグループ設定項目	データ移行インスタンスのリソースグループです。デフォルト：デフォルトリソースグループ。詳細については、「What is Resource Management?
インスタンスクラス	インスタンスクラスは移行スループットを決定します。ご利用のワークロードに基づいて選択してください。詳細については、「Specifications of data migration instances」をご参照ください。

Data Transmission Service（従量課金）サービス規約 のチェックボックスをオンにします。
購入および開始 をクリックします。タスクリストでタスクの進行状況を監視します。

次のステップ

非表示のプライマリキーの削除（該当する場合）

非表示のプライマリキーを追加 オプションを有効化し、ワークロードを移行先クラスターに切り替えた後は、DTS インスタンスを終了またはリリースする前に、非表示のプライマリキーを削除してください。

タスクの詳細ページで、基本情報 タブに移動します（完全なデータ移行 または 増分書き込み モジュール内）。
操作列で、非表示のプライマリキーの削除 をクリックします。

重要

非表示のプライマリキーを削除した後は、ソースおよび移行先データベースのデータが同一であることを検証してください。

シーケンスの開始値の同期

ワークロードを切り替えた後、移行先で新たに書き込まれるシーケンスは、ソースの最大値から自動的に継続しません。前述の制限事項セクションで示した PL/SQL ブロックを実行して、ソースのシーケンスに対する setval 文を生成し、該当する文を移行先データベースで実行してください。