Data migration issues - Data Transmission Service - Alibaba Cloud Documentation Center

Q: After a data migration task is executed, does the data in the source database still exist?
A: DTS data migration and synchronization copy data from the source database to the destination database and do not affect the data on the source.
Q: Which database instances does DTS support for migration?
A: DTS supports data migration between various data sources, such as relational database management systems (RDBMSs), NoSQL databases, and online analytical processing (OLAP) databases. For the supported migration instances, see Migration scenarios
Q: How does data migration work?
A: For information about how data migration works, see Product architecture and feature principles.
Q: A data migration task remains in the Preparing state for a long time. Is DTS traversing files on the source?
A: Yes. After the task is created, DTS first sends a HEAD request to the source to probe the data, and then traverses all files on the source that need to be migrated. Data migration officially starts only after the traversal is complete. The Preparing phase does not display migration progress. Its duration depends on the volume of data on the source to be migrated and has no fixed estimate. After the traversal is complete, the task automatically enters the migration phase without any manual intervention.
Q: Can I modify the migration objects of a data migration task?
A: No.
Q: Can I add new tables for migration to a data migration task?
A: No.
Q: How do I modify the migration objects, such as tables and columns, of a running migration task?
A: A migration task does not support modifying its migration objects.
Q: If I suspend a migration task and then restart it after a period of time, will data inconsistency occur?
A: If the source database changes while the migration task is suspended, the data in the source database and the destination database may become inconsistent. After the migration task is restarted and the incremental data is migrated to the destination database, the data in the destination database becomes consistent with the source database.
Q: Can a migration task be converted into a synchronization task?
A: No. Different types of tasks cannot be converted to each other.
Q: Can I migrate only data without migrating the schema?
A: Yes. When you configure the migration task, do not select Schema Migration.
Q: What are the possible causes of data inconsistency between the source and destination of a data migration instance?
Possible causes of data inconsistency include the following:
1. When you configured the task, the destination was not cleared and already contained existing data.
2. When you configured the task, only the incremental migration module was selected, and the full migration module was not selected.
3. When you configured the task, only the full migration module was selected, the incremental migration module was not selected, and the source data changed after the task ended.
4. Data other than that from the DTS task is being written to the destination.
5. Incremental writes are delayed, and not all incremental data has been written to the destination.
Q: Can I modify the name of the source database in the destination database for a data migration task?
A: Yes. For information about how to modify the name of the source database in the destination database, see Object name mapping.
Q: Does DTS support data migration within the same instance?
A: Yes. For information about how to perform data migration within the same instance, see Synchronize or migrate data between databases of different names.
Q: Does DTS support real-time migration of DML or DDL operations?
Yes. For data between relational databases, the supported DML operations are INSERT, UPDATE, and DELETE, and the supported DDL operations are CREATE, DROP, ALTER, RENAME, and TRUNCATE.
Note
The supported DML or DDL operations vary in different scenarios. In Migration scenarios, select the link that matches your business scenario and view the supported DML or DDL operations in the configuration document of that specific link.
Q: Can a read-only instance be used as the source instance of a migration task?
If the migration task does not require incremental data migration, a read-only instance can be used as the source instance. If the migration task requires incremental data migration, the following two situations apply:
- A read-only instance that records transaction logs (such as ApsaraDB RDS for MySQL 5.7 or 8.0) can be used as the source instance.
- A read-only instance that does not record transaction logs (such as ApsaraDB RDS for MySQL 5.6) cannot be used as the source instance.
Q: Does DTS support data migration for sharded databases and tables?
A: Yes. For example, you can migrate sharded databases and tables from MySQL or PolarDB for MySQL to AnalyticDB for MySQL to merge multiple tables into one.
Q: Does a migration task support filtering some columns or data?
A: Yes. You can use the mapping feature to filter out columns that do not need to be migrated, and use SQL WHERE conditions to filter the data to be migrated. For more information, see Synchronize or migrate specific columns and Filter the data to be migrated.
Q: Why is the amount of data on the destination instance smaller than on the source instance after the migration task ends?
A: If data was filtered during migration, or if there are many table fragments in the source instance, the amount of data on the destination instance may be smaller than on the source instance after migration is complete.
Q: Why does the completed value shown by the migration task exceed the total?
A: The displayed total is an estimated value. After the migration task is complete, the total is adjusted to the accurate value.
Q: What is the purpose of the increment_trx table added to the destination database during data migration?
A: During data migration, an increment_trx table is added to the destination database. This is a checkpoint table that DTS creates in the destination instance for incremental migration. It is used to record the checkpoint of the incremental migration and to support resumable transfer after an abnormal task restart. Do not delete this table during migration. Otherwise, the migration fails.
Q: Does a data migration task support resumable transfer during the full data migration phase?
A: Yes. If you suspend the task during the full data migration phase and then restart it, the task resumes from where it left off and does not need to start over.
Q: How do I migrate a non-Alibaba Cloud instance to Alibaba Cloud?
A: For information about how to migrate a non-Alibaba Cloud instance to Alibaba Cloud, see Migrate data from a third-party cloud to Alibaba Cloud.
Q: How do I migrate an on-premises Oracle database to PolarDB?
A: For information about how to migrate an on-premises Oracle database to PolarDB, see Migrate self-managed Oracle to PolarDB for PostgreSQL (Compatible with Oracle).
Q: Can I suspend a data migration task that has not completed the full data migration phase?
A: Yes.
Q: How do I migrate a subset of data from ApsaraDB RDS for MySQL to a self-managed MySQL database?
A: When you configure the migration task, you can select the objects to be migrated in Source Objects or filter them in Selected Objects based on your needs. Migration between MySQL databases is similar. You can refer to Migrate self-managed MySQL to RDS for MySQL to perform the operation.
Q: How do I migrate between RDS instances under the same Alibaba Cloud account?
A: DTS supports migration and synchronization between RDS instances. For the configuration procedure, see the relevant configuration document in Migration scenarios.
Q: An IOPS alert is triggered on the source database immediately after the migration task starts. How can I keep the workloads on the source database stable?
When a DTS task is running, if the load on the source database instance is heavy, you can use one of the following three methods to reduce the impact of the DTS task on the source database:
1. Upgrade the specifications of the source database instance.
2. Suspend the DTS task first, and then restart it after the load on the source database decreases.
3. Lower the rate of the DTS task. For information about how to adjust the rate, see Adjust the rate of a full migration.
Q: Why can a data migration task not select a database named test?
A: DTS data migration does not support migrating system databases. Select a business database that you have created for migration.
Q: Why is no latency displayed for a migration instance whose source database is PolarDB-X 1.0?
A: An instance whose source database is PolarDB-X 1.0 runs a distributed task, and the metrics that DTS monitors only exist in subtasks. Therefore, no latency information is displayed for instances whose source is PolarDB-X 1.0. You can click the instance ID and view the latency information under Task Management > Subtask Details of the instance.
Q: Why can DTS not migrate a MongoDB database?
A: The database to be migrated may be local or admin. DTS does not support using MongoDB admin or local as the source or destination database.
Q: Why does a many-to-one migration task report the DTS-071001 error?
A: This may occur because an Online DDL operation was performed on the source database while the many-to-one migration task was running, which modified the source database schema (such as tables), but the corresponding changes were not manually applied to the destination database.
Q: I failed to add a whitelist when configuring a task in the previous version of the console. How do I resolve this issue?
A: Configure the task in the new version of the console.
Q: During DTS data migration, a DDL operation was performed on the source database and caused the task to fail. How do I resolve this issue?
A: Manually execute the same DDL statement on the destination based on the DDL that was performed on the source database, and then restart the task. During data migration, do not use tools such as pt-online-schema-change to perform online DDL changes on the migration objects in the source database. Otherwise, the migration fails. If no data other than that from DTS is being written to the destination database, you can use Data Management (DMS) to perform online DDL changes.
Q: During DTS data migration, a DDL operation was performed on the destination database and caused the task to fail. How do I resolve this issue?
A: If a database or table in the destination database is deleted during incremental migration performed by DTS, the task becomes abnormal. You can reconfigure the task and exclude the database or table that caused the failure from the migration objects.
Q: Can a migration task be recovered after it is released? Can data consistency be ensured by reconfiguring the task?
A: A migration task cannot be recovered after it is released. When you reconfigure the task, if you do not select Full Data Migration, the data added between the time when the task is released and the time when the new task starts cannot be migrated to the destination database, and data consistency cannot be ensured. If your business has strict accuracy requirements for the data, you can delete the data on the destination database, reconfigure the migration task, and select Schema Migration, Incremental Data Migration, and Full Data Migration together in Task Stages.
Q: A DTS full data migration task has made no progress for a long time. How do I resolve this issue?
A: If the tables to be migrated have no primary keys, full data migration is very slow. We recommend that you add primary keys to the tables to be migrated in the source database before you perform migration.
Q: When migrating data for tables with the same name, does DTS support transferring source table data only when the corresponding data does not exist in the destination table?
A: Yes. When you configure the task, you can set Processing Mode of Conflicting Tables to Ignore Errors and Proceed. When the table schemas are consistent, if the destination database encounters a record with the same primary key value as one in the source database during full data migration, the record in the source database is not migrated to the destination database.
Q: How do I configure a cross-account migration task?
A: You must first understand Scenarios for cross-account tasks, then use the Alibaba Cloud account to which the database instance belongs to Configure RAM authorization for cross-account DTS tasks, and finally Configure a cross-account DTS task.
Q: How does a data migration task connect to an on-premises database?
A: You can configure the migration task by setting Access Method of the on-premises database to Public IP Address. For an example procedure, see Migrate self-managed MySQL to RDS for MySQL.
Q: Data migration fails with the DTS-31008 error. How do I resolve this issue?
A: You can click View Cause or find the solution in Overview of Common Errors based on the error message.
Q: The network is unreachable when I use Express Connect to access a self-managed database. How do I resolve this issue?
A: Check whether the Express Connect circuit is correctly configured with the DTS-related IP address whitelist. For the list of IP addresses to add to the whitelist, see Whitelist DTS IP ranges for your user-created database.
Q: For a migration task whose source is SQL Server, does DTS support migrating functions?
A: No. If the granularity of the selected migration objects is table, other objects (such as views, triggers, and stored procedures) are not migrated to the destination database either.
Q: DTS full data migration is slow. How do I resolve this issue?
A: The volume of data to be migrated may be large. Please wait patiently. You can go to the task details page and view the migration progress in the Full Data Migration module under Task Management.
Q: The task reports an internal error. How do I resolve this issue?
A: You can join the DTS Customer Communication DingTalk group (Group ID: 116655009709) on DingTalk (download the client) for assistance.
Q: Schema migration returns an error. How do I resolve this issue?
A: Click the instance ID to go to the task details page, view the specific error message of the schema migration module in Task Management, and then troubleshoot the issue based on the error message. For solutions to common errors, see Overview of Common Errors.
Q: Are schema migration and full data migration billed?
A: No. For more information about billing, see Billable items.
Q: In a data migration task between Redis databases, will the zset data on the destination be overwritten?
A: Yes. The zset on the destination is overwritten. If a key that already exists on the destination is the same as one on the source, DTS first deletes the zset of the corresponding key on the destination, and then uses zadd to add each object in the zset collection on the source to the destination.
Q: What is the impact of full data migration on the source database?
A: In DTS full data migration, data is first sharded, and then the data within each shard is read and written. During sharding, the IOPS of the source database increases. During reading of the data within each shard, some impact is exerted on the IOPS, CachePool, and outbound bandwidth of the source database. Based on DTS practices, these impacts are negligible.
Q: When PolarDB-X 1.0 is used as the source, does the source PolarDB-X 1.0 instance of the migration task support scaling nodes in or out?
A: No. If node scaling occurs on the source PolarDB-X 1.0 instance, you must reconfigure the task.
Q: Can DTS guarantee data uniqueness when migrating data to Kafka?
A: No. Because data written to Kafka is appended, duplicate data may occur when the DTS task is restarted or when logs from the source are pulled repeatedly. DTS guarantees data idempotency, which means that data is arranged in order and the latest value of the duplicate data is placed at the end.
Q: If I configure a full data migration task first and then an incremental data migration task, will data inconsistency occur?
A: Data inconsistency may occur. When only incremental data migration is configured for a migration task, data migration starts only after the incremental migration task starts. Before the incremental migration task starts, the incremental data generated on the source instance is not synchronized to the destination instance. If you need to perform migration without downtime, we recommend that you select schema migration, full data migration, and incremental data migration as the migration types when you configure the task.
Q: Do I need to select schema migration when I configure an incremental migration task?
A: Schema migration migrates the definitions of the migration objects to the destination instance before data migration starts. For example, it migrates the table definition of Table A to the destination instance. If you need to perform incremental migration, to ensure data consistency, we recommend that you select schema migration, full data migration, and incremental data migration together.
Q: Why does the RDS instance use more storage space than the source database when a self-managed database is migrated to RDS?
A: DTS performs logical migration. It encapsulates the data to be migrated into SQL statements and then migrates them to the destination RDS instance. During this process, binlog data is generated on the destination RDS instance. Therefore, during migration, the storage space used by the RDS instance may be larger than that of the source database.
Q: Does DTS support migration for MongoDB databases in a VPC?
A: Yes. DTS supports using ApsaraDB for MongoDB in a VPC as the source database of a migration.
Q: What happens to the migrated data if the source database changes during data migration?
A: If the migration task is configured with schema migration, full data migration, and incremental data migration, all data changes on the source database during migration are migrated to the destination database by DTS.
Q: Does releasing a completed migration task affect the use of the databases involved in the migration?
A: No. After the migration task is complete (when Status is Completed), you can safely release the migration task.
Q: Does DTS support incremental migration for MongoDB?
A: Yes. For related configuration examples, see Migration scenarios.
Q: What is the difference between using an RDS instance as the source of a migration task and using a self-managed database instance that is accessed over the Internet?
A: If you select an RDS instance when you configure the migration task, when the RDS instance undergoes changes such as DNS modifications or a network type switch, the DTS migration task can adapt automatically, which effectively ensures the reliability of the link.
Q: Does DTS support migrating a self-managed database on an ECS instance in a VPC to an RDS instance?
Yes.
- If the source ECS instance and the destination RDS instance reside in the same region, DTS can directly access the self-managed database on the ECS instance within the VPC.
- If the source ECS instance and the destination RDS instance reside in different regions, you must associate an elastic IP address (EIP) with the ECS instance. When you configure the migration task, select the ECS instance as the source instance. DTS automatically uses the EIP of the ECS instance to access the database on the ECS instance.
Q: Does DTS lock tables during migration? Is there any impact on the source database?
A: DTS does not lock tables on the source database during either full data migration or incremental data migration. During full and incremental data migration, the data tables on the source can still be read from and written to as normal.
Q: When DTS migrates data for an RDS instance, does it pull data from the primary or the secondary instance?
A: When DTS performs data migration, it pulls data from the primary instance of the RDS instance.
Q: Does DTS support scheduled automatic migration?
A: DTS does not currently support scheduling the start of data migration tasks.
Q: Does DTS support data migration for RDS instances in VPC mode?
A: Yes. When you configure the migration task, specify the RDS instance ID directly.
Q: When DTS performs migration or synchronization within the same account or across accounts, does it use the internal network or the Internet for ECS and RDS instances? Are traffic fees charged?
When DTS runs a synchronization or migration task, the type of network used (internal network or Internet) is not related to whether the task is cross-account. Whether traffic fees are charged depends on the task type.
- Network used
  - Migration task: For data migration within the same region, DTS uses the internal network to connect to ECS and RDS instances. For cross-region migration, DTS uses the Internet to connect to the source instance (ECS or RDS) and uses the internal network to connect to the destination RDS instance.
  - Synchronization task: The internal network is used.
