Usage notes and limits for data synchronization from Oracle

Category

Description

Limits on the source database

• Object requirements:

  • Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Otherwise, the destination database may contain duplicate data.

  • For Oracle 12c and later, table names cannot exceed 30 bytes.

  • If you select tables as objects and edit them in the destination (such as renaming tables or columns), a single task supports up to 1,000 tables. Exceeding this limit causes a request error. To synchronize more, split tables across multiple tasks or synchronize the entire database.

• If the source Oracle RAC database connects over Express Connect, specify a VIP when you configure the task.

• For self-managed Oracle RAC databases, use a VIP instead of a SCAN IP address. Node failover is not supported after you specify the VIP.

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

  Note

  For incremental-only synchronization, retain redo logs and archive logs for more than 24 hours. For full + incremental synchronization, retain them for at least seven days. After full synchronization completes, you can set retention to more than 24 hours. Insufficient retention may cause task failures, data inconsistency, or loss, and the DTS SLA may not apply.

• A primary/secondary switchover on the source database during synchronization causes the task to fail.

• If the data contains a VARCHAR2 empty string (treated as null by Oracle) and the destination column has a NOT NULL constraint, the task fails.

• If a table has the Fine-Grained Audit (FGA) policy enabled, DTS cannot detect the ORA_ROWSCN pseudocolumn, which causes the task to fail.

  Note

  Disable the FGA policy for the table, or exclude the table from synchronization.

• Do not update LONGTEXT fields during synchronization. Otherwise, the task fails.

• Do not run DDL operations that change database or table schemas during schema synchronization or full synchronization. Otherwise, the synchronization task fails.

  Note

  During full synchronization, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

Other limits

• Initial schema synchronization supports the following objects: table, constraint, function, sequence, and view.

  Warning

  Schema consistency between source and destination is not guaranteed after initial schema synchronization. Evaluate the impact of data type conversion on your business to avoid task failures or data inconsistency. Data type mappings for schema synchronization.

• External tables cannot be synchronized.

• Packages, package bodies, materialized views, synonyms, types, type bodies, procedures, and indexes cannot be synchronized.

• Triggers cannot be synchronized. Delete triggers from the source database to prevent data inconsistency. For more information about how to synchronize triggers, see Configure a data synchronization or migration task for a source database that contains a trigger.

• DTS discards partition definitions for partitioned tables. Define partitions in the destination database.

• Only tables can be selected as objects. Append-optimized (AO) tables are not supported.

• If column mapping is used for non-full table synchronization, or if source and destination table structures differ, data for columns missing in the destination is lost.

• The destination AnalyticDB for PostgreSQL instance does not support the string terminator '\0'. If the data contains this terminator, DTS omits it, which causes data inconsistency.

• Do not use Oracle Data Pump to write data to the source database during incremental synchronization. Otherwise, data loss may occur.

• Synchronize data during off-peak hours. During initial full synchronization, DTS consumes read and write resources on both databases, which may increase server load.

• Concurrent INSERT operations during full synchronization cause table fragmentation. After full synchronization, the destination tablespace is larger than the source.

• DTS calculates synchronization latency from the timestamp of the latest synchronized data and the current source timestamp. If no DML operations run on the source for a long time, the latency may be inaccurate. Perform a DML operation on the source to refresh the latency.

  Note

  If you synchronize an entire database, create a heartbeat table that updates every second.

• During synchronization, use only DTS to write to the destination database. Writing with other tools (for example, DMS online DDL) may cause data loss or inconsistency.

• 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.

Category

Description

Limits on the source database

• Object requirements:

  • Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Otherwise, the destination database may contain duplicate data.

  • For Oracle 12c and later, table names cannot exceed 30 bytes.

  • If you select tables as objects and edit them in the destination (such as renaming tables or columns), a single task supports up to 1,000 tables. Exceeding this limit causes a request error. To synchronize more, split tables across multiple tasks or synchronize the entire database.

• If the source Oracle RAC database connects over Express Connect, specify a VIP when you configure the task.

• For self-managed Oracle RAC databases, use a VIP instead of a SCAN IP address. Node failover is not supported after you specify the VIP.

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

  Note

  For incremental-only synchronization, retain redo logs and archive logs for more than 24 hours. For full + incremental synchronization, retain them for at least seven days. After full synchronization completes, you can set retention to more than 24 hours. Insufficient retention may cause task failures, data inconsistency, or loss, and the DTS SLA may not apply.

• A primary/secondary switchover on the source database during synchronization causes the task to fail.

• If the data contains a VARCHAR2 empty string (treated as null by Oracle) and the destination column has a NOT NULL constraint, the task fails.

• If a table has the Fine-Grained Audit (FGA) policy enabled, DTS cannot detect the ORA_ROWSCN pseudocolumn, which causes the task to fail.

  Note

  Disable the FGA policy for the table, or exclude the table from synchronization.

• Do not update LONGTEXT fields during synchronization. Otherwise, the task fails.

• Do not run DDL operations that change database or table schemas during schema synchronization or full synchronization. Otherwise, the synchronization task fails.

  Note

  During full synchronization, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

Other limits

• DTS does not synchronize renamed tables unless the new name is included in the objects to synchronize. To add renamed tables, perform the Modify Synchronized Objects operation. For more information, see Add a synchronization object.

• External tables cannot be synchronized.

• Indexes, partitions, views, procedures, functions, triggers, foreign keys, table comments, and column comments cannot be synchronized.

