Data Transmission Service:Precautions and limits for synchronizing data from an Oracle database

Category

Description

Limits on the source database

• Requirements for the objects to be synchronized:

  • The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.

  • If the version of your Oracle database is 12c or later, the names of the tables to be synchronized cannot exceed 30 bytes in length.

  • If you select tables as the objects to be synchronized and you want to edit the tables in the destination database, such as renaming tables or columns, you can synchronize up to 1,000 tables in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• If the source database is an Oracle Real Application Cluster (RAC) database connected over Express Connect, you must specify a virtual IP address (VIP) for the database when you configure the data synchronization task.

• If the self-managed Oracle database is an Oracle RAC database, you can use only a VIP rather than a Single Client Access Name (SCAN) IP address when you configure the data synchronization task. After you specify the VIP, node failover of the Oracle RAC database is not supported.

• The redo logging and archive logging features must be enabled.

  Note

  If you perform only incremental data synchronization, the redo logs and archive logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the redo logs and archive logs of the source database must be stored for at least seven days. Otherwise, Data Transmission Service (DTS) may fail to obtain the redo logs and archive logs, which causes the task to fail, or even data inconsistency or data loss. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of redo logs and archive logs based on the preceding requirements. Otherwise, the service level agreement (SLA) of DTS does not guarantee service reliability or performance.

• If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.

• The data synchronization task fails if the source database contains an empty string of the VARCHAR2 type and the corresponding column in the destination database has a NOT NULL constraint. Empty strings of the VARCHAR2 type are processed as null values in Oracle databases.

• During data synchronization, do not update LONGTEXT fields. Otherwise, the data synchronization task fails.

Other limits

• DTS supports initial schema synchronization for the following types of objects: table, index, constraint, function, sequence, and view.

  Warning

  DTS does not ensure that the schemas of the source and destination databases are consistent after initial schema synchronization. We recommend that you evaluate the impact of data type conversion on your business. For more information, see Data type mappings for schema synchronization.

• Triggers cannot be synchronized. We recommend that you delete the triggers of the source database to prevent data inconsistency caused by triggers. For more information about how to synchronize triggers, see Configure a data synchronization task for a source database that contains a trigger.

• For partitioned tables, DTS discards the partition definitions. You must define partitions in the destination database.

• You can select only tables as the objects to be synchronized. The tables cannot be append-optimized (AO) tables.

• If column mapping is used for non-full table synchronization or if the source and destination table schemas are inconsistent, the data is lost for the columns that are not contained in the tables of the destination database.

• Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During initial full data synchronization, DTS uses the read and write resources of the source and destination databases. This may increase the loads of the database servers.

• During initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After initial full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.

• DTS calculates the synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for an extended period of time, the synchronization latency may be inaccurate. If the synchronization latency is too high, you can perform a DML operation on the source database to update the latency.

  Note

  If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

• During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use Data Management (DMS) to perform online DDL operations.

Category

Description

Limits on the source database

• Requirements for the objects to be synchronized:

  • The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.

  • If the version of your Oracle database is 12c or later, the names of the tables to be synchronized cannot exceed 30 bytes in length.

  • If you select tables as the objects to be synchronized and you want to edit the tables in the destination database, such as renaming tables or columns, you can synchronize up to 1,000 tables in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• If the source database is an Oracle RAC database connected over Express Connect, you must specify a VIP for the database when you configure the data synchronization task.

• If the self-managed Oracle database is an Oracle RAC database, you can use only a VIP rather than a Single Client Access Name (SCAN) IP address when you configure the data synchronization task. After you specify the VIP, node failover of the Oracle RAC database is not supported.

• The redo logging and archive logging features must be enabled.

  Note

  If you perform only incremental data synchronization, the redo logs and archive logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the redo logs and archive logs of the source database must be stored for at least seven days. Otherwise, Data Transmission Service (DTS) may fail to obtain the redo logs and archive logs, which causes the task to fail, or even data inconsistency or data loss. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of redo logs and archive logs based on the preceding requirements. Otherwise, the service level agreement (SLA) of DTS does not guarantee service reliability or performance.

• If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.

• The data synchronization task fails if the source database contains an empty string of the VARCHAR2 type and the corresponding column in the destination database has a NOT NULL constraint. Empty strings of the VARCHAR2 type are processed as null values in Oracle databases.

• During data synchronization, do not update LONGTEXT fields. Otherwise, the data synchronization task fails.

Other limits

• DTS does not synchronize the data in a renamed table to the destination Kafka cluster. This applies if the new table name is not included in the objects to be synchronized. To synchronize the data in a renamed table to the destination Kafka cluster, you must reselect the objects to be synchronized. For more information, see Add an object to a data synchronization task.

• Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During initial full data synchronization, DTS uses the read and write resources of the source and destination databases. This may increase the loads of the database servers.

• During initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After initial full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.

• DTS calculates the synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for an extended period of time, the synchronization latency may be inaccurate. If the synchronization latency is too high, you can perform a DML operation on the source database to update the latency.

  Note

  If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

• During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use DMS to perform online DDL operations.

• During data synchronization, if the destination Kafka cluster is scaled up or down, you must restart the Kafka cluster.

Category

Description

Limits on the source database

• Requirements for the objects to be synchronized:

  • The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.

  • If the version of your Oracle database is 12c or later, the names of the tables to be synchronized cannot exceed 30 bytes in length.

  • If you select tables as the objects to be synchronized and you want to edit the tables in the destination database, such as renaming tables or columns, you can synchronize up to 1,000 tables in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• If the source database is an Oracle RAC database connected over Express Connect, you must specify a VIP for the database when you configure the data synchronization task.

• If the self-managed Oracle database is an Oracle RAC database, you can use only a VIP rather than a Single Client Access Name (SCAN) IP address when you configure the data synchronization task. After you specify the VIP, node failover of the Oracle RAC database is not supported.

• The redo logging and archive logging features must be enabled.

  Note

  If you perform only incremental data synchronization, the redo logs and archive logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the redo logs and archive logs of the source database must be stored for at least seven days. Otherwise, Data Transmission Service (DTS) may fail to obtain the redo logs and archive logs, which causes the task to fail, or even data inconsistency or data loss. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of redo logs and archive logs based on the preceding requirements. Otherwise, the service level agreement (SLA) of DTS does not guarantee service reliability or performance.

• If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.

• The data synchronization task fails if the source database contains an empty string of the VARCHAR2 type and the corresponding column in the destination database has a NOT NULL constraint. Empty strings of the VARCHAR2 type are processed as null values in Oracle databases.

• During data synchronization, do not update LONGTEXT fields. Otherwise, the data synchronization task fails.

Other limits

• The objects of schema synchronization must be tables.

  Warning

  In this scenario, DTS does not support schema synchronization for triggers. We recommend that you delete the triggers of the source database to prevent data inconsistency caused by the triggers. For more information, see Configure a data synchronization task for a source database that contains a trigger.

• A single string in the destination DataHub project cannot exceed 2 MB in length.

• Only tables can be selected as the objects to be synchronized.

• DTS calculates the synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for an extended period of time, the synchronization latency may be inaccurate. If the synchronization latency is too high, you can perform a DML operation on the source database to update the latency.

  Note

  If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

• During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use DMS to perform online DDL operations.

Category

Description

Limits on the source database

• Requirements for the objects to be synchronized:

  • The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.

  • If the version of your Oracle database is 12c or later, the names of the tables to be synchronized cannot exceed 30 bytes in length.

  • If you select tables as the objects to be synchronized and you want to edit the tables in the destination database, such as renaming tables or columns, you can synchronize up to 1,000 tables in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• If the source database is an Oracle RAC database connected over Express Connect, you must specify a VIP for the database when you configure the data synchronization task.

• If the self-managed Oracle database is an Oracle RAC database, you can use only a VIP rather than a Single Client Access Name (SCAN) IP address when you configure the data synchronization task. After you specify the VIP, node failover of the Oracle RAC database is not supported.

• The redo logging and archive logging features must be enabled.

  Note

  If you perform only incremental data synchronization, the redo logs and archive logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the redo logs and archive logs of the source database must be stored for at least seven days. Otherwise, Data Transmission Service (DTS) may fail to obtain the redo logs and archive logs, which causes the task to fail, or even data inconsistency or data loss. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of redo logs and archive logs based on the preceding requirements. Otherwise, the service level agreement (SLA) of DTS does not guarantee service reliability or performance.

• If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.

• The data synchronization task fails if the source database contains an empty string of the VARCHAR2 type and the corresponding column in the destination database has a NOT NULL constraint. Empty strings of the VARCHAR2 type are processed as null values in Oracle databases.

• During data synchronization, do not update LONGTEXT fields. Otherwise, the data synchronization task fails.

Other limits

• Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During initial full data synchronization, DTS uses the read and write resources of the source and destination databases. This may increase the loads of the database servers.

• During initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After initial full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.

• DTS calculates the synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for an extended period of time, the synchronization latency may be inaccurate. If the synchronization latency is too high, you can perform a DML operation on the source database to update the latency.

  Note

  If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

• During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use DMS to perform online DDL operations.