Oracle Cloud Infrastructure Documentation

Configure and Manage Autonomous Data Guard

The Autonomous Data Guard feature of Autonomous Database on Dedicated Exadata Infrastructure enables you to keep your critical production databases available to mission critical applications despite failures, disasters, human error, or data corruption. This kind of capability is often called disaster recovery.

Starting March 2025, Autonomous Container Databases (ACDs) can enable Autonomous Data Guard from their Details page and create up to two standby ACDs. With this release, the previous Autonomous Data Guard Associations model and associated APIs will be deprecated and replaced with the new Autonomous Data Guard Groups model and APIs. All new ACDs provisioned after March 2025 from the Oracle Cloud Infrastructure (OCI) console will automatically use the new Autonomous Data Guard Groups model. See Knowledge Base for more information.

To transition existing ACDs, customers can migrate to the new model using any of the following options: See Autonomous Data Guard Models to know more details about the new model.

Parent topic: Create and Manage Autonomous Container Databases

Enable Autonomous Data Guard on an Autonomous Container Database

You can enable Autonomous Data Guard from the Details page of an Autonomous Container Database.
Note

You cannot enable Autonomous Data Guard on an ACD with an active maintenance run scheduled within the next three days.

Required IAM Permissions

inspect cloud-autonomous-vmclusters

use autonomous-container-databases

Procedure

Note

When an add standby ACD operation is in progress, any scheduled maintenance on that ACD will not begin until the add standby operation is complete.
  1. Go to the Details page of the Autonomous Container Database for which you want to enable Autonomous Data Guard.
  2. Click Enable under Autonomous Data Guard in Autonomous Container Database information.
  3. Alternatively, you can also click Add Standby on Autonomous Data Guard groups or Autonomous Data Guard associations under Resources.
  4. Fill out the Add Standby dialog with the following information:
    Setting Description Notes
    Peer Autonomous Container Database compartment Select the standby Autonomous Container Database compartment.  
    Peer Autonomous Container Database name Enter a name for the standby ACD.  
    Peer region Select a region for the standby ACD.

    The primary and secondary ACDs can also be deployed in different regions (cross-region). In a cross-region Autonomous Data Guard setup using customer-managed keys or KMS, depending on the number of Autonomous Databases in the primary ACD, new key versions will automatically be generated for the standby databases in the cross-region Vault.

    Peer Exadata Infrastructure Select the underlying Exadata Infrastructure resource for the standby ACD.  
    Peer Autonomous Exadata VM Cluster (AVMC) Select the parent AVMC for the standby ACD.  
    Protection Mode Select Maximum performance or Maximum availability from the drop-down list.

    Maximum Performance is selected by default.

    For information about Autonomous Data Guard and guidance in choosing where to place the standby autonomous container database and which protection mode to use, see About Autonomous Data Guard and Autonomous Data Guard Configuration Options.

    Peer database backup configuration Select a Backup Destination type from the drop-down list. APPLIES TO: Applicable Exadata Cloud@Customer only

    A backup destination is required on Exadata Cloud@Customer deployments.

    Peer database maintenance preference Select the number of days for which the standby ACD maintenance will be scheduled before primary ACD maintenance because standby ACD is always patched before primary ACD. This option is available only when the primary ACD has defined a custom maintenance schedule.
  5. Confirm to add the standby database.
    Note

    Once enabled, Autonomous Data Guard can only be disabled by terminating the standby ACD.

View the Status of an Autonomous Data Guard Configuration

You view the status of an Autonomous Data Guard configuration from the Details page of the primary or standby Autonomous Container Database in the configuration.

Required IAM Policies

inspect autonomous-container-databases

Procedure

  1. Go to the Details page of the primary or standby Autonomous Container Database in the Autonomous Data Guard configuration.

    For instructions, see View Details of an Autonomous Container Database.

    You can view the Autonomous Data Guard details such as its status, peer role, peer state, protection mode, and automatic failover setting under Autonomous Data Guard in Autonomous Container Database information.

  2. You can also view the Autonomous Data Guard details by clicking Autonomous Data Guard groups or Autonomous Data Guard associations under Resources.

    The Autonomous Data Guard table displays information about the peer container database, the current apply lag and transport lag, state, and last role change and creation dates.

Add a Second Standby Autonomous Container Database

