Precautions and limitations for migrating data from an Oracle source database

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

    Note

    You can also use the Oracle ROWID as the primary key for tables that do not have a primary key or unique constraint.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

• Migration of foreign tables is not supported.

• The destination PolarDB for PostgreSQL (Compatible with Oracle) cluster generates unique indexes, such as pg_oid_1498503_index, to correspond to the ROWID of the source Oracle database. Therefore, the destination cluster has more indexes than the source Oracle database.

• The destination PolarDB for PostgreSQL (Compatible with Oracle) cluster does not support writing the string terminator ('\0'). If the data to be migrated contains this terminator, DTS does not write it to the destination database. This causes data inconsistency.

• When a CHECK constraint from the source Oracle database is migrated to the destination PolarDB for PostgreSQL (Compatible with Oracle) cluster, it is converted into a NOT NULL constraint.

• Ensure that the character sets of the source and destination databases are compatible. Incompatible character sets may cause data inconsistency or task failure.

• Use the schema migration feature of DTS. Otherwise, the task may fail due to incompatible data types.

• The time zones of the source and destination databases must be the same.

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• User-defined types can be migrated to the destination PolarDB for PostgreSQL (Compatible with Oracle) cluster. Type objects automatically generated by Oracle, which are built-in objects, are not migrated.

  Note

  PolarDB for PostgreSQL (Compatible with Oracle) clusters already support Oracle's built-in objects, so you do not need to migrate them.

• DTS validates data content but does not validate metadata such as sequences. You must validate metadata yourself.

• After you switch your workloads to the destination instance, newly written sequences do not increment from the maximum value of the corresponding sequences in the source database. Before you switch your workloads, you must update the sequence values in the destination database. For more information, see Update sequence values in the destination database.

• This limit applies to full or incremental data migration tasks where the tables to be migrated from the source database contain foreign keys, triggers, or event triggers. If the destination database account has high-privilege or superuser permissions, DTS temporarily sets the session_replication_role parameter to replica at the session level during the migration. If the account does not have these permissions, you must manually set the parameter to replica in the destination database. During this period (while session_replication_role is set to replica), cascade update or delete operations in the source database may cause data inconsistency. After the migration task is released, you can set the parameter back to origin.

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

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• Migration of foreign tables is not supported.

• Migration of PACKAGE, PACKAGE_BODY, MATERIALIZED_VIEW, SYNONYM, TYPE, TYPE_BODY, FUNCTION, PROCEDURE, SEQUENCE, VIEW, TABLE_COMMENT, COLUMN_COMMENT, and TRIGGER is not supported.

• If your data includes four-byte characters—such as rare Chinese characters or emojis—the destination database and table must use the utf8mb4 charset.

  Note

  If you use DTS to migrate schemas, set the instance-level parameter character_set_server to utf8mb4 in the destination database.

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

• If a DDL statement fails to be written to the destination database, the DTS task continues to run. You must check the task logs for the failed DDL statement. For more information about how to view task logs, see Query task logs.

• Ensure that the character sets of the source and destination databases are compatible. Incompatible character sets may cause data inconsistency or task failure.

• Use the schema migration feature of DTS. Otherwise, the task may fail due to incompatible data types.

• The time zones of the source and destination databases must be the same.

• If you write columns with identical names but different cases into the same table in the destination MySQL database, unexpected results may occur. MySQL column names are case-insensitive.

• After migration completes—the task status is Status and the status changes to Completed—run analyze table <table_name> to confirm all data is written to the destination table. For example, after a high-availability (HA) switchover in the destination MySQL database, data may remain in memory and never reach disk, causing data loss.

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

Special cases

When the destination database is ApsaraDB RDS for MySQL

• ApsaraDB RDS for MySQL instances are case-insensitive to English table names. If you use uppercase English letters to create a table, ApsaraDB RDS for MySQL converts the table name to lowercase before creating the table.

  If the source Oracle database contains tables whose names are identical but differ in case, this may cause object name conflicts and a message indicating that the object already exists during schema migration. If this occurs, use the object name mapping feature provided by DTS to rename the conflicting objects when you configure migration objects. Convert the table names to uppercase. For more information, see Map tables and columns.

• DTS automatically creates databases in the ApsaraDB RDS for MySQL instance. If the name of a database to be migrated does not comply with the naming conventions of ApsaraDB RDS for MySQL, you must create the database in the ApsaraDB RDS for MySQL instance before you configure the migration task. For more information, see Manage databases.

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• Migration of foreign tables is not supported.

• Migration of PACKAGE, PACKAGE_BODY, MATERIALIZED_VIEW, SYNONYM, TYPE, TYPE_BODY, FUNCTION, PROCEDURE, SEQUENCE, VIEW, TABLE_COMMENT, COLUMN_COMMENT, and TRIGGER is not supported.

• If your data includes four-byte characters—such as rare Chinese characters or emojis—the destination database and table must use the utf8mb4 charset.

  Note

  If you use DTS to migrate schemas, set the instance-level parameter character_set_server to utf8mb4 in the destination database.

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

