Category | Description |
Source database limits | Bandwidth: The source database server must have sufficient outbound bandwidth. Insufficient bandwidth slows the migration. Tables to be migrated must have primary keys or UNIQUE constraints with unique field values. Otherwise, the destination database may contain duplicate data. If you migrate at the table level with edits such as column name mapping, a single task supports up to 1,000 tables. Exceeding this limit causes a request error. Split the tables into multiple tasks or migrate the entire database instead. Incremental migration requires the following data log settings: Data logging must be enabled. Otherwise, the precheck fails and blocks the task from starting. DTS requires source data logs to be retained for more than 24 hours for incremental migration, or at least 7 days for full-plus-incremental migration. After full migration completes, you can reduce the retention to more than 24 hours. If retention is too short, DTS may fail to read data logs, causing task failure or, in extreme cases, data inconsistency or loss. Issues caused by insufficient log retention are not covered by the DTS SLA.
Limits on operations in the source database: During full migration, do not perform DDL operations that change database or table schemas. Otherwise, the task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination databases. To maintain real-time consistency, select both full and incremental migration.
The Change Data Capture (CDC) property must be enabled for the tables to be migrated.
|
Other limits | DTS migrates incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, CDC replication has its own limits. General data restrictions for SQL Replication. Evaluate source and destination database performance before starting migration. Migrate during off-peak hours because full migration consumes read and write resources on both databases, increasing load. Full migration uses concurrent INSERT operations that cause table fragmentation. After full migration, tables in the destination database use more storage space than in the source. Verify that the DTS migration precision for FLOAT or DOUBLE columns meets your requirements. DTS reads these columns using the ROUND(COLUMN,PRECISION) function. Default precision: 38 for FLOAT, 308 for DOUBLE. DTS attempts to recover failed tasks for up to seven days. Before switching your workload to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke write permissions from the DTS account on the destination instance. This prevents a recovered task from overwriting destination data. -
If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.
Note
Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.
-
If the destination PolarDB-X 2.0 table has auto partitioning enabled (auto_partition=true), each DDL statement executed on the source can contain only one alter_specification. Otherwise, DTS reports an error (TDDL-4998: Multi alter specifications when create GSI not support yet). To execute a DDL statement that contains multiple alter_specification items, split each alter_specification into a separate DDL statement and execute them one by one. For more information, see ALTER TABLE (DRDS mode) and ALTER TABLE (AUTO mode).
|
Special cases | Because the source Db2 for LUW database is self-managed: If a primary/secondary switchover occurs on the source database during migration, the migration task fails. DTS calculates migration latency by comparing the timestamp of the last migrated entry with the current time. If no DML operations run on the source for a long time, the displayed latency may be inaccurate. To update it, perform a DML operation on the source database.
Note For full database migration, you can create a heartbeat table that receives writes at regular intervals (for example, every second) to keep latency readings accurate.
|