• Do not use Oracle Data Pump to write data to the source database during incremental synchronization. Otherwise, data loss may occur.

• Synchronize data during off-peak hours. During initial full synchronization, DTS consumes read and write resources on both databases, which may increase server load.

• Concurrent INSERT operations during full synchronization cause table fragmentation. After full synchronization, the destination tablespace is larger than the source.

• DTS calculates synchronization latency from the timestamp of the latest synchronized data and the current source timestamp. If no DML operations run on the source for a long time, the latency may be inaccurate. Perform a DML operation on the source to refresh the latency.

  Note

  If you synchronize an entire database, create a heartbeat table that updates every second.

• During synchronization, use only DTS to write to the destination database. Writing with other tools (for example, DMS online DDL) may cause data loss or inconsistency.

• If the destination Kafka cluster is scaled during synchronization, restart the instance.

• 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.

Category

Description

Limits on the source database

• Object requirements:

  • Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Otherwise, the destination database may contain duplicate data.

  • For Oracle 12c and later, table names cannot exceed 30 bytes.

  • If you select tables as objects and edit them in the destination (such as renaming tables or columns), a single task supports up to 1,000 tables. Exceeding this limit causes a request error. To synchronize more, split tables across multiple tasks or synchronize the entire database.

• If the source Oracle RAC database connects over Express Connect, specify a VIP when you configure the task.

• For self-managed Oracle RAC databases, use a VIP instead of a SCAN IP address. Node failover is not supported after you specify the VIP.

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

  Note

  For incremental-only synchronization, retain redo logs and archive logs for more than 24 hours. For full + incremental synchronization, retain them for at least seven days. After full synchronization completes, you can set retention to more than 24 hours. Insufficient retention may cause task failures, data inconsistency, or loss, and the DTS SLA may not apply.

• A primary/secondary switchover on the source database during synchronization causes the task to fail.

• If the data contains a VARCHAR2 empty string (treated as null by Oracle) and the destination column has a NOT NULL constraint, the task fails.

• If a table has the Fine-Grained Audit (FGA) policy enabled, DTS cannot detect the ORA_ROWSCN pseudocolumn, which causes the task to fail.

  Note

  Disable the FGA policy for the table, or exclude the table from synchronization.

• Do not update LONGTEXT fields during synchronization. Otherwise, the task fails.

• Do not execute DDL statements during schema synchronization. Otherwise, the task fails.

Other limits

• The structure initialization object is TABLE.

  Warning

  DTS does not support schema migration for triggers. Delete triggers from the source database to prevent data inconsistency. For more information, see Configure a data synchronization or migration task for a source database that contains a trigger.

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

• External tables cannot be synchronized.

• Do not use Oracle Data Pump to write data to the source database during incremental synchronization. Otherwise, data loss may occur.

• DTS calculates synchronization latency from the timestamp of the latest synchronized data and the current source timestamp. If no DML operations run on the source for a long time, the latency may be inaccurate. Perform a DML operation on the source to refresh the latency.

  Note

  If you synchronize an entire database, create a heartbeat table that updates every second.

• During synchronization, use only DTS to write to the destination database. Writing with other tools (for example, DMS online DDL) may cause data loss or inconsistency.

• 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.

Category

Description

Limits on the source database

• Object requirements:

  • Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Otherwise, the destination database may contain duplicate data.

  • For Oracle 12c and later, table names cannot exceed 30 bytes.

  • If you select tables as objects and edit them in the destination (such as renaming tables or columns), a single task supports up to 1,000 tables. Exceeding this limit causes a request error. To synchronize more, split tables across multiple tasks or synchronize the entire database.

• If the source Oracle RAC database connects over Express Connect, specify a VIP when you configure the task.

• For self-managed Oracle RAC databases, use a VIP instead of a SCAN IP address. Node failover is not supported after you specify the VIP.

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

  Note

  For incremental-only synchronization, retain redo logs and archive logs for more than 24 hours. For full + incremental synchronization, retain them for at least seven days. After full synchronization completes, you can set retention to more than 24 hours. Insufficient retention may cause task failures, data inconsistency, or loss, and the DTS SLA may not apply.

• A primary/secondary switchover on the source database during synchronization causes the task to fail.

• If the data contains a VARCHAR2 empty string (treated as null by Oracle) and the destination column has a NOT NULL constraint, the task fails.

• If a table has the Fine-Grained Audit (FGA) policy enabled, DTS cannot detect the ORA_ROWSCN pseudocolumn, which causes the task to fail.

  Note

  Disable the FGA policy for the table, or exclude the table from synchronization.

• Do not update LONGTEXT fields during synchronization. Otherwise, the task fails.

• Do not run DDL operations that change database or table schemas during schema synchronization or full synchronization. Otherwise, the synchronization task fails.

  Note

  During full synchronization, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

Other limits

• Do not use Oracle Data Pump to write data to the source database during incremental synchronization. Otherwise, data loss may occur.

• Synchronize data during off-peak hours. During initial full synchronization, DTS consumes read and write resources on both databases, which may increase server load.

• External tables cannot be synchronized.

• DTS calculates synchronization latency from the timestamp of the latest synchronized data and the current source timestamp. If no DML operations run on the source for a long time, the latency may be inaccurate. Perform a DML operation on the source to refresh the latency.

  Note

  If you synchronize an entire database, create a heartbeat table that updates every second.

• During synchronization, use only DTS to write to the destination database. Writing with other tools (for example, DMS online DDL) may cause data loss or inconsistency.

• 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.