About Standby Databases

Provides information about enabling and using Autonomous Data Guard for disaster recovery on Autonomous AI Database.

When you use Autonomous Data Guard, the system creates a standby database that is continuously updated with the changes from the primary database. You can use Autonomous Data Guard with a standby in the current region, a local standby, or with one or more standby databases in different regions, cross region standby databases, or you can add both a local standby and one or more a remote standby databases.

You can also create an Autonomous Data Guard standby, either local or remote in a different tenancy.

By selecting from the disaster recovery options that Autonomous AI Database provides, you can choose the features and options that meet your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements.

By default, each Autonomous AI Database instance provides a local Backup-Based Disaster Recovery peer database.

To add automatic failover and to lower your Recovery Time Objective (RTO), you can use a local Autonomous Data Guard standby database.

To use the most resilient disaster recovery option that Autonomous AI Database offers, you can add a local Autonomous Data Guard standby database and one or more cross region Autonomous Data Guard standby databases.

In addition, other options using Backup-Based Disaster Recovery enable you to provide lower cost and higher Recovery Time Objective (RTO) disaster recovery options, as compared to Autonomous Data Guard. See Use Backup-Based Disaster Recovery for details on Backup-Based Disaster Recovery.

Autonomous Data Guard with Local Standby

When you use an Autonomous Data Guard standby database in the current region, Autonomous AI Database provisions a local standby database and monitors the primary database; if the primary database goes down, the standby instance can automatically assume the role of the primary instance or you can fail over to the standby database yourself.

Local Autonomous Data Guard peer databases incur the additional cost of the base CPUs and the storage of the Primary database, including any auto scaled storage usage, billed on the Primary database itself. auto scaled CPUs of the Primary database are not billed for additionally on the local Autonomous Data Guard peer database. See Oracle Autonomous AI Database Serverless Features Billing for more information.

All databases with a local Autonomous Data Guard standby are protected by zero data loss by default, during normal operation. Redo is sent synchronously to the standby redo log destination, and the primary database does not commit transactions until it receives acknowledgment that the data has been received on the standby redo log destination. If the primary database does not receive an acknowledgment within specific time thresholds (due to a network problem, for example), the standby may temporarily fallback to operate asynchronously to preserve primary database availability until it starts to receive acknowledgments in a timely manner again.

See Zero Data Loss Protection with Local Autonomous Data Guard for more information.

Adding a local standby database provides an identical standby database that allows the following, depending on the state of the primary database:

• If your primary database goes down, Autonomous Data Guard converts the standby database to the primary database with minimal interruption. After failover completes, Autonomous Data Guard creates a new standby database for you.

• You can perform a switchover operation, where the primary database becomes the standby database, and the standby database becomes the primary database.

Autonomous AI Database does not provide access to a standby database in the current region. You perform all operations, such as scaling up the ECPU count (OCPU count if your database uses OCPUs) and enabling compute auto scaling on the primary database, and Autonomous Data Guard then performs the same actions on the local standby database. Likewise, you only perform actions such as stopping or restarting the database on the primary database.

A local standby database is created in the same region as the primary database (current region). For better resilience, the standby database is provisioned as follows:

• In regions with more than one availability domain, a local standby database is provisioned automatically in a different availability domain than the primary database.

• In regions with a single availability domain, a local standby database is provisioned automatically in a different fault domain than the primary database (that is, on a different physical machine).

See View Network Information on the OCI Console and Regions and Availability Domains for more information on availability domains.

All Autonomous AI Database features from the primary database are available when the local standby instance becomes the primary, after the system fails over or after you perform a switchover operation, including the following:

• Database Options: The ECPU count (OCPU count if your database uses OCPUs), Storage, Display Name, Database Name, Auto Scaling, Tags, and BYOL licensing options have the same values after a failover to the standby database or after you perform a switchover.

• OML Notebooks: Notebooks and users created in the primary database are available in the standby.

• APEX Data and Metadata: APEX information created in the primary database is copied to the standby.

• ACLs: The Access Control List (ACL) of the primary database is duplicated for the standby.

• Private Endpoint: The private endpoint from the primary database applies to the standby.

  Oracle recommends that for a databases on a Private Endpoint, when you create the subnet you use the regional subnet option for optimum availability and latency. See Creating a Subnet for more information.

• APIs or Scripts: Any APIs or scripts you use to manage the Autonomous AI Database continue to work without any changes after a failover operation or after you perform a switchover.

• Client Application Connections: Client applications do not need to change their connection strings to connect to the database after a failover to the standby database or after you perform a switchover.

• Wallet Based Connections: You can continue using your existing wallets to connect to the database after a failover to the standby database or after you perform a switchover.

Zero Data Loss Protection with Local Autonomous Data Guard

Autonomous AI Database provides zero data loss protection (Recovery Point Objective, RPO = 0) when a local Autonomous Data Guard standby is enabled. It uses synchronous redo transport between the primary and standby databases to ensure that all committed transactions are protected.

This capability is fully managed and requires no additional configuration or tuning. It maintains existing performance and does not introduce additional cost, removing traditional trade-offs between protection and operations.

If you are using a local Autonomous Data Guard standby, zero data loss protection is automatically enabled and no user action is required. As a result, you can achieve zero data loss protection with minimal effort while maintaining performance and cost efficiency.

This capability provides the following benefits:

• Zero Data Loss Assurance: Ensures that all committed transactions are protected (RPO = 0), eliminating uncertainty during recovery and maintaining data consistency.

• Simplified Operations: Requires no manual configuration or tuning. The service is fully managed, reducing operational complexity and effort.