• If a DDL statement fails to be written to the destination database, the DTS task continues to run. You must check the task logs for the failed DDL statement. For more information about how to view task logs, see Query task logs.

• Ensure that the character sets of the source and destination databases are compatible. Incompatible character sets may cause data inconsistency or task failure.

• Use the schema migration feature of DTS. Otherwise, the task may fail due to incompatible data types.

• The time zones of the source and destination databases must be the same.

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

Special cases

When the destination database is PolarDB for MySQL:

• PolarDB for MySQL clusters are case-insensitive to English table names. If you use uppercase English letters to create a table, PolarDB for MySQL converts the table name to lowercase before creating the table.

  If the source Oracle database contains tables whose names are identical but differ in case, this may cause object name conflicts and a message indicating that the object already exists during schema migration. If this occurs, use the object name mapping feature provided by DTS to rename the conflicting objects when you configure migration objects. Convert the table names to uppercase. For more information, see Map tables and columns.

• DTS automatically creates databases in PolarDB for MySQL. If the name of a database to be migrated does not comply with the naming conventions of PolarDB for MySQL, you must create the database in PolarDB for MySQL before you configure the migration task. For more information, see Manage databases.

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• Only table-level migration is supported. Append-optimized (AO) tables are not supported as destination tables.

• If you use column mapping for a partial table migration or if the source and destination table schemas differ, data in columns that exist in the source but not in the destination will be lost.

• The destination AnalyticDB for PostgreSQL instance does not support writing the string terminator ('\0'). If the data to be migrated contains this terminator, DTS does not write it to the destination database. This causes data inconsistency.

• Migration of foreign tables is not supported.

• Migration of PACKAGE, PACKAGE_BODY, MATERIALIZED_VIEW, SYNONYM, TYPE, TYPE_BODY, PROCEDURE, and INDEX is not supported.

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• If a table to be migrated has a primary key, the primary key column in the destination table must be the same as that in the source table. If a table to be migrated 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 of the destination table, including the primary key column, must contain all columns of the distribution key.

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

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

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• Migration of foreign tables is not supported.

• Migration of INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, FK, TABLE_COMMENT, and COLUMN_COMMENT is not supported.

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

• During migration, if the destination Kafka cluster is scaled out or in, you must 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.

Type

Description

Source database limitations

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• If the source database is connected over a leased line, you must configure one of the virtual IP addresses (VIPs) in the connection information. This allows the Oracle Real Application Clusters (RAC) to connect to the data migration task over the leased line.

• If the self-managed Oracle database uses an RAC architecture and is connected over a leased line, VPN Gateway, Smart Access Gateway, Database Gateway (DG), or Cloud Enterprise Network (CEN), or from an ECS instance, you cannot configure a Single Client Access Name (SCAN) IP address. You can only configure one of the VIPs in the connection information. If you use this method, node switching for RAC is not supported.

• If the data to be migrated contains empty strings of the `varchar2` type, which Oracle treats as null, and the corresponding destination database field has a NOT NULL constraint, the migration task fails.

• If the FGA (Fine-Grained Audit) policy is enabled on the table to be migrated, DTS cannot recognize the ORA_ROWSCN pseudocolumn, which will cause the migration job to fail.

  Note

  You can disable the FGA policy for the tables to be migrated, or choose not to migrate data from these tables.

• Requirements for migration objects:

  • The tables to be migrated must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database.

  • If your self-managed Oracle database is version 12c or later, the names of the tables to be migrated must not exceed 30 bytes in length.

  • If you migrate objects at the table level and need to edit them, such as mapping table or column names, a single data migration task supports a maximum of 1,000 tables. If this limit is exceeded, an error is reported after you submit the task. In this case, split the tables into multiple batches and configure a separate task for each batch, or configure a task to migrate the entire database.

• For incremental migration, Redo Logs and Archive Logs:

  • Must be enabled.

  • For an incremental data migration task, DTS requires that Redo Logs and Archive Logs in the source database are retained for more than 24 hours. For a task that includes both full and incremental data migration, DTS requires that Redo Logs and Archive Logs are retained for at least 7 days. After the full data migration is complete, you can change the retention period to more than 24 hours. If the retention period is shorter than required, the DTS task may fail because it cannot obtain the logs. In extreme cases, this may cause data inconsistency or loss. Issues caused by a log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

• Limitations on source database operations:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency between the source and destination occurs. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

  • Updating large text fields separately is not supported and will cause the task to fail.

Other limitations

• During incremental migration, importing data into the source database by using Oracle Data Pump is not supported. This may cause data loss.

• Migration of foreign tables is not supported.

• Schema migration tasks do not support the migration of schemas.

• Evaluate the performance of the source and destination databases before migrating data, and perform migration during off-peak hours. During full data migration, DTS consumes some read and write resources from the source and destination databases, which may increase the database load.

• Full data migration performs concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance.

• DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. Alternatively, use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed.

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