This post is part of a blog series.
With a Data Guard asynchronous configuration, there is usually one asynchronous process that handles redo for multiple standby databases. If one or more standby databases are much slower at receiving redo than the others, Data Guard can automatically create extra asynchronous processes for the slower ones.
Before version 26ai, each asynchronous process could open only one connection for each standby database. This limited throughput when network setups restricted bandwidth per connection.
Starting in 26ai, an asynchronous process can notice when a connection is using all its available bandwidth and then open extra connections for better throughput and less lag. This change helps especially in cloud environments, where each connection often has its own bandwidth limit. On the receiving side, there is one RFS process for every connection.
You do not need to change any configuration to get this benefit. Just upgrade to 26ai and the improvement automatically works.
Latest posts by Ludovico (see all)
- Data Guard 26ai – #8: Multiple ASYNC connections - February 5, 2026
- Data Guard 26ai – #7: Rolling Upgrade with Application Continuity - February 4, 2026
- Data Guard 26ai – #6: Up to four Fast-Start Failover Observers - February 3, 2026