In an Autonomous Data Guard setup, you can add a second standby Autonomous Container Database (ACD) to the primary ACD. The second standby ACD must be in the same tenancy as the primary ACD.

Prerequisites

To be able to add a second standby ACD:

  • The primary ACD must have been provisioned on or after March 2025 or migrated to the Autonomous Data Guard Groups model discussed in Configure and Manage Autonomous Data Guard.

  • The first standby ACD should not have automatic failover enabled. You must disable automatic failover on the first standby before adding the second standby and can re-enable later.

Required IAM Permissions

use autonomous-container-databases

Procedure

Note

  • When an add standby ACD operation is in progress, any scheduled maintenance on that ACD will not begin until the add standby operation is complete.
  • Adding a standby database requires an automatic non-rolling restart for the first standby database. The primary database does not have any down-time because of this non-rolling restart.

  1. Go to the Details page of the Autonomous Container Database for which you want to add a second standby database.

    For instructions, see View Details of an Autonomous Container Database.

  2. Click Add standby in Autonomous Data Guard groups under Resources.

  3. Fill out Add standby with the following information:
    Setting Description Notes
    Peer Autonomous Container Database compartment Select the standby Autonomous Container Database compartment.  
    Peer Autonomous Container Database name Enter a name for the standby ACD.  
    Peer region Select a region for the standby ACD.

    In a cross-region Autonomous Data Guard setup, depending on the number of Autonomous Databases in the primary ACD, new key versions will automatically be generated in the cross-region Vault for the standby databases.
    Peer Exadata Infrastructure Select the underlying Exadata Infrastructure resource for the standby ACD.  
    Peer Autonomous Exadata VM Cluster (AVMC) Select the parent AVMC for the standby ACD.  
    Peer Database Backup Configuration

    APPLIES TO: Applicable Exadata Cloud@Customer only

    Select the backup destination type for the second standby database from the drop-down list.

    		  
    Note

    You cannot explicitly set maintenance preferences for the second standby ACD as it inherits these preferences from the first standby ACD of the primary ACD.
  4. Click Add standby.

Reinstate the Disabled Standby in an Autonomous Data Guard Configuration

After a failover has occurred and the failed primary Autonomous Container Database assumes a disabled, standby role, you can reinstate the failed database to an enabled, standby role from its Details page.

Required IAM Policies

use autonomous-container-databases

Procedure

Depending on your ACD's Autonomous Data Guard model, follow the instructions from one the following tabs. See Configure and Manage Autonomous Data Guard to know more about the Autonomous Data Guard models.

  1. Go to the Details page of the Disabled standby ACD that you want to reinstate.

    For instructions, see View Details of an Autonomous Container Database.

    Tip:

    The primary database that you failed over is labeled as "Disabled Standby" in the list of Autonomous Container Databases for a compartment.

  2. Click Reinstate.

  3. Provide a confirmation to proceed with the reinstatement of the disabled standby ACD.

    The states of the peer databases become Role Change in Progress... until the reinstate action is complete. Upon completion, the role of the Disabled Standby container database becomes Standby and its state changes to Available.

  1. Go to the Details page of the disabled standby Autonomous Container Database that you want to reinstate.

    Tip:

    The primary database that you failed over is labeled as "Disabled Standby" in the list of Autonomous Container Databases for a compartment.

    For instructions, see View Details of an Autonomous Container Database.

  2. Click Autonomous Data Guard assocations. The list of peer databases is listed in a tabular column. Click the ellipsis (three vertical dots) More Actions in the database row where you want to switch roles and click Reinstate.

    The states of the peer databases become Role Change in Progress... until the reinstate action is complete. Upon completion, the role of the Disabled Standby container database becomes Standby and its state changes to Available.

Switch Roles in an Autonomous Data Guard Configuration

You switch the roles of the primary and standby Autonomous Container Databases in an Autonomous Data Guard configuration from the Details page of the primary or standby Autonomous Container Database.

Required IAM Policies

use autonomous-container-databases

Procedure

