This topic describes the precautions and limits when you migrate data from a Teradata database. To ensure that your data migration task runs as expected, read the precautions and limits before you configure the task.
Migrate data from a Teradata database to an AnalyticDB for PostgreSQL instance
The following are the precautions and limits:
Category | Description |
Limits on the source database | Bandwidth requirements: The server of the source database must have sufficient egress bandwidth. Otherwise, the data migration speed is affected. The tables to be migrated must have a primary key or a UNIQUE constraint. The values in the constrained columns must be unique. Otherwise, the destination database may contain duplicate data. If you select tables as migration objects and need to edit them, such as by mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, a request error is reported after you submit the task. In this case, split the tables into multiple tasks, or configure a task to migrate the entire database. Limits on operations: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the database or table schemas. Otherwise, the data migration task fails. This scenario does not support incremental data migration. To ensure data consistency, do not write new data to the source instance during data migration.
|
Other limits | This scenario is supported only in the China (Shanghai), China (Qingdao), and China (Zhangjiakou) regions. Only table-level migration is supported. Append-optimized (AO) tables are not supported as destination tables. When you use column mapping, if you do not migrate the full table or if the source and destination table schemas differ, data from columns that are missing in the destination table is lost. This scenario supports schema migration and full data migration. Incremental data migration is not supported. If a table to migrate has a primary key, the primary key column in the destination table must be the same as in the source table. If a table to migrate does not have a primary key, the primary key column in the destination table must be the same as the distribution key. The unique key, including the primary key column, of the destination table must contain all columns of the distribution key. Before migrating data, evaluate the performance of the source and destination databases. Migrate data during off-peak hours. During a full data migration, Data Transmission Service (DTS) consumes read and write resources on both the source and destination databases. This may increase the load on the database servers. During a full data migration, concurrent INSERT operations cause fragmentation in the destination database tables. After the full data migration is complete, the storage space used by the destination tables is larger than that of the source tables. Confirm that the migration precision for FLOAT or DOUBLE columns meets your business requirements. DTS uses the ROUND(COLUMN,PRECISION) function to read values from these columns. If you do not specify a precision, DTS uses a precision of 38 for FLOAT and 308 for DOUBLE. DTS attempts to resume data migration tasks that failed within the last seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, run the revoke command to revoke the write permissions from the account that DTS uses to access the destination instance. This prevents the source data from overwriting the destination data if the task is automatically resumed. If the task fails, DTS technical support will attempt to recover it within 8 hours. During the recovery process, operations such as restarting the task or adjusting its parameters may be performed.
Note When parameters are adjusted, only DTS task parameters are modified. Database parameters remain unchanged.The parameters that may be modified include but are not limited to those described in Modify instance parameters.
|