跳至內容

AWS DMS Fatal Errors - Lag Issue?

0

We have DMS CDC running with Binary Reader (Oracle RDS 19c source → Aurora PostgreSQL target). When the task starts, it successfully reads through the existing archived redo logs — we can see 91 log sequences processed in CloudWatch with no errors. However, once DMS catches up to the present and reaches the current online redo log (which hasn't been archived yet), it waits approximately 5 minutes and then fatally errors with 'Redo log with the sequence X does not exist.'

We believe the root cause is that this is a lower environment with minimal traffic, so Oracle is not generating enough redo activity to trigger a log switch and archive the current log within DMS's retry window. In a production environment with higher transaction volume, logs would archive frequently enough that this likely wouldn't be an issue.

We don't have RDSAdmin access to change archive_lag_target on the Oracle RDS instance, so we're looking for a DMS-side solution. Is there a task setting or source endpoint ECA that controls how long Binary Reader waits for the next archived redo log before erroring, so we can extend it beyond the current ~5 minute window?

已提問 3 個月前檢視次數 85 次
1 個回答
0

The issue you're experiencing is related to AWS DMS's inability to access Oracle archive logs before they become available. When DMS catches up to the current online redo log that hasn't been archived yet, it has a limited retry window before failing with the "Redo log with sequence X does not exist" error.

For Amazon RDS Oracle instances, you can increase the archive log retention period to help prevent this issue. You can run the following procedure to extend log retention:

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

This increases the retention time for archived logs, giving DMS more time to process them before they're removed from the server.

However, your specific scenario is slightly different - you're dealing with logs that haven't been archived yet rather than logs that have been purged. Unfortunately, there isn't a DMS task setting or endpoint-specific configuration (ECA) that directly controls the Binary Reader's wait time for the next archived redo log to become available.

The fundamental challenge is that DMS needs archived redo logs to process changes, and in low-traffic environments, Oracle may not generate enough activity to trigger automatic log switches. While you mentioned not having direct RDSAdmin access to modify archive_lag_target, this Oracle parameter is actually what would force a log switch after a specified time period, which would be the most direct solution to your problem.

You may want to consider working with your database administrators to have archive_lag_target configured on the Oracle RDS instance, as this is the most effective way to ensure logs are archived regularly in low-activity environments, preventing the timeout issue you're experiencing with DMS.
Sources
Troubleshooting migration tasks in AWS Database Migration Service - AWS Database Migration Service

已回答 3 個月前
專家
已審閱 3 個月前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。