• Cost Efficiency: Introduces no additional cost. Zero data loss protection is included with local Autonomous Data Guard standby.

• Enhanced Business Continuity: Improves availability by combining data protection with continuous application access, helping maintain consistent operations during failures.

Autonomous Data Guard with Cross Region or Cross Tenancy Standby

You can add a cross region or a cross tenancy Autonomous Data Guard standby database.

When you add a standby database in a different region, if the primary instance goes down, Autonomous Data Guard provides a standby database that is physically separated in a remote region. The standby database is available to assume the role of the unavailable primary instance. When you add a standby database in a different tenancy, Autonomous Data Guard provides a standby database that is in a different tenancy. The standby database is available to assume the role of the unavailable primary instance.

See About Autonomous Data Guard with Cross Region Standby for more information.

Autonomous Data Guard Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Autonomous Data Guard monitors the primary database and if the instance goes down, the local standby instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

If a local Autonomous Data Guard standby instance is not available and you have enabled cross region disaster recovery, you can manually fail over to the cross region standby.

If you do not add a cross region Autonomous Data Guard standby, you have the option to add a cross region Backup-Based Disaster Recovery peer. See Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for details on the RTO and RPO with Backup-Based Disaster Recovery.

The RTO is the maximum amount of time required to restore database connectivity to a standby database after a manual or automatic failover is initiated. The RPO is the maximum duration of potential data loss on the primary database.

Local Autonomous Data Guard Standby

When you add a local standby database Autonomous Data Guard provides these options for failover or switchover:

• Automatic Failover:

  The RTO is two (2) minutes. When you enable Autonomous Data Guard, automatic failover is by default configured to guarantee zero data loss during a failover. You can select a data loss limit between 0 and 3600 seconds, if needed. A limit of 0 ensures automatic failover occurs only when zero data loss can be achieved. This means if Autonomous Data Guard can verify that there is no data loss, it automatically fails over in case of a problem. When there is a problem and Autonomous Data Guard determines that the possible data loss is greater than the data loss limit, automatic failover does not happen and you have the option to perform a manual failover.

• Manual Failover or Switchover: the RTO (Recovery Time Objective) is two (2) minutes, and the RPO (Recovery Point Objective) is zero (0).

Cross Region Autonomous Data Guard Standby

When you add a cross region standby database, the RTO and RPO numbers for failover to the Autonomous Data Guard cross region standby are as follows:

• Switchover: the RTO is less than ten (10) minutes and RPO is zero (0).

• Automatic Failover: Not available

• Manual Failover: the RTO is less than ten (10) minutes and RPO is up to one (1) minute.

See the following for more information:

• Automatic Failover with a Standby Database for details on automatic failover.

• Perform a Switchover

• Perform a Manual Failover

• Service Level Objectives (SLOs)

Autonomous Data Guard Operations

Autonomous Data Guard provides a set of operations to manage a standby database, including: to enable, switchover, disconnect, or terminate a standby database.

Autonomous AI Database Disaster Recovery Status

Autonomous AI Database provides information about disaster recovery status on the Autonomous AI Database Details page.

In the Disaster recovery area:

The Role field shows the role of the current database, as follows:

• When you have either a local backup copy peer or a local Autonomous Data Guard standby, the Oracle Cloud Infrastructure Console shows the Role field value Primary. Autonomous AI Database does not provide access to a local standby database (or to a local backup copy peer).

• When using either a cross region backup copy peer or a cross region Autonomous Data Guard standby, the Oracle Cloud Infrastructure Console shows the Role field value Primary if you are viewing the primary database and shows Standby if you are viewing the details for a standby database.

• Switchover: Provides a link so that you can perform a switchover operation.

• Failover: When the primary database is not available and you have a local standby and automatic failover was not successful, the failover link allows you initiate a manual failover.

  When the primary database is not available and you have a cross region standby and failover to a local standby is not possible, the failover link allows you initiate a manual failover to the remote standby database.

To view the peer Autonomous AI Database information, on the Autonomous AI Database details page select the Disaster recovery tab. This shows the peer Autonomous AI Database information. The State column shows the state of a standby database, as follows:

• Provisioning

  • This state shows when you enable Autonomous Data Guard and indicates that a standby database is provisioning (until the standby database state changes to Standby).

  • This state shows after a failover to a local standby when a local standby database is being recreated.

  • This state shows if a restore from backup operation is performed on the primary database, the local standby is recreated and the State column shows Provisioning.

• Standby: Indicates that a standby is available and ready for either a switchover or a failover operation.

  Note: When a standby database is stopped, the standby state shows Standby. A standby database never shows the Stopped state.

• Role Change in Progress: Indicates a failover or switchover operation started.

Autonomous Data Guard Events

You can use Oracle Cloud Infrastructure events to respond when Autonomous AI Database changes its state due to an Autonomous Data Guard related event such as a failover or switchover operation.

Autonomous AI Database events include the following:

• Begin automatic failover

• End automatic failover

• Begin disable Autonomous Data Guard

• Begin enable Autonomous Data Guard

• Begin failover

• Begin switchover

• End disable Autonomous Data Guard

• End enable Autonomous Data Guard

• End failover with failover result of success or failure.

• End switchover with switchover result of success or failure.

Based on events you can perform actions or send notifications. See Events and Notifications for a Standby Database for more information on using events and producing notifications.

Autonomous Data Guard Metrics

You can use Oracle Cloud Infrastructure metrics to monitor Autonomous Data Guard.

Autonomous AI Database metrics includes Peer Lag which is the total time in seconds by which the Disaster Recovery peer lags behind its Primary database.

See Available Metrics: oci_autonomous_database for more information.