- Traffic fees
  - Migration task: Outbound Internet traffic fees are charged. No traffic fees are charged for DTS instances of other types. Outbound Internet traffic fees refer to the traffic fees generated when Access Method of the destination database instance is Public IP Address.
  - Synchronization task: No traffic fees are charged.
Q: When I use DTS for data migration, will the data in the source database be deleted after migration?
A: No. When DTS performs data migration, it copies the data from the source database to the destination database and does not affect the data in the source database.
Q: When DTS performs data migration between RDS instances, can I specify the name of the destination database?
A: Yes. When you perform data migration between RDS instances, you can use the database name mapping feature provided by DTS to specify the name of the destination database. For more information, see Synchronize or migrate data between databases of different names.
Q: The source of a DTS migration task cannot connect to an ECS instance. How do I resolve this issue?
A: The ECS instance may not have a public IP address enabled. Associate an elastic IP address (EIP) with the ECS instance and try again. For information about how to associate an EIP, see EIP.
Q: Why does a migration task between Redis databases not display full data migration?
A: Migration between Redis databases supports both full data migration and incremental data migration, which are combined and displayed as Incremental Data Migration.
Q: Can full data migration be skipped?
A: Yes. After you skip full data migration, incremental migration continues. However, errors may occur. We recommend that you do not skip full data migration.
Q: Does the cluster edition of Redis support access to DTS over the Internet?
A: No. Currently, only the standalone edition of Redis supports access to DTS migration instances over the Internet.
Q: What should I pay attention to when migrating data from MySQL 8.0 to MySQL 5.6?
A: You must create the databases in MySQL 5.6 before you perform the migration. We recommend that you keep the source and destination database versions the same, or migrate from a lower version to a higher version to ensure compatibility. Migrating from a higher version to a lower version may cause database compatibility issues.
Q: Can I migrate the accounts in the source database to the destination database?
A: Currently, only migration tasks between ApsaraDB RDS for MySQL instances support migrating accounts. Other migration tasks do not support this.
Q: How do I configure parameters when ApsaraMQ for Kafka is the destination?
A: Configure the parameters based on your actual scenario. For information about how to configure some special parameters, see Configure Kafka instance parameters.
Q: How do I perform scheduled full data migration?
A: You can use the scheduling policy configuration of the Data Integration feature to periodically migrate the schema and the existing data from the source database to the destination database. For more information, see Configure a data integration task between RDS for MySQL instances.
Q: Does DTS support migrating a self-managed SQL Server on an ECS instance to a self-managed SQL Server in an on-premises data center?
A: Yes. The self-managed SQL Server in the on-premises data center must be connected to Alibaba Cloud. For more information, see Preparation overview.
Q: Does DTS support migrating a PostgreSQL database from another cloud?
If the PostgreSQL database on another cloud is configured to allow DTS to access it over the Internet, you can use DTS to migrate the data.
Note
If the PostgreSQL version is earlier than 10.0, incremental migration is not supported.
Q: Does DTS support migrating data from MySQL to Mycat?
A: Yes. You can connect Mycat to Alibaba Cloud as a self-managed MySQL database, and then use DTS to migrate the data.
Q: During data migration, does DTS support incremental migration of DDL operations?
A: This is supported in some migration scenarios. For more information, see Usage notes and limits for data migration.
Q: Triggers (TRIGGER) are missing in the destination database after migration
- Cause: The source database account used by the DTS task lacks the EVENT privilege, or lacks the SELECT privilege on the information_schema.TRIGGERS table. As a result, DTS cannot read the trigger metadata and skips trigger synchronization.
- Solution:
  - Method 1: After you confirm that the source database account has been granted the required privileges (the EVENT privilege and the SELECT privilege on the information_schema.TRIGGERS table), rerun schema migration.
  - Method 2: Manually create the missing triggers in the destination database.