Depending on your ACD's Autonomous Data Guard model, follow the instructions from one the following tabs. See Configure and Manage Autonomous Data Guard to know more about the Autonomous Data Guard models.

  1. Go to the Details page of the standby ACD that you want to switch roles with the primary ACD in the Autonomous Data Guard configuration.

    For instructions, see View Details of an Autonomous Container Database.

    Note

    You can not switch roles of the primary and standby ACDs in an Autonomous Data Guard configuration where the standby is in the snapshot standby role.

  2. Click Switchover.

  3. Enter the ACD name in the confirmation dialog, and click Switchover.

    Oracle Autonomous Database on Dedicated Exadata Infrastructure sets the statuses of the standby and its primary container databases to Role Change in Progress... and begins the switchover operation, which causes the primary container database to assume the standby role and the standby container database to assume the primary role. Upon completion, the statuses of both container databases returns to Active.

  1. Go to the Details page of the primary or standby Autonomous Container Database in the Autonomous Data Guard configuration.

    For instructions, see View Details of an Autonomous Container Database.

    Note

    You can not switch roles of the primary and standby Autonomous Container Databases in an Autonomous Data Guard configuration where the standby is in the snapshot standby role.
  2. Click Autonomous Data Guard associations to list the peer database in a tabular column. Click the ellipsis (three vertical dots) More Actions in the database row where you want to switch roles and click Switchover.

  3. Enter the ACD name in the confirmation dialog, and click Switch over.

    Oracle Autonomous Database on Dedicated Exadata Infrastructure sets the statuses of both container databases to Role Change in Progress... and begins the switchover operation, which causes the primary container database to assume the standby role and the standby container database to assume the primary role. Upon completion, the statuses of both container databases returns to Active.

Fail Over to the Standby in an Autonomous Data Guard Configuration

You fail over to the standby Autonomous Container Databases in an Autonomous Data Guard configuration from the Details page of the standby Autonomous Container Database.

Required IAM Policies

use autonomous-container-databases

Procedure

Depending on your ACD's Autonomous Data Guard model, follow the instructions from one the following tabs. See Configure and Manage Autonomous Data Guard to know more about the Autonomous Data Guard models.

  1. Go to the Details page of the standby ACD to which you want to fail over in the Autonomous Data Guard configuration.

    For instructions, see View Details of an Autonomous Container Database.

  2. Click Failover.

  3. In case of a snapshot standby Autonomous Container Database, you see a message alerting you that the snapshot standby will be converted to physical standby after discarding all its local updates and applying data from your primary database. Click Failover to proceed.

  4. Enter the ACD name in the confirmation dialog, and click Fail over.

    Oracle Autonomous Database on Dedicated Exadata Infrastructure sets the status of the Standby container database to Role Change in Progress and begins the failover operation. Upon completion, the role of the Standby container database becomes Primary and the role of the Primary container database becomes Disabled Standby with the Unavailable state.

  1. Go to the Details page of the standby Autonomous Container Database in the Autonomous Data Guard configuration.

    For instructions, see View Details of an Autonomous Container Database.

  2. Click Autonomous Data Guard associations to list the peer database in a tabular column. Click the ellipsis (three vertical dots) More Actions in the database row where you want to switch roles and click Failover.

  3. In case of a snapshot standby Autonomous Container Database, you see a message alerting you that the snapshot standby will be converted to physical standby after discarding all its local updates and applying data from your primary database. Click Failover to proceed.

    Oracle Autonomous Database on Dedicated Exadata Infrastructure sets the status of the Standby container database to Role Change in Progress and begins the failover operation. Upon completion, the role of the Standby container database becomes Primary and the role of the Primary container database becomes Disabled Standby with the Unavailable state.

Update Autonomous Data Guard Settings

You can update the settings of an Autonomous Data Guard from the Details page of the primary Autonomous Container Database in the configuration.

Required IAM Policies

use autonomous-container-databases

Procedure
  1. Go to the Details page of the primary Autonomous Container Database in the Autonomous Data Guard configuration.
  2. Click Update Autonomous Data Guard from More actions.
    The Update Autonomous Data Guard dialog displays the current settings for Protection Mode and Automatic Failover.
  3. You can make the following updates from this dialog:
    1. Protection mode: Select Maximum performance or Maximum availability from the drop-down list.
    2. Automatic failover: If automatic failover is not enabled already, you can enable it by selecting Enable automatic failover. Similarly, you can deselect Enable automatic failover to disable automatic failover for this Autonomous Data Guard setup. If one of your standby databases is in the same region as the primary database and the second is in a different region, the local standby database will be prioritized over the remote standby as the automatic failover target. When you enable automatic failover, any of the standby databases will be considered for the automatic failover target.
      Note

      You can not enable Automatic Failover for databases with cross-region Autonomous Data Guard setup on Exadata Cloud@Customer deployments.
    3. Fast start failover lag limit: If automatic failover is enabled and the protection mode is Maximum Performance, the Fast start failover lag limit value is displayed in seconds. By default, this value is set to 30 seconds, but you can change it to any value between 5 and 3600 seconds.
  4. Save your changes.
