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.

Topics

Parent topic: Use Standby Databases with Autonomous Data Guard for 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 automatically assumes the role of the primary instance.

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 Database Serverless Features Billing 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.

Parent topic: About Standby Databases

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.

Parent topic: About Standby Databases

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 or Switchover:

    When you enable Autonomous Data Guard you can select a data loss limit. The default data loss limit for automatic failover is 0 (valid values are 0 to 3600 seconds). For example, a data loss limit of 0 means that Autonomous Data Guard only performs automatic failover when there is no data loss. 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: the RTO is two (2) minutes and the RPO 10 seconds

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:

Parent topic: About Standby Databases

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.

Operation Description
Convert to Snapshot Standby

Converting a disaster recovery peer to a snapshot standby opens the database in read-write mode and the cross-region disaster recovery peer temporarily stops refreshing data from the source database.

See Convert Cross-Region Peer to Snapshot Standby for more information.

Disable Autonomous Data Guard

If you have a local standby database or a cross-region standby database, you can change the disaster recovery type to Backup-Based Disaster Recovery for the local standby or you can terminate a cross-region standby. In either case, disabling Autonomous Data Guard terminates the standby database.

See Update Standby to Use a Backup Copy Peer or Disable a Cross-Region Standby Database for details.

Disconnect Standby

When you disconnect a cross-region standby, the standby is disassociated from the Primary database. This converts the database from a peer database to a standalone database. Following the disconnect operation you are not allowed to reconnect to the Primary.

See Disconnect a Peer Database and Disconnect a Snapshot Standby for more information.

Enable Autonomous Data Guard

If you are using Backup-Based Disaster Recovery, you can update your disaster recovery type to local (current region) Autonomous Data Guard, or you can add an Autonomous Data Guard cross-region standby.

See Enable Autonomous Data Guard and Add a Cross-Region Standby Database for details.

Failover - Automatic

After you add a local Autonomous Data Guard standby database, the system monitors the primary instance and automatically fails over to a local standby database in certain scenarios.

See Automatic Failover with a Standby Database for more information.

Failover - Manual

If the primary database is not available you can perform a manual failover to change roles to make a standby database the primary database:

  • If a local standby is available, you can manually failover to the local standby (you do not have the option to failover to a remote standby if a local standby is available).
  • If a local standby is not available, you have the option to manually failover to a remote standby.

See Perform a Manual Failover for details.

Switchover

When Autonomous Data Guard is enabled, switchover changes the roles of the primary and the standby, the standby database becomes the primary, and the primary database becomes the standby. If you have both a local standby database (current region), and a cross-region standby database (remote), you can choose to switchover to either the local standby or the remote standby.

See Perform a Switchover for details.

Terminate

If you want to terminate the primary instance, select More actions and Terminate. Terminating the primary instance also terminates a local standby database.

If you have both a local standby database (current region), and a cross-region standby database, you must terminate the cross-region standby database before you terminate the primary database.

See Terminate a Cross-Region Standby Database for details.

Parent topic: About Standby Databases

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.

Parent topic: About Standby Databases

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.

Parent topic: About Standby Databases

Autonomous Data Guard Metrics

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

Autonomous AI Database metrics include the following:

  • Peer Lag: 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.

Parent topic: About Standby Databases