From DDM to Oracle

Supported Source and Destination Databases

**Table 1** Supported databases
Source DB	Destination DB
DDM instances	On-premises databases ECS databases

Prerequisites

You have logged in to the DRS console.
Your account balance is greater than or equal to $0 USD.
For details about the DB types and versions supported by real-time synchronization, see Supported Databases.
If a subaccount is used to create a DRS task, ensure that an agency has been added. To create an agency, see Agency Management.

Suggestions

When a task is being started or in the full synchronization phase, do not perform DDL operations on the source database. Otherwise, the task may be abnormal.
To keep data consistency before and after the synchronization, ensure that no data is written to the destination database during the synchronization.

The success of database synchronization depends on environment and manual operations. To ensure a smooth synchronization, perform a synchronization trial before you start the synchronization to help you detect and resolve problems in advance.
Start your synchronization task during off-peak hours. A less active database is easier to synchronize successfully. If the data is fairly static, there is less likely to be any severe performance impacts during the synchronization.
- If network bandwidth is not limited, the query rate of the source database increases by about 50 MB/s during full synchronization, and two to four CPUs are occupied.
- The data being synchronized may be locked by other transactions for a long period of time, resulting in read timeout.
- When DRS concurrently reads data from a database, it will use about 6 to 10 sessions. The impact of the connections on services must be considered.
- If you read a table, especially a large table, during the full migration, the exclusive lock on that table may be blocked.
- For more information about the impact of DRS on databases, see What Is the Impact of DRS on Source and Destination Databases?
Data-Level Comparison
To obtain accurate comparison results, start data comparison at a specified time point during off-peak hours. If it is needed, select Start at a specified time for Comparison Time. Due to slight time difference and continuous operations on data, data inconsistency may occur, reducing the reliability and validity of the comparison results.

Precautions

Before creating a synchronization task, read the following notes:

You are advised to create an independent database account for DRS task connection to prevent task failures caused by database account password modification.
After changing the account passwords for the source or destination databases, modify the connection information in the DRS task as soon as possible to prevent automatic retry after a task failure. Automatic retry will lock the database accounts.

**Table 2** Precautions
Type	Restrictions
Database permissions	The source database DDM account must have at least one permission, for example, SELECT. The physical sharded database account must have the following permissions: SELECT, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE and REPLICATION CLIENT. The destination database user must have the following permissions: ALTER ANY INDEX, ALTER ANY TABLE, ALTER SESSION, ANALYZE ANY, COMMENT ANY TABLE, CREATE ANY INDEX, CREATE ANY TABLE, CREATE SESSION, DELETE ANY TABLE, DROP ANY TABLE, INSERT ANY TABLE, SELECT ANY TABLE, SELECT ANY DICTIONARY, SELECT ANY TRANSACTION, UPDATE ANY TABLE, and RESOURCE roles.
Synchronization object	The source database data can be synchronized. The source database table structure supports only full synchronization. Database objects other than table structures, indexes, and constraints cannot be synchronized. The destination Oracle database does not support empty strings, so the object to be synchronized cannot contain empty strings.
Source database	During the incremental synchronization, the binlog of the source sharded database must be enabled and use the row-based format. If the storage space is sufficient, store the binlogs for as long as possible. The recommended retention period is three days. During an incremental synchronization, the server_id value of the MySQL source database must be set. If the source database version is MySQL 5.6 or earlier, the server_id value ranges from 2 to 4294967296. If the source database is MySQL 5.7 or later, the server_id value ranges from 1 to 4294967296. The database names and table names of the source database sharding middleware cannot contain the following characters: '<>/\ and non-ASCII characters. Enable skip-name-resolve for the source sharded database to reduce the possibility of connection timeout. Enable GTID on the source sharded database. The source physical sharded database does not support the enumeration and set types. The source database table name and field name cannot exceed 30 characters. Tables without primary keys cannot be synchronized. The source databases to be synchronized must have the RESOURCE permission. The default value in the timestamp column of the source database must be within the range allowed by the destination database. Otherwise, the synchronization fails.
Destination database	The destination DB instance is running properly. The destination DB instance must have sufficient storage space. The time zone of the destination database must be the same as that of the source database. The destination database (account) must have the RESOURCE permission.
Precautions	If the data types are incompatible, the synchronization may fail. The NOT NULL constraint of MySQL supports empty strings, while the NOT NULL constraint of Oracle does not. During a synchronization, if an empty string exists in a NOT NULL constraint field, delete the NOT NULL constraint from the destination Oracle database. If the source database contains a duplicate primary key, data synchronized to the destination database will be less than that in the source database. You must check and correct the data before starting the synchronization task. The varbinary, binary, and timestamp columns in the source table cannot contain primary key or unique constraints. If the sharding key of a sharded database or table is a function rather than a primary key, the primary key and sharding key will be automatically used as the composite primary key when the table is created in Oracle. The destination table can contain more columns than the source table. However, the following failures must be avoided: Assume that extra columns on the destination cannot be null or have default values. If newly inserted data records are synchronized from the source to the destination, the extra columns will become null, which does not meet the requirements of the destination and will cause the task to fail. Assume that extra columns on the destination must be fixed at a default value and have a unique constraint. If newly inserted data records are synchronized from the source to the destination, the extra columns will contain multiple default values. That does not meet the unique constraint of the destination and will cause the task to fail. After a task is created, you cannot add schemas to the source database or modify the old schema to associate with the new RDS DB instance. Otherwise, data cannot be synchronized or the task fails. DDL operations are not supported during synchronization. During the synchronization, do not change the sharding key of a table on the source DDM instance, or change an unsharded or broadcast table to a sharded table, or change a sharded table to an unsharded or broadcast table. During an incremental synchronization, do not modify or delete the usernames, passwords, permissions, or ports of the source and destination databases. During an incremental synchronization, if you need to modify the structure of the source table to be synchronized, you must modify the corresponding destination table structure. During an incremental synchronization, do not perform the restoration operation on the source database.