Manage Autonomous Data Guard Configuration

The Autonomous Data Guard feature of Autonomous AI 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.

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.

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

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.

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.	You can add a standby ACD from AWS region to the already provisioned ACD in the OCI region. Alternatively, you can add a standby ACD in the OCI region to an already provisioned ACD in the AWS region.
   Peer region	Select a region for the standby ACD.	The primary and secondary ACDs can also be deployed in different regions (cross-region).
   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.	In Exadata Cloud@Customer deployments, if the parent AVMC has the 3rd NIC enabled, all Data Guard operations will travel only over this 3rd NIC.
   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. On Oracle Public Cloud deployments of the Autonomous AI Database, you can choose either Autonomous Recovery Service or Object Storage as the backup destination. The default is Object Storage and the recommended option is Autonomous Recovery Service. For Autonomous AI Database on Oracle Database@AWS, you can choose either Autonomous Recovery Service, OCI Object Storage or Amazon Simple Storage ( AWS S3). The default is AWS S3 and the recommended option is Autonomous Recovery Service.
   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.

   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 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 is not affected by 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.

3. Fill out Add standby with the following information:

   Setting	Description
   Peer Autonomous Container Database compartment	Select the standby Autonomous Container Database compartment.
   Peer Autonomous Container Database name	Enter a name for the standby ACD. Note: You can add a standby ACD from AWS region to the already provisioned ACD in the OCI region. Alternatively, you can add a standby ACD in the OCI region to an already provisioned ACD in the AWS region.
   Peer region	Select a region for the standby ACD.
   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	Select the backup destination type for the second standby database from the drop-down list. On Oracle Public Cloud deployments of the Autonomous AI Database, you can choose either Autonomous Recovery Service or Object Storage as the backup destination. The default is Object Storage and the recommended option is Autonomous Recovery Service. For Autonomous AI Database on Oracle Database@AWS, you can choose either Autonomous Recovery Service, OCI Object Storage or Amazon Simple Storage ( AWS S3). The default is AWS S3 and the recommended option is Autonomous Recovery Service.

   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.

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 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. Under Actions, click Switchover.

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

   Oracle Autonomous AI Database on Dedicated Exadata Infrastructure sets the state 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 state 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

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. Under Actions, 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 AI Database on Dedicated Exadata Infrastructure sets the state 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.

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.

In an Autonomous Data Guard setup with multiple standby databases and automatic failover:

• Manual failovers require you to manually reinstate the original primary database, which becomes the new standby database.

• Whenever an automatic failover occurs, Autonomous AI Database on Dedicated Exadata Infrastructure tries to reinstate the old primary as a standby. However, if that attempt fails, then it must be manually reinstated.

Required IAM Policies

use autonomous-container-databases

Procedure

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. Under Actions, 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.

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.

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

2. Click Update Autonomous Data Guard under 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.

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

2. Click Convert to snapshot standby under 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.

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

2. Click Convert to physical standby under 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 UPDATINGuntil the standby changes to physical standby.

Add a Cross Tenancy Standby Database

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

APPLIES TO: Oracle Public Cloud only

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 thesource 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 AI 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 **read autonomous-database-family** in
        tenancy
    

    Note: The policy only needs to allow read access on the source Autonomous AI Database instance to create a cross tenancy standby.

    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: Specifies the destination group that can be allowed to read Autonomous AI Databases in the source tenancy.

  • 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 AI Databases in the source tenancy.

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

Add a Cross Tenancy Standby Database in Same Region

CLI REST API

You can create a standalone ACD in the source tenancy using CLI as shown below.

oci --debug db autonomous-container-database create
--cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID
--compartment-id ocid1.compartment.oc1.unique_ID --display-name clicrosdg
--patch-model RELEASE_UPDATES --service-level-agreement-type STANDARD

where:

• --cloud-autonomous-vm-cluster-id: The OCID of of the target Autonomous Exadata VM Cluster where the new Autonomous Container Database (ACD) will be provisioned.

Alternatively, you can also use an existing standalone ACD and directly add the standby database as shown below.

On the tenancy where you want to add the standby database, that is, on the destination tenancy, use CLI to add a standby database as shown below:

oci --debug db autonomous-container-database add
--autonomous-container-database-id ocid1.autonomouscontainerdatabase.oc1.<region-name>.unique_ID
--peer-autonomous-container-database-display-name clisecdg
--peer-cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID
--protection-mode MAXIMUM_PERFORMANCE
--peer-autonomous-container-database-compartment-id "ocid1.compartment.oc1.unique_ID"

where:

• --autonomous-container-database-id : The OCID of the primary Autonomous Container Database to which you are adding a standby.

• --peer-autonomous-container-database-display-name: A user-friendly name for the new standby Autonomous Container Database in the destination tenancy.

• --peer-autonomous-vm-cluster-id : The OCID of the Cloud Autonomous VM Cluster in the destination tenancy where the standby database will be created.

• --peer-autonomous-container-database-compartment-id: The OCID of the compartment where the standby Autonomous Container Database will reside.

• --protection-mode: Defines the protection mode that will be used once the ACD is Data Guard enabled.

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. Note: If you want the command to be run in a region which is not listed in the config file, then you need to set the required region in the command prompt before running the oci command.

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 same region.

