All Products
Search
Document Center

Data Transmission Service:Migrate self-managed Oracle to Message Queue for Apache Kafka

Last Updated:Jun 20, 2026

Data Transmission Service (DTS) migrates data from a self-managed Oracle database to a Message Queue for Apache Kafka instance or a self-managed Kafka cluster to expand your message processing capabilities. This topic describes how to configure a migration task, using a migration from a self-managed Oracle database to a Message Queue for Apache Kafka instance as an example.

Prerequisites

  • The self-managed Oracle database is version 9i, 10g, 11g, 12c, 18c, or 19c.
  • Supplemental logging is enabled for the self-managed Oracle database, and both supplemental_log_data_pk and supplemental_log_data_ui are enabled. For more information, see Supplemental Logging.
  • The self-managed Oracle database is running in ARCHIVELOG mode, a reasonable retention period for archived logs is configured, and the logs are accessible. For more information, see ARCHIVELOG.
  • You must complete the required preparations for the self-managed Oracle database. For more information, see Preparation overview.
  • Each table to be migrated must have a primary key or a non-null unique index.
  • The Message Queue for Apache Kafka instance is a version from 0.10.1.0 to 2.x. The self-managed Kafka cluster is a version from 0.10.1.0 to 2.7.0.
  • The destination Kafka instance has more available storage space than the self-managed Oracle database uses.
  • A topic has been created in the destination Kafka instance to receive synchronized data. For more information, see Create a topic.

Usage notes

  • During a full data migration, DTS consumes read and write resources on the source and destination databases, increasing their load. If your databases have poor performance, low specifications, or high workloads (for example, if the source database has many slow SQL queries or tables without primary keys, or if deadlocks occur in the destination database), the increased load can strain your databases or even cause service interruptions. Perform the data migration during off-peak hours, such as when the CPU utilization of both databases is below 30%.

  • If a migration task fails, DTS automatically tries to resume it. Before you switch your business to the destination database, you must stop or release the task. This prevents the resumed task from overwriting data in the destination database with data from the source.
  • If the self-managed Oracle database is deployed in a Real Application Cluster (RAC) architecture and is connected to DTS over an Alibaba Cloud virtual private cloud (VPC), you must connect the Single Client Access Name (SCAN) IP address of the Oracle RAC and the virtual IP address (VIP) of each node to the VPC and configure routes. The settings ensure that your DTS task can run as expected. For more information, see Connect a data center to DTS through VPN Gateway.

    Important

    When you configure the source Oracle database in the DTS console, you can specify the SCAN IP address of the Oracle RAC as the database endpoint or IP address.

  • If your self-managed Oracle database is version 12c or later, the names of tables to be migrated cannot exceed 30 bytes in length.
  • If a source table lacks a primary key or a unique constraint and contains non-unique data, duplicate data may be created in the destination database.

Billing

Migration type

Task configuration fee

Internet traffic fee

Schema migration and full data migration

Free of charge.

DTS charges an Internet traffic fee when the Access Method of the destination database is set to Public IP Address. Billing overview.

Incremental data migration

Charged. Billing overview.

Migration types

Migration type Description
Schema migration DTS migrates the schema definitions of the migration objects from the source database to the destination database. In this scenario, DTS supports only table schema migration.
Full data migration DTS migrates all existing data from the migration objects in the source database to the destination database.
Note Do not perform DDL operations on the migration objects before the schema migration and full data migration are complete. Otherwise, the migration task may fail.
Incremental data migration After the full data migration, DTS polls and captures redo logs from the self-managed Oracle database to migrate incremental data updates to the destination database in real time. Incremental data migration enables a smooth, zero-downtime migration.

During the incremental data migration phase, DTS supports synchronization of DML and DDL statements.

Before you begin

Log on to the Oracle database that you want to migrate, create a database account for data collection, and grant the necessary permissions to the account.

Note If you already have an account with the required permissions, you can skip this step.
Database Schema migration Full data migration Incremental data migration
Self-managed Oracle database Schema owner permissions Schema owner permissions DBA

To create a database account and grant permissions:

For a self-managed Oracle database, see CREATE USER and GRANT.

Enable logging and grant fine-grained permissions to an Oracle database account

Important

