1 Answer
- Newest
- Most votes
- Most comments
0
Hey.. Robert
The issue you're facing is likely due to the missing archived redo logs on the source Oracle database. Ensure that archived redo logs are retained and available for AWS DMS to process.
To fix this, you can: Increase retention of archived redo logs on the Oracle database to ensure they are available during DMS replication. Make sure supplemental logging is enabled correctly for DMS to capture changes.
Example to enable supplemental logging:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
Also, verify that the UseLogminerReader is set properly for binary reader use.
Relevant content
- asked 3 months ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
I do have that set, and I have "useLogMinerReader=N;useBfile=Y" in my ECA for my source endpoint. However, it is still failing whenever a backup runs on that particular database.
It might be that the backup process is deleting the redo logs too early. You could try disabling RMAN log deletion during backups, so the redo logs stay available for DMS. Also, double-check if UseBfile is actually being recognized by DMS.
Maybe increasing the retention of the redo logs during the backup window could help too. Worth a shot!
Even if I run a backup once a day, the DMS task fails on an archivelog that may have been sitting out there up to 6 hours. Is there that much lag time on DMS replication? Also, I thought that by enabling Binary mode, it reads the online redo logs and is not dependent on the archive logs for the CDC.
How would I confirm that DMS is indeed using the UseBfile mode?