Data Transmission Service:Migrate from RDS PPAS to PolarDB for Oracle

Prerequisites

• You must have an active PolarDB for PostgreSQL (Compatible with Oracle) cluster. For more information, see Create a PolarDB for PostgreSQL (Compatible with Oracle) cluster.

• Ensure that the PolarDB for PostgreSQL (Compatible with Oracle) cluster has more storage space than the data in the source ApsaraDB RDS for PPAS instance.

• If database, table, or column names in the source ApsaraDB RDS for PPAS instance contain uppercase letters, you must enclose them in double quotation marks ("") when creating them in the PolarDB for PostgreSQL (Compatible with Oracle) cluster.

• To perform incremental data migration, you must grant superuser permissions to the database account used for migration on the source ApsaraDB RDS for PPAS instance.

Usage notes

• During a full data migration, DTS consumes read and write resources on the source and destination databases, increasing their load. If your databases have poor performance, low specifications, or high workloads (for example, if the source database has many slow SQL queries or tables without primary keys, or if deadlocks occur in the destination database), the increased load can strain your databases or even cause service interruptions. Perform the data migration during off-peak hours, such as when the CPU utilization of both databases is below 30%.

• If a source table lacks a primary key or a unique constraint and contains non-unique data, duplicate data may be created in the destination database.

• A data migration task handles only one database at a time. To migrate multiple databases, create a separate task for each.

• DTS automatically attempts to resume a failed data migration task. To prevent an automatic resumption from overwriting data in the destination instance, stop or release the task before you perform a business switchover.

• Sequences in the destination database do not continue from the source maximum after switchover. Before switching, query each sequence's maximum value in the source and set it as the starting value in the destination. Query sequence values:

  do language plpgsql $$
  declare
    nsp name;
    rel name;
    val int8;
  begin
    for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
    loop
      execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
      raise notice '%',
      format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
    end loop;
  end;
  $$;

• When you migrate data from an ApsaraDB RDS for PPAS instance to a PolarDB for Oracle cluster, consider the following:

  • Ensure the PolarDB for Oracle cluster has specifications equal to or greater than those of the ApsaraDB RDS for PPAS instance. This prevents slow SQL queries or out-of-memory (OOM) errors that can be caused by insufficient CPU and memory resources in the PolarDB for Oracle cluster after the migration. For recommended specifications for the PolarDB for Oracle cluster, see Mapping between ApsaraDB RDS for PPAS specifications and recommended PolarDB for Oracle specifications.

  • If your business requires a specific number of connections or IOPS after migration, refer to and Compute node specifications to select a suitable PolarDB for Oracle cluster.

  • Use the cluster endpoint for your application connections to enable automatic read/write splitting. This routes read requests to read-only nodes and reduces the PolarDB for Oracle cluster load. For details on obtaining a cluster endpoint, see View or apply for an endpoint.

Mapping table for RDS PPAS and recommended PolarDB for PostgreSQL (Compatible with Oracle) cluster instance types

We recommend that the specifications of the PolarDB for Oracle cluster be greater than or equal to the RDS PPAS specifications to prevent slow SQL queries or OOM errors caused by insufficient CPU and memory in the PolarDB for Oracle cluster after migration.

Migration types

Billing

Database account permissions

Log on to the source and destination databases, create accounts for data migration, and grant the required permissions.

To create accounts and grant permissions for a PolarDB for PostgreSQL (Compatible with Oracle) cluster, see Create an account.

Procedure

1. Log on to the DTS console.

   Note

   If you are automatically redirected to the Data Management (DMS) console, you can click the icon in the lower-right corner and then click to return to the classic DTS console.

2. In the left-side navigation pane, click Data Migration.

3. At the top of the Migration Tasks page, select the region of the destination cluster.

4. In the upper-right corner of the page, click Create Data Migration Task.

5. Configure the connection settings for the source and destination databases.

   Category	Parameter	Description
   N/A	Task name	DTS automatically generates a task name. We recommend specifying a descriptive name for easy identification. The name does not need to be unique.
   Source database	Instance type	Because DTS does not directly support an RDS for PPAS instance as a source database, select self-managed database with Express Connect/VPN Gateway/Smart Access Gateway.
   	Region	Select the region where the RDS for PPAS instance is located.
   	VPC connected to the source database	Select the ID of the virtual private cloud (VPC) for the RDS for PPAS instance.
   	Database type	Select PPAS.
   	Version	Select the version of your RDS for PPAS instance.
   	IP address	Enter the private IP address of the RDS for PPAS instance.
   	Port	Enter the service port of the RDS for PPAS instance. The default port is 3433.
   	Database name	Enter the name of the database to migrate.
   	Database account	Enter the database account for the RDS for PPAS instance. For required permissions, see Database account permissions.
   	Database password	Enter the password for the database account. Note After you enter the source database information, you can click Test Connectivity next to Database Password to verify that the information is correct. If the information is correct, the message Passed is displayed. If the message Failed is displayed, click Diagnose next to the Failed message and adjust the source database information based on the prompts.
   Destination database	Instance type	Select PolarDB.
   	Region	Select the region of the destination PolarDB for Oracle cluster.
   	PolarDB instance ID	Select the ID of the destination PolarDB for Oracle cluster.
   	Database name	Enter the name of the destination database.
   	Database account	Enter the database account of the destination PolarDB for Oracle cluster. For required permissions, see Database account permissions.
   	Database password	Enter the password for the database account. Note After you enter the destination database information, you can click Test Connectivity after Database Password to verify that the entered information is correct. If the information is correct, a Passed message is displayed. If a Failed message is displayed, click Diagnose after Failed and adjust the destination database information based on the prompts.