Note
DTS generally does not recommend configuring trigger migration, because triggers executed on the destination may cause data inconsistency. If you have no special requirements, we recommend that you exclude trigger objects in the DTS task configuration.
Q: Description of automatic conversion of the DEFINER attribute when migrating stored procedures
A: When DTS migrates stored procedures, it automatically converts the DEFINER attribute of the source stored procedure to the destination database account and changes the SQL SECURITY mode to INVOKER. This is a standardized behavior that is designed to ensure that the migrated stored procedures can be executed properly within the permission scope of the destination database account.
- If this conversion causes a schema verification error but the functionality of the stored procedure itself is not affected, you can choose to ignore the error.
- If your business needs to restore the original DEFINER attribute on the destination, you must manually delete the stored procedure on the destination and then re-create it by using an account that has the required privileges.
Q: What is the impact of modifying data in the destination database while a data synchronization or migration task is running?
- Modifying data in the destination database may cause the DTS task to fail. During data migration or synchronization, performing operations on the objects that are being migrated or synchronized in the destination database may cause issues such as primary key conflicts or missing update records, which ultimately cause the DTS task to fail. However, you can perform operations that do not interrupt the DTS task. For example, if you create a table in the destination instance and write data to it, the DTS task is not affected because the table is not included in the migration or synchronization objects.
- Because DTS reads information from the source instance database and migrates or synchronizes its full data, schema data, and incremental data to the destination instance, data modifications made to the destination database during the task may be overwritten by data migrated or synchronized from the source database.
Q: Does DTS support cross-account data migration or data synchronization?
A: Yes. For information about how to configure it, see Configure a cross-account DTS task.
Q: Can data be written to the source database and the destination database at the same time while a data synchronization or migration task is running?
A: Yes. However, while the DTS instance is running, if data sources other than DTS write data to the destination database, exceptions may occur in the destination database data or in the DTS instance.
Q: Does DTS support sampling data synchronization or migration by time range?
A: No.
Q: When synchronizing or migrating data, do I need to manually create tables in the destination database?
A: For DTS instances that support schema tasks (schema synchronization or schema migration), if you have configured a schema task (Synchronization Types with Schema Synchronization selected, or Migration Types with Schema Migration selected), you do not need to manually create tables in the destination database.
Q: When synchronizing or migrating data, do the source database and the destination database need to be connected over the network?
A: No.
Q: How do I use the API to configure the ETL feature for a synchronization or migration task?
A: You can configure it in the Reserve parameter of the API by using common parameters such as etlOperatorCtl and etlOperatorSetting. For more information, see ConfigureDtsJob and Reserve parameter reference.
Q: Is data in the source database retained after DTS synchronization or migration ends?
A: Yes. DTS does not delete data in the source database. If you do not need to retain the data in the source database, delete it manually.
Q: Can I adjust the rate after a synchronization or migration instance is running?
A: Yes. For more information, see Enable throttling for data migration.
Q: An incremental synchronization error indicates that the packet is too large or the max_allowed_packet value at the destination is insufficient. How do I resolve this?
- Cause:
  The source contains a row with a large amount of data that exceeds the limit of the max_allowed_packet parameter at the destination during incremental synchronization, causing the synchronization error.
