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.

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 two weeks.

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.

  • The primary ACD and its associated Autonomous Databases will have a downtime due to automatic non-rolling restart.

  1. Go to the Details page of the Autonomous Container Database for which you want to enable Autonomous Data Guard.
  2. Open the Enable Autonomous Data Guard dialog using any of the two options below:

    • Option 1: Under the Autonomous Data Guard section on the Autonomous Container Database information tab, click Enable next to Status.

    • Option 2: Under the Resources section of the Details page, select Autonomous Data Guard Associations, and click Enable Autonomous Data Guard.

  3. Fill out the Enable Autonomous Data Guard 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. If you choose to enable a cross-region Autonomous Data Guard association, note the following about encryption keys:
    • If you are managing keys using the OCI Vault service, you must use a key from a virtual private vault located in the region of the primary database. This vault must be replicated in the region of the standby database. See Replicating Vaults and Keys for information on creating and managing these resources.
    • The replicated vault used by the standby is read-only. So, when the standby assumes the primary role from a switchover or failover, you cannot create a new Pluggable Database or rotate the key.
    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.

    Automatic Failover Select Enable automatic failover to enable it. You can also deselect Enable automatic failover if you wish to disable automatic failover for this Autonomous Data Guard setup.  
    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.

    Minimum fast start lag limit value supported by ACDs with 19.17 and older versions is 30 seconds.

    For more details about automatic failover, see Automatic Failover or Fast-Start Failover.

    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.
  4. Click Enable Autonomous Data Guard.
    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 the Autonomous Data Guard section on the Autonomous Container Database Information tab.

  2. You can also view the Autonomous Data Guard details in the side menu, under Resources by clicking Autonomous Data Guard Associations.

    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.

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

  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. In the side menu, under Resources, click Autonomous Data Guard Associations.

  3. In the Created column of the table showing Autonomous Data Guard associations, click the ellipsis icon and then click Switchover.

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

    In case of cross region Data Guard with Customer Managed Keys, the replicated vault used by the standby is read-only. So, when the standby assumes the primary role from a failover, you cannot create a new Pluggable Database or rotate the key.

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

  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. In the side menu, under Resources, click Autonomous Data Guard Associations.

  3. In the Created column of the table showing Autonomous Data Guard associations, click the ellipsis icon and then click Failover.

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

    Note

    In case of cross region Data Guard with Customer Managed Keys, the replicated vault used by the standby is read-only. So, when the standby assumes the primary role from a failover, you cannot create a new Pluggable Database or rotate the key.

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

  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. In the Resources section, click Autonomous Data Guard Associations to display a list of peer databases for the primary database you are managing.

  3. For the Autonomous Container Database you are reinstating, click the ellipsis in the Created column, 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.

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. Under More Actions, click Update Autonomous Data Guard.
    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.
      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. Click Save 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. Under More actions, click Convert to snapshot standby.
    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. Under More actions, click Convert to physical standby.
  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.