6. After you complete the settings, click Set whitelist and next in the lower-right corner of the page.

   If the source or destination database is an Alibaba Cloud database instance (such as ApsaraDB RDS for MySQL or ApsaraDB for MongoDB), DTS automatically adds the IP addresses of DTS servers in the corresponding region to the instance's whitelist. If the database is a self-managed database on an ECS instance, DTS automatically adds the IP addresses to the security rules of the ECS instance. You must also ensure that the self-managed database allows access from the ECS instance. For database clusters on multiple ECS instances, manually add the DTS server IP addresses for the region to the security rules of each instance. If the database is a self-managed database in an on-premises data center or on another cloud, you must manually add the IP addresses of DTS servers in the corresponding region to allow access from DTS servers. For the IP addresses of DTS servers, see IP addresses of DTS servers.

   Warning

   Adding the public CIDR blocks of DTS servers, whether automatically or manually, may introduce security risks. By using this product, you acknowledge and accept these potential risks. You are responsible for implementing basic security measures, including but not limited to using strong passwords, restricting open ports, using authentication for internal API calls, regularly reviewing and restricting unnecessary network segments, or connecting through private networks such as Express Connect, VPN Gateway, or Smart Access Gateway.

7. Select the migration types and objects.

   Select the migration types based on your business requirements, and then move the objects to migrate to the Selected Objects list. DTS maps uppercase database names to lowercase by default. To preserve uppercase names, manually edit the mapped names in the Selected Objects list.

   Parameter	Description
   Migration types	If you need to perform only a full migration, select both Schema Migration and full data migration. If you need to perform a zero-downtime migration, select Schema Migration, full data migration, and incremental data migration. Important If you do not select incremental data migration, do not write new data to the source database during schema migration or full data migration to ensure data consistency. Do not perform DDL operations on the migration objects until the schema migration and full data migration are complete. Otherwise, the migration task may fail.
   Migration objects	In the Migration Objects box, click the objects that you want to migrate, and then click the icon to move them to the Selected Objects box. Note You can select objects at the database, table, or column level. By default, object names in the destination database are the same as in the source. To rename an object, use the object name mapping feature. For more information, see Object name mapping. If you use the object name mapping feature, the migration of dependent objects may fail.
   Edit mapped name	To rename a migration object in the destination database, use the object name mapping feature. For more information, see Object name mapping.
   Connection retry duration	By default, DTS retries the connection to the source or destination database for 12 hours. You can also specify a custom duration. If DTS reconnects within the specified period, the migration task automatically resumes. Otherwise, the task fails. Note You are charged for the DTS task during the connection retry period. We recommend specifying a custom duration based on your business needs, or releasing the DTS instance when the source and destination instances are released.

8. After you complete the configuration, click Precheck and Start in the lower-right corner of the page.

   Note

   • Before the migration task starts, DTS runs a precheck. The task can start only after it passes the precheck.

   • If the precheck fails, click the icon next to the failed item to view details.

     • Fix the issues as prompted and run the precheck again.

     • If you do not need to fix the warning items, you can select Ignore and then click Ignore Warnings and Rerun Precheck to run the precheck again.

9. After the task passes the precheck, click Next.

10. In the Confirm Settings dialog box that appears, select a Instance Class and select the Data Transmission Service (pay-as-you-go) Service Terms checkbox.

11. Click Buy and Start to begin the migration.

    • Schema migration + Full data migration

      Allow the task to complete automatically. Stopping it manually may result in incomplete data.

    • Schema migration + Full data migration + Incremental data migration

      The migration task does not stop automatically. You must stop it manually.

      Important

      Choose an appropriate time to stop the task manually, such as during off-peak hours or when you are ready to switch your business to the destination cluster.

      1. Wait until the migration task enters the Incremental Data Migration phase and the status shows Undelayed. Then, stop writing data to the source database for several minutes. During this time, the status of Incremental Data Migration may show a latency.

      2. Wait for the Incremental Data Migration status to show Undelayed again. Then, manually stop the migration task. Select the check box of the target migration task, and click Pause in the batch operation bar at the bottom of the page.