If you want to migrate data from an Oracle database but the database administrator (DBA) permission cannot be granted to the database account, you can enable archive logging and supplemental logging, and grant fine-grained permissions to the account.

  1. Enable archive logging and supplemental logging.

    Type

    Procedure

    Archive logging

    Execute the following statements to enable archive logging:

    shutdown immediate;
    startup mount;
    alter database archivelog;
    alter database open;
    archive log list;

    Supplemental logging

    Enable supplemental logging at the database or table level based on your business requirements:

    Note

    You can enable database-level supplemental logging to ensure the stability of Data Transmission Service (DTS) tasks. You can enable table-level supplemental logging to reduce the disk usage of the source Oracle database.

    • Enable database-level supplemental logging

      1. Execute the following statement to enable minimal supplemental logging:

        alter database add supplemental log data;
      2. Execute the following statement to enable primary key and unique key supplemental logging at the database level:

        alter database add supplemental log data (primary key,unique index) columns;
    • Enable table-level supplemental logging

      1. Execute the following statement to enable minimal supplemental logging:

        alter database add supplemental log data;
      2. Enable table-level supplemental logging by using one of the following methods:

        • Enable primary key supplemental logging at the table level

          alter table table_name add supplemental log data (primary key) columns;
        • Enable table-level supplemental logging for all columns

          alter table tb_name add supplemental log data (all) columns;

    Force logging

    Execute the following statements to enable force logging:

    alter database force logging;
  2. Grant fine-grained permissions to an Oracle database account.

    Oracle versions 9i to 11g

    # Create a database account named rdsdt_dtsacct and grant permissions to the account.
    create user rdsdt_dtsacct IDENTIFIED BY rdsdt_dtsacct;
    grant create session to rdsdt_dtsacct;
    grant connect to rdsdt_dtsacct;
    grant resource to rdsdt_dtsacct;
    grant execute on sys.dbms_logmnr to rdsdt_dtsacct;
    grant select on V_$LOGMNR_LOGS to rdsdt_dtsacct;
    grant select on  all_objects to rdsdt_dtsacct;
    grant select on  all_tab_cols to rdsdt_dtsacct;
    grant select on  dba_registry to rdsdt_dtsacct;
    grant select any table to rdsdt_dtsacct;
    grant select any transaction to rdsdt_dtsacct;
    -- v$log privileges
    grant select on v_$log to rdsdt_dtsacct;
    -- v$logfile privileges
    grant select on v_$logfile to rdsdt_dtsacct;
    -- v$archived_log privileges
    grant select on v_$archived_log to rdsdt_dtsacct;
    -- v$parameter privileges
    grant select on v_$parameter to rdsdt_dtsacct;
    -- v$database privileges
    grant select on v_$database to rdsdt_dtsacct;
    -- v$active_instances privileges
    grant select on v_$active_instances to rdsdt_dtsacct;
    -- v$instance privileges
    grant select on v_$instance to rdsdt_dtsacct;
    -- v$logmnr_contents privileges
    grant select on v_$logmnr_contents to rdsdt_dtsacct;
    -- system tables
    grant select on sys.USER$ to rdsdt_dtsacct;
    grant select on SYS.OBJ$ to rdsdt_dtsacct;
    grant select on SYS.COL$ to rdsdt_dtsacct;
    grant select on SYS.IND$ to rdsdt_dtsacct;
    grant select on SYS.ICOL$ to rdsdt_dtsacct;
    grant select on SYS.CDEF$ to rdsdt_dtsacct;
    grant select on SYS.CCOL$ to rdsdt_dtsacct;
    grant select on SYS.TABPART$ to rdsdt_dtsacct;
    grant select on SYS.TABSUBPART$ to rdsdt_dtsacct;
    grant select on SYS.TABCOMPART$ to rdsdt_dtsacct;
    grant select_catalog_role TO rdsdt_dtsacct;

    Oracle 12c to 19c (multitenant)

    # Switch to the pluggable database (PDB). Create a database account named rdsdt_dtsacct and grant permissions to the account.
    ALTER SESSION SET container = ORCLPDB1;
    create user rdsdt_dtsacct IDENTIFIED BY rdsdt_dtsacct;
    grant create  session to rdsdt_dtsacct;
    grant connect  to rdsdt_dtsacct;
    grant resource to rdsdt_dtsacct;
    grant execute on sys.dbms_logmnr to rdsdt_dtsacct;
    grant select on  all_objects to rdsdt_dtsacct;
    grant select on  all_tab_cols to rdsdt_dtsacct;
    grant select on  dba_registry to rdsdt_dtsacct;
    grant select any table to rdsdt_dtsacct;
    grant select any transaction to rdsdt_dtsacct;
    -- v$log privileges
    grant select on v_$log to rdsdt_dtsacct;
    -- v$logfile privileges
    grant select on v_$logfile to rdsdt_dtsacct;
    -- v$archived_log privileges
    grant select on v_$archived_log to rdsdt_dtsacct;
    -- v$parameter privileges
    grant select on v_$parameter to rdsdt_dtsacct;
    -- v$database privileges
    grant select on v_$database to rdsdt_dtsacct;
    -- v$active_instances privileges
    grant select on v_$active_instances to rdsdt_dtsacct;
    -- v$instance privileges
    grant select on v_$instance to rdsdt_dtsacct;
    -- v$logmnr_contents privileges
    grant select on v_$logmnr_contents to rdsdt_dtsacct;
    grant select on sys.USER$ to rdsdt_dtsacct;
    grant select on SYS.OBJ$ to rdsdt_dtsacct;
    grant select on SYS.COL$ to rdsdt_dtsacct;
    grant select on SYS.IND$ to rdsdt_dtsacct;
    grant select on SYS.ICOL$ to rdsdt_dtsacct;
    grant select on SYS.CDEF$ to rdsdt_dtsacct;
    grant select on SYS.CCOL$ to rdsdt_dtsacct;
    grant select on SYS.TABPART$ to rdsdt_dtsacct;
    grant select on SYS.TABSUBPART$ to rdsdt_dtsacct;
    grant select on SYS.TABCOMPART$ to rdsdt_dtsacct;
    -- V$PDBS privileges
    grant select on V_$PDBS to rdsdt_dtsacct;
    grant select on v$database to rdsdt_dtsacct;
    grant select on dba_objects to rdsdt_dtsacct;
    grant select on DBA_TAB_COMMENTS to rdsdt_dtsacct;
    grant select on dba_tab_cols to rdsdt_dtsacct;
    grant select_catalog_role TO rdsdt_dtsacct;
    
    # Switch to the CDB$ROOT, which is the root container of the container database (CDB). Create a database account and grant permissions to the account.
    ALTER SESSION SET container = CDB$ROOT;
    # Create a database account named rdsdt_dtsacct and grant permissions to the account. You must modify the default parameters of the Oracle database. 
    alter session set "_ORACLE_SCRIPT"=true;
    create user rdsdt_dtsacct IDENTIFIED BY rdsdt_dtsacct;
    grant create session to rdsdt_dtsacct;
    grant connect to rdsdt_dtsacct;
    grant select on v_$logmnr_contents to rdsdt_dtsacct;
    grant LOGMINING TO rdsdt_dtsacct;
    grant EXECUTE_CATALOG_ROLE to rdsdt_dtsacct;
    grant execute on sys.dbms_logmnr to rdsdt_dtsacct;

    Oracle 12c to 19c (non-multitenant)

    # Create a database account named rdsdt_dtsacct and grant permissions to the account.
    create user rdsdt_dtsacct IDENTIFIED BY rdsdt_dtsacct;
    grant create  session to rdsdt_dtsacct;
    grant connect  to rdsdt_dtsacct;
    grant resource to rdsdt_dtsacct;
    grant select on V_$LOGMNR_LOGS to rdsdt_dtsacct;
    grant select on  all_objects to rdsdt_dtsacct;
    grant select on  all_tab_cols to rdsdt_dtsacct;
    grant select on  dba_registry to rdsdt_dtsacct;
    grant select any table to rdsdt_dtsacct;
    grant select any transaction to rdsdt_dtsacct;
    grant select on v$database to rdsdt_dtsacct;
    grant select on dba_objects to rdsdt_dtsacct;
    grant select on DBA_TAB_COMMENTS to rdsdt_dtsacct;
    grant select on dba_tab_cols to rdsdt_dtsacct;
    -- v$log privileges
    grant select on v_$log to rdsdt_dtsacct;
    -- v$logfile privileges
    grant select on v_$logfile to rdsdt_dtsacct;
    -- v$archived_log privileges
    grant select on v_$archived_log to rdsdt_dtsacct;
    -- v$parameter privileges
    grant select on v_$parameter to rdsdt_dtsacct;
    -- v$database privileges
    grant select on v_$database to rdsdt_dtsacct;
    -- v$active_instances privileges
    grant select on v_$active_instances to rdsdt_dtsacct;
    -- v$instance privileges
    grant select on v_$instance to rdsdt_dtsacct;
    -- v$logmnr_contents privileges
    grant select on v_$logmnr_contents to rdsdt_dtsacct;
    grant select on sys.USER$ to rdsdt_dtsacct;
    grant select on SYS.OBJ$ to rdsdt_dtsacct;
    grant select on SYS.COL$ to rdsdt_dtsacct;
    grant select on SYS.IND$ to rdsdt_dtsacct;
    grant select on SYS.ICOL$ to rdsdt_dtsacct;
    grant select on SYS.CDEF$ to rdsdt_dtsacct;
    grant select on SYS.CCOL$ to rdsdt_dtsacct;
    grant select on SYS.TABPART$ to rdsdt_dtsacct;
    grant select on SYS.TABSUBPART$ to rdsdt_dtsacct;
    grant select on SYS.TABCOMPART$ to rdsdt_dtsacct;
    grant LOGMINING TO rdsdt_dtsacct;
    grant EXECUTE_CATALOG_ROLE to rdsdt_dtsacct;
    grant execute on sys.dbms_logmnr to rdsdt_dtsacct;
    grant select_catalog_role TO rdsdt_dtsacct;
    Note

    For more information about the multitenant architecture of Oracle, see Oracle Multitenant.