On the Oracle Cloud Infrastructure console, the Autonomous Container Database state shows UPDATING until the updated Autonomous Data Guard settings are applied.

Convert Physical Standby to Snapshot Standby

You can convert a standby Autonomous Container Database to a snapshot standby in an Autonomous Data Guard setup from the Details page of the standby Autonomous Container Database in the configuration.

Required IAM Policies

use autonomous-container-databases

Procedure

  1. Go to the Details page of the standby Autonomous Container Database in the Autonomous Data Guard configuration.
  2. Click Convert to snapshot standby from More actions.
    Note

    Converting to snapshot standby is not supported when automatic failover is enabled. You must disable automatic failover before converting to a snapshot standby. See Update Autonomous Data Guard Settings for instructions to disable automatic failover in an Autonomous Data Guard setup.
  3. The Convert to snapshot standby dialog displays with options to use new Database services or primary Database services for the snapshot standby database connections.
    • Use new Database services: Click this option to connect to snapshot standby using new services that are active only in the snapshot standby mode.
    • Use primary Database services: Click this option if you wish to connect to snapshot standby database using the same services as the primary database.
      Note

      Activating primary database services on the snapshot standby database may result in snapshot standby connection requests forwarded to the primary database or vice-versa if you use incorrect database connect strings. Hence, you must be careful to use appropriate connect string while connecting to your primary and snapshot standby database when you choose to use primary Database services.
  4. Click Convert.
    On the Oracle Cloud Infrastructure console the Autonomous Container Database state shows UPDATING until the standby changes to snapshot standby.

Convert Snapshot Standby to Physical Standby

You can convert a snapshot standby Autonomous Container Database to a physical standby in an Autonomous Data Guard setup from the Details page of the standby Autonomous Container Database in the configuration.

Required IAM Policies

use autonomous-container-databases

Procedure

  1. Go to the Details page of the standby Autonomous Container Database in the Autonomous Data Guard configuration.
  2. Click Convert to physical standby from More actions.
  3. The Convert to physical standby dialog displays a message alerting you that converting the snapshot standby to physical standby will discard all its local updates and apply data from your primary database.
  4. Click Convert.
    On the Oracle Cloud Infrastructure console the Autonomous Container Database state shows UPDATING until the standby changes to physical standby.

Add a Cross Tenancy Standby Database

APPLIES TO: Applicable Oracle Public Cloud only

You can add an Autonomous Data Guard standby database that resides in a tenancy different from the primary database.

Required IAM Policies

To create a cross tenancy standby database, you must ensure to meet the following requirements:

  • Run the CLI or API commands to add the cross tenancy standby database in the destination tenancy.

  • Define OCI Identity and Access Management groups and policies on the source and destination tenancies so that you can run commands to add the cross tenancy standby database in the destination tenancy and allow the destination tenancy to contact the source tenancy where the primary database resides. When these polices are revoked, adding a cross tenancy standby database will not be allowed.

    • On the destination tenancy, create a group (for example: DestinationGroup), and add the user(s) who will be allowed to add a cross tenancy standby database to this group. See Using the Console to Create a Group for guidance.

    • On the source tenancy, create IAM policies to allow the group created in the destination tenancy (DestinationGroup) to add a cross tenancy standby database using the primary database from the source tenancy. See Using the Console to Create a Policy for guidance.

      For example, you can define a policy to allow a user in the DestinationGroup of the DestinationTenancy read from a specific Autonomous Database instance in the specified compartment on the source tenancy as shown below:
      define tenancy DestinationTenancy as ocid1.tenancy.oc1..unique_ID
