How do I resolve CDC failures, performance issues, and sequence errors in AWS DMS when an Oracle database is the source?

Resolution

When you run AWS DMS replication tasks with an Oracle database as the source, issues with the redo logs might cause CDC failures, replication lag, or task errors.

To resolve these issues, compete the resolution based on the error message that you receive.

Archived redo log not found during CDC replication

If you try to extract the archived redo log with the sequence number, then you might get one of the following error messages:

• "01197747: 2024-12-24T08:05:57:590599 [SOURCE_CAPTURE ]D: Cannot find archived redo log with sequence '523652', thread '1'. Please check redo log retention settings and retry. (oracdc_reader.c:420)"
• "00235080: 2024-08-15T09:35:26 [SOURCE_CAPTURE ]E: Failed to add the REDO sequence '1048' to LogMiner in thread '1'. Replication task could not find the required REDO log on the source database to read changes from. Please check redo log retention settings and retry. [1022318] (oracdc_reader.c:659)"

These errors occur when Oracle deletes the archived redo log because of the retention period, so the replication task can't find the redo log.

To check whether there's an archived redo log sequence on the source, run the following query on the Oracle database:

SELECT name, dest_id, thread#, sequence#, archived, applied, deleted, status,
       first_time, next_time, completion_time
FROM v$archived_log
WHERE sequence# = 523652;

Note: Replace 523652 with your sequence number.

In the query's output, check the DELETED column.

If DELETED = NO, then the archived redo log is on the source.

To view the log, run one of the following commands on the archived redo log location.

Amazon RDS for Oracle log location:

exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
select * from table(rdsadmin.rds_file_util.listdir(p_directory => 'ARCHIVELOG_DIR'))

On-premises log location:

ls -ltr 523652

Note: Replace 523652 with your sequence number.

After you check the log, restart the AWS DMS task.

If DELETED = YES, then then Oracle deleted the archived redo log on the source.

To resolve this issue, restore the archived redo log from backup and restart the task after the sequences become available on the source. If you can’t restore the archived redo log sequence, then restart the task from the full-load phase.

Also, increase the value of the archived redo log retention period so that Oracle doesn't delete the log again. Allow enough time for the full load and CDC to complete. If the retention period is too short, then Oracle might delete the archived redo logs before AWS DMS can read them. In this case, you must download the archived redo logs from the Amazon Simple Storage Service (Amazon S3) bucket to restore them.

For an on-premises Oracle database or an Oracle database on Amazon Elastic Compute Cloud (Amazon EC2), use Oracle Recovery Manager (RMAN) to increase the archived redo log retention period.

For example, you run the DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-1' RMAN command to delete archived redo logs that are older than 1 day. To retain archived redo logs for a longer period, change SYSDATE-1 to a higher value.

Start RMAN, and connect to your database.

To view the current retention period of the archived redo log, run the following command:

SHOW ALL;

Note: The default setting is NONE.

To change the retention period, run the following command:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;

Note: Replace 2 with the number of days that you want to retain the archived redo log.

If Oracle deleted the archived redo logs before AWS DMS read them, then you must restore the redo log from a backup.

To check whether there's a backup of the archived redo log, run the following command:

LIST BACKUP OF ARCHIVELOG SEQUENCE 523652 THREAD 1;

Note: Replace 523652 with your archive log sequence number.

To restore the archived redo log sequence, run the following command:

RUN {
  ALLOCATE CHANNEL c DEVICE TYPE DISK;
  RESTORE ARCHIVELOG SEQUENCE 523652 THREAD 1 UNTIL SEQUENCE 523652 THREAD 1;
}

Restart the AWS DMS task.

If you can't restore the archived redo log sequence, then restart the task from the full-load phase.

Out-of-order archive log sequence error

If your current log sequence doesn't match the previous log sequence, then you might get the following error message in the AWS DMS log:

"03791910: 2024-10-16T16:28:48 [TASK_MANAGER ]E: The Archived Redo log sequence 314633 is out of order, expecting 314634 or 314635 instead, thread 2 file name +PDL3SMS_ARCH01/PDL3SMS/ARCHIVELOG/2024_10_16/thread_2_seq_314633.1826.1182515085; Oracle corrupted redo log [1022322] (replicationtask.c:3481)"

This error occurs when you use a standby database as the source in AWS DMS. AWS DMS automatically retries and restarts the task when the correct sequence becomes available.

AWS DMS must process log sequences in sequential order. If AWS DMS doesn't complete the previous log sequence before you request the current log, then AWS DNS can't begin to process the current log.

AWS DMS automatically handles out-of-order redo log sequences through retry logic.

However, if you continue to experience sequence errors, then take the following actions:

• Contact your Oracle database administrator (DBA) team to identify changes or unexpected behavior in the Oracle database or network.
• Monitor Amazon CloudWatch metrics for spikes in replication lag during task restarts.
• Contact Oracle Support.

CDC stops after Oracle DataGuard failover

If you use Oracle DataGuard architecture with the primary database as the AWS DMS source, then CDC might fail after a failover. 

You get one of the following error messages:

