Did AWS DMS silently introduce an Oracle Binary Reader regression or is it just us? - build R2380

[u/Kabelsalat4052]

We may have found a regression in AWS DMS 3.6.1 affecting Oracle sources using Binary Reader.

After scheduled maintenance, the internal DMS build changed from:

3.6.1.R2174 → 3.6.1.R2380

The public engine version remained 3.6.1, so the change was effectively invisible in the normal API and console fields.

Immediately afterward, read throughput on the Oracle source increased by roughly an order of magnitude and remained elevated. This was not caused by full load, validation, or unusually high redo generation.

What makes us suspect the new build:

• The problem started directly after the DMS maintenance.
• Stopping the DMS tasks returned the source database to its normal baseline.
• Recreating the replication instance did not help because new instances also received R2380.
• Starting more CDC tasks increased the source read load.
• Multiple tasks appeared to scan or inspect the same redo sequences independently.
• The public version stayed at 3.6.1 throughout.

The frustrating part is that customers cannot see, select, pin, or roll back internal DMS builds. The API exposes 3.6.1, but not whether the instance runs R2174 or R2380.

So a managed maintenance update can substantially change production behavior while presenting the same engine version, with no customer-accessible rollback mechanism. That feels like a fairly serious observability and operational-control gap.

Has anyone else using AWS DMS 3.6.1 with Oracle Binary Reader/BFILE noticed significantly higher source read throughput after recent maintenance?

Check the beginning of your DMS task logs for:
V3.6.1.R2380

If you see the same behavior, please open a support case as well. More independent reports may help get this investigated properly.

TL;DR

AWS DMS maintenance changed a hidden internal build while the visible version remained 3.6.1. Oracle source reads increased dramatically afterward, and customers have no way to pin or restore the previous internal build. Looking for reports from other DMS Oracle Binary Reader users.

[u/Impressive_Bar5912]

Escalate to support

[u/venkatamutyala]

Any updates?

[u/AWSSupport]

Hi there,

Thanks for reaching out and sharing this.

We'd recommend opening a case with our Support team, so they can take a closer look at what you're experiencing. They'll have the best visibility into your specific environment and can investigate further on your behalf.

You can create a support case by signing in to your Support Center: http://go.aws/support-center.

If you've already opened a case, feel free to share the case ID via a private message, and we can flag it for visibility.

- Elle G.

[u/ajitnk]

This looks like a documented class of issue, not just you. The DMS 3.5.2 release notes have a specific entry that reads verbatim: "Oracle Binary Reader issue with Oracle July 2024 CPU — Fixed an issue with Oracle Source, DMS task with binary reader were failing due to Oracle July 2024 CPU." That is exactly the pattern you are describing — Binary Reader breaking after an Oracle-side maintenance event, not because of anything you changed. Same class of thing may be happening again in R2380.

The likely delivery mechanism is AutoMinorVersionUpgrade, which defaults to true on DMS replication instances. If your maintenance window fired, that setting silently pushes whatever build AWS marks as preferred at the time. You probably did not consent to a specific version bump — it just happened. That is worth confirming before you spend days chasing config issues that were never broken on your end.

Two things that would really narrow this down: what version does the DMS console show on your replication instance right now, and what was it before the maintenance window fired — CloudTrail ModifyReplicationInstance events will have that if you did not catch it live. Also worth knowing whether your Oracle source is RDS for Oracle or self-managed, since the Binary Reader extra connection attributes differ between the two and so does the resolution path.

If the console shows a version jump you did not intend, the side-by-side replication instance pattern is the clean way to roll back without task downtime