You can create a standalone ACD in the source tenancy using REST API as shown below.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases
--request-body '{
"cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID",
"compartmentId": "ocid1.compartment.oc1.unique_ID",
"displayName": "cliapcrdg",
"patchModel": "RELEASE_UPDATES",
"serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}''

where:

• cloudAutonomousVmClusterId: The OCID of of the target Autonomous Exadata VM Cluster where the new Autonomous Container Database (ACD) will be provisioned.

Alternatively, you can also use an existing standalone ACD and directly add the standby database as shown below.

On the tenancy where you want to add the standby database, that is, on the destination tenancy, use REST API to add a standby database as shown below:

oci raw-request --http-method POST --target-uri
https://database.<region-name>.oraclecloud.com/../../ocid1.autonomouscontainerdatabase.oc1.<region-name>../actions/addStandby
--request-body '{
  "peerCloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1.unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapsec1",
   "protectionMode": "MAXIMUM_PERFORMANCE",
}'

where:

• peerCloudAutonomousVmClusterId: The OCID of the Cloud Autonomous VM Cluster in the destination tenancy where the standby database will be created.

• peerAutonomousContainerDatabaseCompartmentId: The OCID of the compartment where the standby Autonomous Container Database will reside.

• peerAutonomousContainerDatabaseDisplayName: A user-friendly name for the new standby Autonomous Container Database in the destination tenancy.

• protectionMode: Defines the protection mode that will be used once the ACD is Data Guard enabled.

See AutonomousContainerDatabase for additional information on the REST API.

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

Create a Cross-Tenancy Standby Database in a Remote Region

CLI REST API

You can create a standalone ACD in the source tenancy (if you have not created one already) using CLI as shown below.

oci --debug db autonomous-container-database create
--cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<sourceregion-name>.unique_ID
--compartment-id ocid1.compartment.oc1.unique_ID --display-name clicrosdg
--patch-model RELEASE_UPDATES --service-level-agreement-type STANDARD

where:

• --cloud-autonomous-vm-cluster-id: The OCID of of the target Autonomous Exadata VM Cluster where the new Autonomous Container Database (ACD) will be provisioned.

Alternatively, you can also use an existing standalone ACD and directly add the standby database as shown below.

On the tenancy where you want to add the standby database, that is, on the destination tenancy in the remote region, use CLI to add a standby database as shown below:

oci --debug db autonomous-container-database add
--autonomous-container-database-id "ocid1.autonomouscontainerdatabase.oc1.<sourceregion-name>.unique_ID"
--peer-autonomous-container-database-display-name "cliCrosstSec2"
--protection-mode "MAXIMUM_PERFORMANCE"
--peer-cloud-autonomous-vm-cluster-id "ocid1.cloudautonomousvmcluster.oc1.<remoteregion-name>.uniqueID"
--peer-autonomous-container-database-compartment-id "ocid1.compartment.oc1..uniqueID"

where:

• --autonomous-container-database-id: The OCID of the primary Autonomous Container Database in the source region to which you are adding a standby.

• --peer-autonomous-container-database-display-name: A user-friendly name for the new standby Autonomous Container Database in the destination region and in the destination tenancy.

• --peer-autonomous-vm-cluster-id: The OCID of the Cloud Autonomous VM Cluster in the destination region and in the destination tenancy where the standby database will be created.

• -peer-autonomous-container-database-compartment-id: The OCID of the compartment where the standby Autonomous Container Database will reside.

• --protection-mode: Defines the protection mode that will be used once the ACD is Data Guard enabled

Note: If the remote region is different from what is listed in the default config file, then you need to set the required remote region in the command prompt before running the oci command.

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 as the primary database using REST API, use AutonomousContainerDatabases.

You can create a standalone ACD in the source tenancy using REST API as shown below.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<sourceregion-name>.unique_ID",
  "compartmentId": "ocid1.compartment.oc1.unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
   "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}'

where:

• cloudAutonomousVmClusterId: The OCID of of the target Autonomous Exadata VM Cluster where the new Autonomous Container Database (ACD) will be provisioned.

Alternatively, you can also use an existing standalone ACD and directly add the standby database as shown below.

On the tenancy where you want to add the standby database, that is, on the destination tenancy in the destination region, use REST API to add a standby database as shown below:

oci raw-request --http-method POST --target-uri
https://database.ap-chuncheon-1.oraclecloud.com/20160918/autonomousContainerDatabases/ocid1.autonomouscontainerdatabase.oc1.<sourceregion-name>../actions/addStandby
--request-body '{
  "peerCloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<remoteregion-name>.uniqueID",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1.uniqueID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapsec2",
   "protectionMode": "MAXIMUM_PERFORMANCE",
}'

where:

• peerCloudAutonomousVmClusterId: The OCID of the Cloud Autonomous VM Cluster in the destination tenancy where the standby database will be created.

• peerAutonomousContainerDatabaseCompartmentId: The OCID of the compartment where the standby Autonomous Container Database will reside.

• peerAutonomousContainerDatabaseDisplayName: A user-friendly name for the new standby Autonomous Container Database in the destination tenancy.

• protectionMode: Defines the protection mode that will be used once the ACD is Data Guard enabled.

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 AI Database in this state.

Related Content

Protect Critical Databases from Failures and Disasters Using Autonomous Data Guard