• "02894392: 2024-11-23T00:03:46 [SOURCE_CAPTURE ]I: Database role is 'PHYSICAL STANDBY' (oracle_endpoint_conn.c:139)"
• "02894392: 2024-11-23T00:03:46 [SOURCE_CAPTURE ]I: Resetlog process is supported in Oracle Database (oracle_endpoint_imp.c:1568)"
• "02894392: 2024-11-23T00:03:46 [SOURCE_CAPTURE ]I: Resetlog process is not supported for Physical Standby Oracle environment (oracle_endpoint_imp.c:1575)"
• "02894392: 2024-11-23T03:57:19 [SOURCE_CAPTURE ]I: The connection to the source database reestablished (oracdc_merger.c:1248)"
• "02894392: 2024-11-23T03:57:19 [SOURCE_CAPTURE ]I: Trying to reconnect to the source database (oracdc_merger.c:1219)"
• "02894392: 2024-11-23T03:57:19 [SOURCE_CAPTURE ]I: Disconnecting Oracle database (oracle_endpoint_conn.c:1600)"

After a failover, the new primary database has a new resetlog system change number (SCN), that AWS DMS can't reconcile without the supportResetlog parameter. If the standby database transitions to the primary database during a failover, then AWS DMS no longer replicates data changes.

To continue to replicate data changes after a database failover, set the supportResetlog parameter to TRUE as an extra connection attribute (ECA) in the AWS DMS source endpoint settings. For more information, see How to handle AWS DMS replication when used with Oracle database in fail-over scenarios.

Note: In AWS DMS versions 3.4.7 and later, supportResetlog is set to TRUE by default.

Source reading paused

If the size of swap files on the replication instance exceeds 1 GB, then you receive the following message in the AWS DMS task logs:

"2025-03-31T03:34:27 [SORTER ]W: Reading from source is paused temporarily to enhance performance and avoid storage being full on replication instance. Total storage used by swap files exceeded the limit 1048576000 bytes, please consider checking target latency (sorter_transaction.c:119)";

This error occurs when the source sends changes faster than the target can apply them. AWS DMS writes the extra changes to disk instead of memory, and the replication slows down.

To improve the TARGET_APPLY component's performance, set BatchApplyEnabled to True for supported endpoints. For more information, see Target metadata task settings.

To reduce swap file usage, configure MemoryLimitTotal, MemoryKeepTime, and StatementCacheSize based on the availability on your replication instance. For more information, see How do I optimize AWS DMS memory usage for migration? and Change processing tuning settings.

If the AWS DMS task is stuck, then the task log repeats the same message without a change in the context or timestamp. If there are new redo log operations on the source but AWS DMS isn't logging them, then the task isn't processing events.

Example task logs that repeat the same message:

2025-06-18T04:01:58:945501 [SOURCE_CAPTURE  ]I:  Start processing archived Redo log sequence 36137 thread 2 name +DISK1/TESTDB1/ARCHIVELOG/2025_06_17/thread_2_seq_36137.100476.1204041857 (oradcdc_redo.c:1008)
2025-06-18T04:11:31:899846 [SOURCE_CAPTURE  ]I:  Start processing archived Redo log sequence 21426 thread 4 name +DISK1/TESTDB1/ARCHIVELOG/2025_06_17/thread_4_seq_21426.53870.1204042175  (oradcdc_redo.c:1008)
2025-06-18T04:13:36:602725 [SOURCE_CAPTURE  ]I:  Start processing archived Redo log sequence 36278 thread 1 name +DISK1/TESTDB1/ARCHIVELOG/2025_06_17/thread_1_seq_36278.240264.1204042245 (oradcdc_redo.c:1008)

High redo log generation

If source latency remains high even though AWS DMS reads the logs, then the Oracle database might generate too many redo logs. AWS DMS reads the redo logs to find changes for the replicated tables. A high generation rate slows replication.

To check how many redo logs your Oracle database generates each day, run the following query:

SELECT TRUNC(COMPLETION_TIME, 'DD') AS Day, thread#,
       ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024 / 1024) AS GB,
       COUNT(*) AS Archives_Generated FROM v$archived_log WHERE completion_time > SYSDATE - 1
GROUP BY TRUNC(COMPLETION_TIME, 'DD'), thread#
ORDER BY 1;

If you experience source latency, then take the following actions:

• Make sure that the network between the replication instance and the Oracle source can handle the redo log generation rate.
• Retain logs only for what you require.
• If your Oracle database generates more than 10 GB an hour, then use Binary Reader.
• Set ArchivedLogsOnly to Y so that AWS DMS waits for your Oracle database to archive the online redo logs before AWS DMS reads them.
• If you use Oracle Automatic Storage Manager (ASM) on your source, then check the ASM-related endpoint settings. Make sure that there's optimal throughput between the ASM instance and the DMS replication task.

Optimize performance for high redo generation scenarios

By default, AWS DMS uses Oracle LogMiner for CDC and doesn't require additional connection attributes. If your Oracle source database generates a high volume of redo logs, then take one or more of the following actions to improve AWS DMS performance.

Use Binary Reader for high volume workloads

Binary Reader reads redo logs faster than LogMiner. If high replication lag occurs or Oracle deletes archived redo logs before AWS DMS processes them, then turn on Binary Reader.

To turn on Binary Reader, add the following ECA to the source endpoint:

useLogMinerReader=N;useBfile=Y;

For more information, see Using Oracle LogMiner or AWS DMS Binary Reader for CDC.

Store redo logs in ASM

When you store redo logs in ASM, AWS DMS read performance improves. Oracle Real Application Cluster (RAC) configurations automatically use ASM.

If you use Binary Reader and ASM, then add the following ECA to the source endpoint:

asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;parallelASMReadThreads=6;readAheadBlocks=1000000;

Note: Replace asm_username with your ASM username, RAC_server_ip_address with your IP address, and port_number with your port number.

Related information

Troubleshooting migration tasks in AWS Database Migration Service

Oracle endpoint troubleshooting

Accessing online and archived redo logs