This topic describes the precautions and limits when you synchronize data from a self-managed Oracle database. To ensure that your data synchronization task runs as expected, read the precautions and limits before you configure the task.

Scenarios of synchronizing data from an Oracle database

You can view the precautions and limits based on the following synchronization scenarios:

Synchronize data from a self-managed Oracle database to an AnalyticDB for PostgreSQL instance

Synchronize data from a self-managed Oracle database to an AnalyticDB for PostgreSQL instance

The following table describes the precautions and limits.
Type Description
Limits on the source database
  • Requirements for the objects to be synchronized:
    • The source database 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.
  • The following requirements for data logs must be met:
    • The data logging feature must be enabled.
    • Data logs are retained for at least 7 days during initial full data synchronization. You can wait until initial full data synchronization is complete, and then clear the data logs generated in the source database after the DTS task is run.
      Note To ensure data security, the DTS server stores only 50 GB of data logs or the data logs for the last 24 hours. If the limit is exceeded, the DTS server automatically clears the cached logs.
      Warning If you clear the data logs of the source database during initial full data synchronization, the data synchronization task may fail. For example, initial full data synchronization takes more than 24 hours due to the large data volume in the source database and abnormal writing in the destination database. In this case, if the data logs of the source database are cleared during initial full data synchronization, DTS cannot obtain the data logs generated 24 hours ago. Therefore, the data synchronization task may fail.
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
Other limits
  • DTS supports initial schema synchronization for the following types of objects: table, index, constraint, function, sequence, and view.
    Warning
    • Oracle and AnalyticDB for PostgreSQL are heterogeneous databases. 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.
    • In this scenario, DTS is incompatible with triggers. We recommend that you delete the triggers of the source database to prevent data inconsistency caused by triggers. For more information, see Configure a data synchronization task for a source database that contains a trigger.
    • For partition tables, DTS discards the partition definitions. You must define partitions in 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 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.
  • We recommend that you do not use gh-ost or pt-online-schema-change to perform data definition language (DDL) operations on source tables during data synchronization. Otherwise, data synchronization may fail.
  • To ensure that the latency of data synchronization is accurate, DTS adds a heartbeat table to the source database. The name of the heartbeat table is dts_log_heart_beat.
  • DTS calculates 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 data manipulation language (DML) operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task 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.