If you’ve managed Oracle environments for any length of time, you already know the pain of database links. They’re one of those features that just works — until maintenance day rolls around, and suddenly every distributed session tied to that link starts throwing errors.
I’ve lost count of how many maintenance windows I’ve planned around this exact issue. You patch a remote database, and every application with an active database link session to it gets slapped with a connection failure. Doesn’t matter how careful your change plan is — someone downstream feels it.
Oracle AI Database 26ai finally addresses this with a feature called Database Links Draining, and honestly, it’s overdue.
Why Database Links Break During Maintenance
Here’s a fairly typical setup:
Nothing unusual there — thousands of Oracle shops run architectures like this. The trouble starts the moment the remote database needs patching, upgrading, or a restart.
When that happens, you’re looking at:
- Active database link sessions dropping without warning
- Distributed transactions failing mid-flight
- Applications throwing errors they were never designed to recover from gracefully
- A DBA team scrambling to coordinate manual timing across systems that don’t talk to each other about maintenance schedules
If you’re running a handful of database links, this is annoying. If you’re a bank or telco running hundreds of them across core systems, it turns into a genuine coordination headache — and I say that from experience.
So What Does Database Links Draining Actually Do?
In short: Oracle now lets the target database warn the source database before it goes down for maintenance, instead of just cutting the connection.
The sequence looks something like this:
- The target database is marked as entering maintenance.
- It sends an in-band notification back through the existing database link.
- The source database picks up that notification.
- The Database Link Coordinator starts draining active sessions instead of killing them outright.
- New connection requests get redirected where possible.
- Maintenance goes ahead once things have quietly wound down.
The important part here is that none of this requires a separate monitoring tool bolted on the side. The notification rides along the same connection the database link already uses.
How the Notification Actually Travels
Instead of the remote database going dark mid-session, it essentially tells the source: “I’m about to go into maintenance — wrap up what you’re doing and route new work elsewhere.” Existing sessions get a chance to finish cleanly rather than being cut off.
This is the same philosophy Oracle already applies to RAC client connection draining — Oracle’s just extending it to cover database-to-database traffic, which honestly should have happened a while ago given how central database links are to distributed Oracle architectures.
What Happens Once Maintenance Mode Kicks In
- In-flight requests are allowed to finish
- Database link sessions get flagged for draining
- By default, the link closes once the current request completes
- New work steers clear of the draining target automatically
No frantic Slack messages to the app team, no last-minute “can we push the window” conversations. That alone is worth the upgrade for teams running distributed banking or telecom workloads.
Backstop: Application Continuity Still Has Your Back
Draining reduces the number of interruptions, but it doesn’t promise zero. For the rare case where something still gets cut short:
- Application Continuity (AC) can replay eligible requests automatically
- Transparent Application Continuity (TAC) extends that replay capability to transactions, when it’s enabled on the service
So you get two layers working together — graceful draining first, automatic replay as the safety net if anything slips through.
Why This Feature Exists in the First Place
According to Oracle, this came directly out of feedback from large financial institutions — and that tracks with what I’ve seen in the field. Banking environments in particular tend to be held together by dense webs of database links connecting:
- Core banking platforms
- Payment processing systems
- Data warehouse sync jobs
- Regulatory reporting feeds
- ERP integrations
- Cross-region RAC clusters
When one node in that web goes down for patching without warning the rest, the blast radius can be a lot bigger than the DBA who scheduled the window ever intended.
What This Actually Buys You
Less planned downtime — fewer interruptions across dependent systems during maintenance.
Cleaner session handling — connections wind down naturally instead of dying abruptly.
Better coordination across distributed databases — without someone manually tracking every dependency on a spreadsheet.
Lower operational risk — one less thing DBAs have to babysit before a patching window.
Fewer support tickets — because end users stop seeing random errors mid-maintenance.
A Quick Before-and-After
Picture an Oracle RAC production database linked to a reporting database.
Before 26ai: the reporting database goes into maintenance, active link sessions fail outright, reports error out, and someone on the app side has to manually retry the connection.
With Database Links Draining: the reporting database announces the maintenance ahead of time, the source database gets the notice, running queries finish up, the link drains on its own, and maintenance starts with barely a ripple on the application side.
That difference alone would have saved me a few stressful patching nights over the years.
Rollout
Oracle has stated Database Links Draining will ship with:
- Oracle AI Database 26ai
- Oracle Database 19c (planned for supported environments)
Backporting it to 19c is a good move — a lot of production banking and telecom environments I work with are still running 19c and won’t be on 26ai for a while yet, so this gives them a real path to benefit sooner.
Final Thoughts
Distributed Oracle architectures aren’t getting any simpler, and database links quietly hold a lot of that complexity together. Database Links Draining doesn’t reinvent anything dramatic — it just closes a gap that’s existed since database links were introduced, by finally letting databases talk to each other about maintenance instead of one side just disappearing.
For anyone running Oracle RAC across banking, telecom, or large enterprise environments where database links are load-bearing infrastructure, this is one of those quiet 26ai features that will save real operational headaches once it lands.
