Data Transmission Service:Migrate data from a PolarDB for MySQL cluster to a self-managed Oracle database

High-impact limitations

Review these limitations before starting — they can cause task failure or data loss:

• Read-only nodes cannot be migrated. Only the primary node of the source PolarDB for MySQL cluster is supported.

• No DDL during schema migration or full data migration. If you run DDL operations that change database or table schemas on the source during these phases, the migration task fails.

• Do not write to the source during full-only migration. If you run schema migration and full data migration without incremental migration, writing to the source causes data inconsistency. To keep the source online, select all three migration types: schema migration, full data migration, and incremental data migration.

• Binary logging required for incremental migration. Binary logging must be enabled and loose_polar_log_bin must be set to on. If not configured, precheck fails. See Enable binary logging and Modify parameters. Required binary log retention: After full migration completes, you can reduce retention to more than 24 hours. Insufficient retention causes DTS to fail when fetching binary logs, which may result in task failure or data loss.

  Note

  Enabling binary logging on PolarDB for MySQL incurs storage charges for the binary log files.

  Migration type	Minimum retention period
  Incremental data migration only	More than 24 hours
  Full data migration + incremental data migration	At least 7 days

• Stop the migration task before switching workloads. DTS retries failed tasks for up to 7 days. If a failed task resumes after you switch workloads to the destination, it overwrites destination data with source data. Before switching, stop or release the migration task, or run REVOKE to remove write permissions from DTS accounts on the destination database.

Other limitations

• Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Without these constraints, the destination database may contain duplicate records.

• Table rename limit. If you select tables as migration objects and need to rename tables or columns in the destination, a single task supports up to 1,000 tables. For more than 1,000 tables, split the migration across multiple tasks or migrate the entire database instead.

• Oracle RAC over Express Connect, VPN Gateway, Smart Access Gateway, Database Gateway, Cloud Enterprise Network (CEN), or ECS: use a single VIP rather than a SCAN IP. Node failover is not supported after specifying the VIP.

• Migrate during off-peak hours to minimize performance impact. Full data migration uses read and write resources on both databases and increases server load.

• Destination tablespace grows after full migration. Concurrent INSERT operations during full migration cause table fragmentation. The destination tablespace will be larger than the source tablespace after full migration.

• FLOAT and DOUBLE precision. DTS uses ROUND(COLUMN, PRECISION) to retrieve FLOAT and DOUBLE values. Default precision: FLOAT uses 38 digits, DOUBLE uses 308 digits. Verify these settings meet your requirements before starting.

• Source server bandwidth. The source server must have sufficient outbound bandwidth. Insufficient bandwidth reduces migration speed.

Foreign key behavior

DTS migrates foreign keys during schema migration. During full data migration and incremental data migration, DTS temporarily disables foreign key constraint checks and cascade operations at the session level. If you perform cascade or delete operations on the source during migration, data inconsistency may occur.

Special case

DTS executes CREATE DATABASE IF NOT EXISTS \test\`` on the source database on a schedule to advance the binary log file position. This is expected behavior.

Step 1: Go to the Data Migration Tasks page

1. Log on to the Data Management (DMS) console.

2. In the top navigation bar, click DTS.

3. In the left-side navigation pane, choose DTS (DTS) > Data Migration.

Step 2: Select the region

From the drop-down list next to Data Migration Tasks, select the region where the data migration instance resides.

Step 3: Configure source and destination databases

Click Create Task and configure the following parameters.

Task settings

Source database

Destination database

Step 4: Test connectivity

Click Test Connectivity and Proceed.

DTS automatically adds its CIDR blocks to the IP address whitelist of Alibaba Cloud database instances and to the security group rules of ECS-hosted databases. For self-managed databases in a data center or on a third-party cloud, manually add the DTS CIDR blocks to your database whitelist. See Add the CIDR blocks of DTS servers.

Step 5: Configure migration objects and settings

Parameter	Description
Migration Types	Select Schema Migration and Full Data Migration for a one-time migration. Select Schema Migration, Full Data Migration, and Incremental Data Migration to keep services running during migration. Note Without incremental migration, do not write to the source database during migration.
Processing Mode of Conflicting Tables	Precheck and Report Errors: checks for tables with identical names in source and destination. The task fails precheck if conflicts exist. Use object name mapping to resolve conflicts — see Map object names. Ignore Errors and Proceed: skips the check. Data records with matching primary keys are not migrated. If schemas differ, only specific columns may be migrated or the task may fail.
Capitalization of Object Names in Destination Instance	Controls capitalization of database, table, and column names in the destination. Default: DTS default policy. See Specify the capitalization of object names in the destination instance.
Source Objects	Select objects from the Source Objects list and click to add them to Selected Objects. Select columns, tables, or databases. Selecting tables or columns excludes views, triggers, and stored procedures.
Selected Objects	To rename a database in the destination, right-click it and set Schema Name in the Edit Schema dialog box. To filter rows by condition, right-click a table and specify WHERE conditions. See Set filter conditions. To select specific SQL operations for a database or table, right-click the object and select the operations. Note Renaming an object may cause dependent objects to fail migration.

Step 6: Configure advanced settings

Click Next: Advanced Settings.

Data verification

To configure data verification, see Configure data verification.

Advanced settings

Step 7: Run a precheck

Click Next: Save Task Settings and Precheck.

To preview the API parameters for this task, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters before proceeding.

Step 8: Purchase the migration instance

Wait for the precheck success rate to reach 100%, then click Next: Purchase Instance.

On the Purchase Instance page, configure the instance class:

Step 9: Start the migration task

Select the Data Transmission Service (Pay-as-you-go) Service Terms check box, then click Buy and Start.

Monitor progress on the Task Management page.