define group DestinationGroup as ocid1.group.region1..unique_ID
admit group DestinationGroup of tenancy DestinationTenancy to manage autonomous-database-family in
    tenancy
      Note

      The policy only needs to allow read access on the source Autonomous Database instance to create a cross tenancy clone.
      The above policy specifies the following:
      • Line 1: OCID of the destination tenancy where you are going to add the standby database.
      • Line 2: OCID of the destination group to which the user who will create cross tenancy standby database belongs.
      • Line 3: OCID of the compartment where the primary database resides and the OCID of the primary database.

    • On the destination tenancy, create IAM policies to endorse a group to manage the primary database source on the source tenancy. See Using the Console to Create a Policy for guidance.

      For example:
      define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
      The above policy specifies the following:
      • Line 1: OCID of the source tenancy OCID where the primary database resides.
      • Line 2: Specifies the destination group that can be allowed to manage Autonomous Databases in the source tenancy.

      This policy discussed in the above example allows DestinationGroup to create Autonomous Databases and cross tenancy standby databases in the source tenancy. See IAM Permissions and API Operations for Autonomous Database for more information and examples.

To add a local (same region) cross tenancy standby database:

On the tenancy where you want to add the standby database, that is, on the destination tenancy, use the CLI or call the REST API and provide the OCID of the primary database, where the primary database resides in a different tenancy (the source tenancy).

oci db autonomous-container-database create --cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.iad.unique_ID --compartment-id ocid1.compartment.oc1..unique_ID --display-name clicrosdg --patch-model RELEASE_UPDATES --peer-autonomous-container-database-compartment-id ocid1.compartment.oc1..unique_ID --peer-autonomous-container-database-display-name clisecdg --peer-cloud-autonomous-vm-cluster-id ocid1.autonomousexainfrastructure.oc1.iad.unique_ID --protection-mode MAXIMUM_PERFORMANCE --service-level-agreement-type AUTONOMOUS_DATAGUARD

Once the command succeeds a work-request-id will be returned which can be used to track the progress of the standby database. See autonomous-container-database for more information.

For information about SDKs, see Software Development Kits and Command Line Interface.

To add a cross tenancy standby database residing in the same region as the primary database using REST API, use AutonomousContainerDatabases.

The API call to create the standby is sent to the different tenancy in the local region.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1..unique_ID",
  "compartmentId": "ocid1.compartment.oc1..unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1..unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapscdg",
  "peerCloudAutonomousVmClusterId": "ocid1.autonomousexainfrastructure.oc1.iad.unique_ID",
  "protectionMode": "MAXIMUM_PERFORMANCE",
  "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}'

See AutonomousContainerDatabase for additional information on the REST API.

For information about using the API and signing requests, see REST APIs and Security Credentials.

To create a remote (cross-region) cross tenancy standby database:

On the tenancy where you want to add the standby database, that is, on the destination tenancy in the destination region, use the CLI or call the REST API and provide the OCID of the primary database, where the primary database resides in a different tenancy and different region.

oci db autonomous-container-database create --cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.ap-chuncheon-1.unique_ID --compartment-id ocid1.compartment.oc1..unique_ID --display-name clicrosdg --patch-model RELEASE_UPDATES --peer-autonomous-container-database-compartment-id ocid1.compartment.oc1..unique_ID --peer-autonomous-container-database-display-name clisecdg --peer-cloud-autonomous-vm-cluster-id ocid1.autonomousexainfrastructure.oc1.iad.unique_ID --protection-mode MAXIMUM_PERFORMANCE --service-level-agreement-type AUTONOMOUS_DATAGUARD

Once the command succeeds a work-request-id will be returned which can be used to track the progress of the standby database. See autonomous-container-database for more information.

For information about SDKs, see Software Development Kits and Command Line Interface.

To add a cross tenancy standby database residing in a different region from the primary database using REST API, use AutonomousContainerDatabases.

The API call to create the standby runs in the different tenancy in the source region. 

oci raw-request --http-method POST --target-uri https://database.ap-chuncheon-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.ap-chuncheon-1.unique_ID",
  "compartmentId": "ocid1.compartment.oc1..unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1..unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapscdg",
  "peerCloudAutonomousVmClusterId": "ocid1.autonomousexainfrastructure.oc1.iad.unique_ID",
  "protectionMode": "MAXIMUM_PERFORMANCE",
  "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
   
}'

See AutonomousContainerDatabase for additional information on the REST API.

For information about using the API and signing requests, see REST APIs and Security Credentials.

Note

After submitting a request to add a cross tenancy standby database. the database Lifecycle State shows Updating. You cannot stop, start, restart, restore or move the Autonomous Database in this state.