- Solution:
  1. Log on to the source database and query the current value of the max_allowed_packet parameter:
```
SHOW VARIABLES LIKE 'max_allowed_packet';
```
    Record the value (for example, 1073741824, which is 1 GB).
  2. Log on to the ApsaraDB RDS console (or the PolarDB console if the destination is PolarDB for MySQL). On the Parameters page of the destination database instance, set the max_allowed_packet parameter to a value that is no less than the value at the source.
  3. After the parameter modification is complete, restart the synchronization task in the DTS console and verify whether synchronization returns to normal.
Q: The synchronization task has been interrupted for several hours, and I suspect that an MDL lock exists at the destination. How do I resolve this?
- Cause:
  A metadata lock (MDL lock) at the destination, caused by a long-running DDL operation (such as adding a column to a large table or rebuilding an index), is blocking the incremental data writes from DTS, causing the synchronization link to be interrupted for a long time.
- Solution:
  1. Log on to the ApsaraDB RDS console, go to the destination database instance, and run SHOW FULL PROCESSLIST to locate the abnormal session that holds the MDL lock. Then, kill the session.
  2. Log on to the DTS console and modify the synchronization objects to remove the tables that are affected by the MDL lock from the synchronization scope.
  3. Drop the table in the destination database (before this operation, make sure that the data has been backed up or can be cleared).
  4. After the DTS synchronization task returns to normal and the synchronization latency drops to zero, modify the synchronization objects again to add the table back to the synchronization scope and complete the re-migration.
