HADR now supports multiple standby databases

The high availability disaster recovery (HADR) feature now allows up to three HADR standby databases. A multiple standby setup improves your ability to protect your data while still keeping it highly available, all with a single technology.

In previous releases, the HADR feature allowed only a single standby database, meaning that you could have your data in at most two sites. With multiple standbys, you can guard against a scenario in which a region-wide outage or disaster brings down both the primary and the standby databases. For example, you can have your primary and one of your standby databases in the same location, with one or two additional standbys a long distance away. These distant standbys automatically run in SUPERASYNC mode, so the distance does not have an impact on activity on the primary database.

Another benefit of having multiple standbys is that they eliminate the implicit trade-off between high availability and disaster recovery. You can have one standby database, the principal HADR standby database, meet your high availability requirements by configuring it to run in close synchronization with the primary and by setting up this standby database for timely, automated failover in the event of an outage. You can also have one or two other standby databases, the auxiliary HADR standby databases, meet your disaster recovery requirements by situating them in a remote site. Previously, the only way to achieve this kind of setup was to use HADR for the first requirement and a different technology for the second.

All the standby databases support the HADR reads on standby feature, and all of them support both forced and unforced takeovers. In addition, you can use one of the standbys with the new time-delayed replay feature. Using this feature, you can keep a standby behind the primary in terms of log replay so that you have time to recover from application errors that cause data loss on the primary.