Procedure

  1. Log on to the DTS console.

    Note

    If you are automatically redirected to the Data Management (DMS) console, you can click the jiqiren icon in the lower-right corner and then click 返回旧版 to return to the classic DTS console.

  2. In the left-side navigation pane, click Data Migration.

  3. At the top of the Migration Tasks page, select the destination instance's region.
  4. In the upper-right corner of the page, click Create Data Migration Task.

  5. Configure the connection settings for the source and destination databases.
    Category Parameter Description
    N/A Task Name DTS automatically generates a task name. We recommend that you specify a descriptive name for easy identification. The name does not need to be unique.
    Source database Instance type Select how the source database is deployed. This topic uses User-Created Database with Public IP Address as an example.
    Note If you use a different instance type for your self-managed database, you must perform additional preparations. For more information, see Preparation overview.
    Instance region If you select User-Created Database with Public IP Address as the instance type, you do not need to set the Instance Region.
    Note If you have configured a whitelist for your self-managed Oracle database, click Get IP Address Segment of DTS next to the Instance Region setting to obtain the IP addresses of the DTS servers. Then, add these IP addresses to the security whitelist of your self-managed Oracle database.
    Database type Select Oracle.
    Hostname or IP address Enter the endpoint of the self-managed Oracle database. In this case, enter its public IP address.
    Port number Enter the service port of the self-managed Oracle database. The default value is 1521.
    Note In this example, the service port is accessible over the internet.
    Instance type
    • Non-RAC Instance: If you select this option, you must also specify the SID.
    • RAC or PDB Instance: If you select this option, you must also specify the Service Name.
    Database account Enter the account for the self-managed Oracle database. For information about the required permissions, see Before you begin.
    Database password Enter the password for the database account.
    Note

    After you enter the source database information, you can click Test Connectivity next to Database Password to verify that the information is correct. If the information is correct, the message Passed is displayed. If the message Failed is displayed, click Diagnose next to the Failed message and adjust the source database information based on the prompts.

    Destination database Instance type Select User-Created Database Connected Over Express Connect, VPN Gateway, or Smart Access Gateway.
    Note Because DTS does not support selecting Message Queue for Apache Kafka directly, you must configure it as a self-managed Kafka cluster.
    Instance region Select the region where the destination Kafka instance is located.
    Peer VPC Select the ID of the destination Kafka instance's VPC. You can find the VPC ID on the Basic Information page of the Kafka instance.
    Database type Select Kafka.
    IP address Enter any IP address from the Default Endpoint of the Kafka instance.
    Note You can find the IP address of the Default Endpoint on the Basic Information page of the Kafka instance.
    Port number The service port of the Kafka instance. The default value is 9092.
    Database account Enter the username for the Kafka instance.
    Note If the instance type of the Kafka instance is VPC Instance, you do not need to configure Database Account and Database Password.
    Database password Enter the password for the username.
    Topic Click Get Topic list on the right and select a topic from the drop-down list.
    Topic for storing DDL Click Get Topic list on the right and select a topic from the drop-down list to store DDL information. If you do not specify a topic, DTS stores the DDL information in the topic selected for the Topic setting.
    Kafka version Select the version that corresponds to your Kafka instance.
    Connection method Based on your business and security requirements, select Non-encrypted or SCRAM-SHA-256.
    Use Kafka schema registry Kafka Schema Registry is a metadata service layer that provides a RESTful interface for storing and retrieving Avro schemas.
    • No: Does not use Kafka Schema Registry.
    • Yes: Uses Kafka Schema Registry. You must enter the URL or IP address of the Avro schema registered in Kafka Schema Registry.
  6. After you complete the configurations, click Set Whitelist and Next in the lower-right corner of the page.
    If the source or destination is an Alibaba Cloud database instance (such as ApsaraDB RDS for MySQL or ApsaraDB for MongoDB), DTS automatically adds the IP addresses of the DTS servers in the corresponding region to the instance's whitelist. If the source or destination is a self-managed database on an ECS instance, DTS automatically adds the IP addresses of the DTS servers to the ECS instance's security group rules. You must also ensure that the self-managed database allows access from the ECS instance. If your database is a cluster deployed across multiple ECS instances, you must manually add the regional IP addresses of the DTS servers to the security group rules of each ECS instance. If the source or destination is a self-managed database in an on-premises data center or a third-party cloud database, you must manually add the IP addresses of the DTS servers to allow access. For a list of DTS server IP addresses, see CIDR blocks of DTS servers.
    Warning

    Adding the public CIDR blocks of DTS servers, whether automatically or manually, may introduce security risks. By using this product, you acknowledge and accept these potential risks. You are responsible for implementing basic security measures, including but not limited to using strong passwords, restricting open ports, using authentication for internal API calls, regularly reviewing and restricting unnecessary network segments, or connecting through private networks such as Express Connect, VPN Gateway, or Smart Access Gateway.

  7. Configure the migration types, policy, and objects.
    Parameter Description
    Migration type Select Schema Migration, Full Data Migration, and Incremental Data Migration.
    Important If you do not select Incremental Data Migration, do not write new data to the source database during the full data migration to ensure data consistency.
    Data format in Kafka Data migrated to the Kafka cluster is stored in Avro format. You must parse the data based on the Avro schema definition. For more information, see DTS Avro schema definition.
    Policy for migrating data to Kafka partitions Select a migration policy based on your business requirements. For more information, see Kafka partition migration policies.
    Migration objects In the Available box, click the tables you want to migrate, and then click the 向右小箭头 icon to move them to the Selected Objects box.
    Note DTS automatically maps the table names to the topic name you selected in Step 5. To change the destination topic for a migration, see Map tables and columns.
    Rename objects To change the name of an object in the destination instance, use the object name mapping feature. For more information, see Map tables and columns.
    Connection retry duration By default, DTS retries for 12 hours. You can also specify a custom retry duration. If DTS reconnects to the source or destination database within the specified time, the migration task automatically resumes. Otherwise, the task fails.
    Note DTS charges fees for the task while it retries to connect. We recommend that you set a custom retry duration based on your business needs or release the DTS instance as soon as possible after the source and destination database instances are released.
  8. Click Precheck and Start.

    Important
    • Before the task starts, DTS performs a precheck. You can only start the task after it passes this precheck.

    • If the precheck fails, click the 提示 icon next to a specific check item to view failure details.

      • You can fix the issues based on the details and then run the precheck again.

      • If you do not need to fix the warning items, you can select Ignore or Ignore and Precheck Again to skip the warning items and run the precheck again.

  9. After the task passes the precheck, click Next.

  10. In the Confirm Settings dialog box that appears, select a Instance Class and select the Data Transmission Service (pay-as-you-go) Service Terms checkbox.

  11. Click Buy and Start to start the migration task.

Stop the migration task

Warning

To minimize the impact of the cutover, you can create a rollback plan to replicate incremental data from the destination database back to the source database in real time. For more information, see Cutover procedure. If no business cutover is involved, you can stop the data migration task.

  • Full data migration

    Do not manually stop a task during full data migration. Otherwise, the system may fail to migrate all data. Wait until the migration task automatically ends.

  • Incremental data migration

    This type of task does not stop automatically; you must stop it manually.

    1. Wait until the task enters the Incremental Data Migration stage with a Undelayed status. Then, stop writes to the source database for a few minutes. During this period, the Incremental Data Migration status might report a latency.
    2. Wait for the Incremental Data Migration status to return to Undelayed. Once this is confirmed in the list, select the task's checkbox and click the StopEnd button in the batch operations bar at the bottom.

Next steps

Authorize a RAM user