When you use an Autonomous Data Guard standby database in the current region, Autonomous 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 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 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 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.

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.

A cross-region standby database is a replica of the primary database and may be used for recovery in case of failure or when the primary is not available. Enabling Autonomous Data Guard with a cross-region standby provides a low RTO solution for disaster recovery in the event an entire region is not available or when the primary database is down for any reason.

Autonomous Data Guard cross-region standby databases incur the additional cost of the base CPUs and twice the storage of the Primary database, including any auto-scaled storage usage, billed on the remote peer database. Auto-scaled CPUs of the Primary are not billed for additionally on the remote peer database. The number of base CPUs is specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count (OCPU count) field on the Oracle Cloud Infrastructure Console.

Autonomous Database allows you to create one or more remote disaster recovery peer databases, depending on your compute model:

• OCPU Compute Model: You can add one remote standby database in a paired region. Paired regions are remote regions where you can create a cross-region peer.

• ECPU Compute Model: You can add multiple remote disaster recovery peers, with up to one peer in each remote paired region. For example if your primary database is in the IAD region, you can add a standby database in PHX and a standby database in SJC, but you cannot add two remote disaster recovery peers in PHX.

Paired regions are remote regions where you can create a cross-region standby database. See Autonomous Database Cross-Region Paired Regions for more information on paired regions.

You perform almost 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. Autonomous Data Guard then performs the same actions on the cross-region standby database.

After you add a remote standby database, Autonomous Database provides access to the remote standby database from the Oracle Cloud Infrastructure Console. Autonomous Database provides access to the remote standby database so that you can perform some operations independently on the remote standby, such as configuring networks and VCNs for private endpoints and adding tagging to define keys and values that are not replicated between the primary database and the remote standby.

You cannot connect to a cross-region standby while it operates as a standby database, and it is not available for read-only operations. You can connect to the database in the following cases:

• When the database assumes the primary role after a failover or switchover operation. See Perform a Switchover and Perform a Manual Failover for more information.

• After you convert a standby database to a snapshot standby database. See Convert Cross-Region Disaster Recovery Peer to a Snapshot Standby for more information.

The following areas have differences for failover or switchover from the primary database to a remote standby database, when compared to failover or switchover to a local standby:

• Display Name: The display name has a "_region" extension. Where region is the region name, such as IAD or BOM.

  If you created the cross-region peer before the introduction of support for multiple cross-region peers, the cross-region peer's display name has a "_Remote" extension.

• OML Notebooks: After a cross-region switchover or failover, OML notebooks from primary that was switched over or failed over are not present in the primary database (the current primary database after the role change). New OML notebooks can be created.

• Private Endpoint: You can independently configure and update private endpoints on a standby database before failover or before you perform a switchover. This allows you to have a private endpoint that is configured differently, after failover or after you perform a switchover. Autonomous Database does not keep the networking configuration synchronized from the primary to a remote standby.

  VCN Peering and domain forwarding are required for wallets to work across regions, with Autonomous Databases with a private endpoint with an Autonomous Data Guard standby, where the primary and the standby database are in different VCNs. See Remote VCN Peering using an RPC and DNS in Your Virtual Cloud Network for information on VCN peering and domain forwarding.

• Network Access Control List: By default a disaster recovery primary database and remote peer databases use the same network Access Control Lists (ACLs). Optionally, you can independently edit network ACLs on a remote peer database. This allows you to use different ACLs on a remote peer database.

  See Manage Remote Peer Network ACLs for more information.

• Tags: Tags are handled independently on a disaster recovery primary and on remote peer database. This means:

  • When you add, remove, or update a tag on a remote peer, the change applies only on the remote peer database.

  • When you add, update, or remove a tag on the primary, the tag is not added, updated, or removed on remote peer databases.

• APIs or Scripts: Any APIs or scripts you use to manage the Autonomous Database need to be updated to call the APIs on the primary database, the current primary database, after a failover or after you perform a switchover.

  For mTLS connections, you must download a wallet from the primary database, the current primary database, after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.

• Client Applications: Client applications need to connect using the connection strings and wallet you download from the primary database, the current primary database, after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.

• Wallet Based Connections: You must download a wallet and connect using the connection strings from the primary database, the current primary database, to connect to the database after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.

• Autonomous Database Tools: The tools have different URLs in the primary database, the current primary database, after a failover or after you perform a switchover (the tools URLs do not change for a switchover or failover to a local standby):

  • Database Actions

  • Oracle APEX

  • Oracle REST Data Services (ORDS)

  • Graph Studio

  • Oracle Machine Learning Notebooks

  • Data Transforms

  • MongoDB API

• Oracle Cloud Infrastructure Object Storage Usage: After you failover or switchover from the primary database to a standby database, on the primary database (the current primary database) the credentials and the URLs that provide access to Object Storage continue to work as they did before the failover or the switchover, providing access to the following:

  • External tables

  • External partitioned tables

  • External hybrid partitioned tables

  Note
  
  This applies when the Object Storage is available. For rare scenarios when the Object Storage is not available, Oracle recommends having Object Storage backups or replication to a different region. If the Object Storage is not available (that is the Object Storage resource you used with the Primary before a switchover or failover), you may update your user credentials and parameters that set URLs for Object Storage so that the parameters specify values to access an available region's Object Storage. See Using Replication for more information.

OCI Full Stack Disaster Recovery with an Autonomous Data Guard Cross-Region Standby

When Full Stack Disaster Recovery is enabled, the Autonomous Database details page, under Disaster recovery, shows the Full Stack DR field as Enabled.

Description of the illustration adb_full_stack_dr_enabled.png

See Use OCI Full Stack Disaster Recovery with Autonomous Database for more information.

• Autonomous Data Guard Database Role
  After you add a cross-region standby database, each database has a designated role: primary, standby, or snapshot standby.
• Autonomous Data Guard Cross-Region Failover and Switchover
  You can have one local disaster recovery peer and optionally you can add one or more cross-region peers (multiple cross-region peers are allowed with the ECPU compute model). In both the local and cross-region cases, either peer can be a Backup-Based Disaster Recovery copy or an Autonomous Data Guard standby.
• Autonomous Data Guard Database Cross-Region Backup and Restore
  After you add an Autonomous Data Guard cross-region standby database, backup and restore from backup is handled as follows:
• Cross-Region Disaster Recovery Connection Strings and Wallets
  When you add an Autonomous Data Guard cross-region (remote) standby database, or when you use a cross-region Backup-Based Disaster Recovery peer, the wallet and connection string from the primary database contains only the hostname of the primary database.
• Autonomous Data Guard with Customer Managed Keys
  When you add an Autonomous Data Guard cross-region standby, there are special considerations when the primary database is using customer-managed keys, or if you want to switch to using customer-managed keys on the primary database.
• Replicating Backups to a Cross-Region Autonomous Data Guard Standby
  When you add a cross-region Autonomous Data Guard standby you can enable cross-region backup replication so that automatic backups from the primary are also available on a remote region.
• Autonomous Data Guard Cross-Region BYOL Licensing
  The BYOL ECPU limit you set on an Autonomous Data Guard Primary database does not apply to a cross-region or cross tenancy Autonomous Data Guard Standby database.

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.

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

Autonomous Database provides information about disaster recovery status on the Autonomous 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 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 Database information, under Resources click Disaster recovery. This area lists the peer autonomous 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.

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

Autonomous 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.