Enable Autonomous Data Guard for mission-critical production databases that require better uptime requirements for disasters from data corruptions, and database or site failures, while still reaping the Autonomous Database High Availability Option benefits.

Additionally, the read-only standby database provides expanded application services to offload reporting, queries, and some updates. The read-only standby database is only available with Autonomous Data Guard on Dedicated Infrastructure.

Enabling Autonomous Data Guard adds one symmetric standby database to an Exadata rack that is located in the same availability domain, another availability domain, or in another region. The primary and standby database systems are configured symmetrically to ensure that performance service levels are maintained after Data Guard role transitions. Autonomous Database Serverless supports configuring two standby databases, and Autonomous Database on Dedicated Infrastructure is restricted to a single database at this time. For Autonomous Database Serverless, a multiple standby configuration consists of a local standby database in the same region and a cross-region standby database.

Oracle Autonomous Data Guard features asynchronous redo transport (in maximum performance mode) by default to ensure zero application performance impact. The standby database can be placed within the same availability domain, across availability domains, or across regions. MAA recommends placing the standby in separate availability domain or in a different region for the best fault isolation. Data Guard zero data loss protection can be achieved by configuring synchronous redo transport (in maximum availability mode); however, maximum availability database protection mode with synchronous redo transport is only available with Autonomous Database on Dedicated Infrastructure, and the standby database is typically placed in a different availability domain in the same region, or across multiple regions if the round trip latency between regions is minimal (< 5ms) to ensure a negligible impact on application response time and throughput while providing fault isolation. Furthermore, local and remote virtual cloud network peering provides a secure, high-bandwidth network across availability domains and regions for any traffic between the primary and standby servers.

Backups are scheduled automatically on both primary and standby databases, and they are stored in Oracle Cloud Infrastructure Object Storage. Autonomous Database with Exadata Cloud at Customer, provides you with an option to backup to NFS or Zero Data Loss Recovery Appliance; however, replication of those backups is the responsibility of the customer. Those backups can be used to restore databases in the event of a double disaster, where both primary and standby databases are lost.

The uptime service-level agreement (SLA) per month is 99.995% (maximum 132 seconds of downtime per month) and recovery time objectives (downtime) and recovery point objectives (data loss) are low, as described in the table below. To achieve the application uptime SLAs where most months would be zero downtime, refer to Maintaining Application Uptime (XREF).

Automatic Data Guard failover with Autonomous Database Serverless supports a data loss threshold service level which will initiate an automatic failover to the standby database if the data loss is below that threshold. Zero data loss failover is not guaranteed for Autonomous Database Serverless but possible when the primary database fails while primary system container and infrastructure is still available allowing the remaining redo to be sent and applied to the standby database. Automatic Data Guard failover with Autonomous Database on Dedicated Infrastructure supports zero data loss or low data loss threshold service levels. In all cases, automatic Autonomous Data Guard failover will occur for primary database, cluster, or data center failures when those data loss service levels can be guaranteed. The target standby becomes the new primary database, and all application services are enabled automatically. A manual Data Failover option is provided in the OCI Console. For the manual Data Guard failover option, the calculated downtime for the uptime SLA starts with the time to execute the Data Guard failover operation and ends when the new primary service is enabled.

You can choose whether your database failover site is located in the same availability domain, in a different availability domain within the same region, or in a different region, contingent upon application or business requirements and data center availability.

Table 25-2 Autonomous Data Guard Recovery Time (RTO) and Recovery Point (RPO) Service-level Objectives

Localized events, including:

Zero or Near Zero

Zero

Events that require failover to the standby database using Autonomous Data Guard, including:

Few seconds to two minutes4

Zero with maximum availability protection mode (uses synchronous redo transport). Most commonly used for intra-region standby databases. This is available for Autonomous Data Guard on Dedicated Infrastructure.

Near zero for maximum performance protection mode (uses asynchronous redo transport). Most commonly used for cross-region standby databases. Also used for intra-regional standby databases and to ensure zero application impact. This is applicable for both Autonomous Data Guard on Dedicated Infrastructure and Autonomous Database Serverless. RPO is less 10 seconds.

RPO may be impacted by network bandwidth and throughput between primary and standby clusters.

1 Service-Level Downtime (RTO) excludes detection time that includes multiple heartbeats to ensure the source is indeed inaccessible before initiating an automatic failover.

2 The Active Data Guard automatic block repair for physical corruptions feature is only available for Autonomous Data Guard on Dedicated Infrastructure.

3Regional failure protection is only available if the standby is located across regions.

4 The back end Autonomous Data Guard role transition timings are much faster than what is indicated by the Cloud Console refresh rates.

Both Autonomous Database on Dedicated Infrastructure and Autonomous Database Serverless have been MAA Gold validated and certified. Autonomous Database on Dedicated Infrastructure was validated with a standby database in the same region, and also with a standby database in a different region, and the above SLAs were met when the standby target was symmetric to the primary. RTO and RPO SLAs were met with redo rates of up to 1000 MB/sec. Autonomous Database Serverless was validated and certified with a standby database in the same region only, and met the above SLAs when the standby target had symmetric resources. RTO and RPO SLAs were met with redo rates up to 300 MB/sec for the entire Container Database (CDB) where the target Autonomous Data Guard pluggable database resides.