Q: An incremental synchronization error indicates that a temporary table is missing in the destination database or that a SELECT INTO conflict occurs. How do I resolve this?
- Cause:
  This issue is not actually caused by a missing temporary table in the destination database. Instead, after Change Data Capture (CDC) is enabled in the source database, the triggers created by DTS intercept the implicit table creation performed by SELECT INTO, which causes conflicts during data synchronization.
- Solution:
  1. Verify that the transaction log file at the source exists and is intact.
  2. Disable the CDC feature in the source database.
  3. Log on to the DTS console, reconfigure the synchronization task, select Parse source database logs as the incremental synchronization method, and then restart the task.
Q: When you use DTS for data synchronization or migration, is existing data at the destination overwritten?
A: Taking data synchronization as an example, the default behavior and related parameters of DTS are as follows:
Default behavior of DTS: If a primary key or unique key conflict occurs while the synchronization task is running:
- If the table schemas are consistent and a record in the destination database has the same primary key or unique key value as a record in the source database:
  - During full data synchronization, DTS retains the destination record and skips the source record.
  - During incremental synchronization, DTS overwrites the destination record with the source record.
- If the table schemas are inconsistent, data initialization may fail. This can result in only partial data synchronization or a complete synchronization failure. Use with caution.
Related parameters: When you configure a task, you can use the Processing Mode of Conflicting Tables parameter to manage how the related data is processed.
- Precheck and Report Errors: Checks for tables with the same names in the destination database. If any tables with the same names are found, an error is reported during the precheck and the data synchronization task does not start. Otherwise, the precheck is successful.
  Note
  If you cannot delete or rename the table with the same name in the destination database, you can map it to a different name in the destination. For more information, see Object name mapping.
- Ignore Errors and Proceed: Skips the check for tables with the same name in the destination database.
  Warning
  Selecting Ignore Errors and Proceed may cause data inconsistency and put your business at risk. For example:
  If the table schemas are consistent and a record in the destination database has the same primary key or unique key value as a record in the source database:
  During full data synchronization, DTS retains the destination record and skips the source record.
  During incremental synchronization, DTS overwrites the destination record with the source record.
  If the table schemas are inconsistent, data initialization may fail. This can result in only partial data synchronization or a complete synchronization failure. Use with caution.
Recommendation: To ensure data consistency, we recommend that you delete the destination table before configuring the DTS task, if your business allows.