Using Autonomous Data Guard with Autonomous Database on Exadata Cloud@Customer

Learn how to enable a Data Guard association between databases, change the role of a database in a Data Guard association using either a switchover or a failover operation, and reinstate a failed database.

Enabling Autonomous Data Guard on an Autonomous Container Database

When you enable Data Guard, a separate Data Guard association is created for the primary and the standby database.

Note

Replication of data happens only over the client network.

Create an Autonomous Data Guard Enabled Autonomous Container Database

Follow these steps to create an Autonomous Data Guard Enabled Autonomous Container Database on an Oracle Exadata Cloud@Customer system.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. Click Create Autonomous Container Database.
    The Create Autonomous Container Database page is displayed.
  4. Provide the following basic information:
    • Compartment: Choose the compartment in which your autonomous container database will be created.
    • Display Name: Enter a user-friendly description or other information that helps you easily identify the autonomous container database. The display name does not have to be unique. Avoid entering confidential information.
  5. Select the Autonomous Exadata VM Cluster you wish to use to create your autonomous container database.
  6. Under Configure Autonomous Data Guard, select the Enable Autonomous Data Guard checkbox and provide the following details.
    • Peer Autonomous Container Database Compartment: Choose the compartment in which your standby autonomous container database will be created.
    • Display Name: Enter a user-friendly description or other information that helps you easily identify the autonomous container database. The display name does not have to be unique. Avoid entering confidential information.
    • Select peer Autonomous Exadata VM Cluster: Specify the following values for the standby:
      • Peer Region: Currently, the peer region is auto-populated and you cannot change it. The primary and secondary databases must run on two Autonomous Exadata VM Cluster on two separate Exadata infrastructures even if they are in the same region.
      • Peer Exadata: Select the Exadata Cloud@Customer infrastructure where the standby database will be created. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
      • Peer Autonomous Exadata VM Cluster: Select the Autonomous VM Cluster in which the standby ACD must be created. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
    • Data Protection Mode: Specify the protection mode used for this Data Guard association.
      • Maximum Performance: Provides the highest level of data protection that is possible without compromising the availability of a primary database.
      • Maximum Availability: Provides the highest level of data protection that is possible without affecting the performance of a primary database. This is the default protection mode.

        See Oracle Data Guard Concepts and Administration for more information about protection modes.

  7. Optionally, you can configure an automatic maintenance schedule.
    1. Click Modify Schedule.
    2. Optionally, you can change the maintenance patch type. Select either Release Update (RU) or Release Update Revision (RUR).
      Note

      You can set maintenance type only for primary.

      Release Update (RU): Autonomous Database installs only the most current release update.

      Release Update Revision (RUR): Autonomous Database installs the release update plus additional fixes.

      For more information, see "management operations.

    3. To configure the maintenance schedule, select Specify a schedule.

      Choose your preferred month, week, weekday, and start time for autonomous container database maintenance.

      • Under Week of the month, specify which week of the month maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of 7 days. Weeks start and end based on calendar dates, not days of the week. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days.
      • Under Day of the week, specify the day of the week on which the maintenance will occur.
      • Under Start hour, specify the hour during which the maintenance run will begin.
    4. Click Save Changes.
  8. Select a Backup Destination Type:
    • Object Storage: Stores backups in an Oracle-managed object storage container on Oracle Cloud Infrastructure. Optionally, you can use this field to specify your corporate HTTP proxy. We recommend using an HTTP proxy when possible for enhanced security.
    • Network File System (NFS): Stores backups in one of your previously defined backup destinations that uses Network File System (NFS) storage.
      • Select a Backup Destination.
    • Recovery Appliance: Not Supported.
  9. The following Advanced Options are available:
    • Backup retention period: Customize the retention period for automatic backups.
    • Encryption Key: Choose an encryption option, Encrypt using Oracle-managed keys or Encrypt using customer-managed keys. The default option is Oracle-managed keys.

      To use customer-managed keys, select the Encrypt using customer-managed keys option, select the compartment where you have created the Key Store, and then select the Key Store. As part of the CDB creation, a new wallet is created for the CDB in Oracle Key Vault (OKV). Also, a TDE Master Key is generated for the CDB and added to the wallet in OKV.

      Note

      • Autonomous Container Databases and Autonomous Databases only support 256-bit Hardware Security Module (HSM) Vault keys.
      • Validate OKV Key encryption post restart: OKV TDE Master Key is validated every time you start or restart your ACD. Start or restart fails if the key is not validated. Work requests and life cycle states indicate the reason for failure.
      • View OKV keys post database restore: When you restore a CDB, the master key associated with that backup is restored as well.
      • Enable CDB backups to capture wallet name: CDB backups information about the wallet associated with the backup.
      • OKV Wallet or TDE Master Key on CDB deletion: If you delete a CDB, then the wallet and TDE Master Key remains in OKV and will not be deleted.
    • Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator. Avoid entering confidential information.
  10. Click Create Autonomous Container Database.

View Details of a Data Guard Enabled Primary or Standby Autonomous Container Database

Follow these steps to view detailed information about a primary or standby Autonomous Container Database on an Oracle Exadata Cloud@Customer system.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the database you wish to view details.
  4. In the Autonomous Container Database Details page, check the Autonomous Data Guard association status and peer database state.
  5. Under Resources, click Autonomous Data Guard to view association details.

Rotate CDB Encryption Key

Follow these steps to rotate the TDE Master key. On key rotation, the ACD life cycle goes through the regular updating state and returns to available.

You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.

Note

You can rotate both Oracle-managed and customer-managed encryption keys.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the primary or standby database you wish to view details.
  4. On the Autonomous Container Database Details page, click Rotate Encryption Key.
  5. On the Rotate Encryption Key dialog, click Rotate Encryption Key.

Perform a Failover to Standby Autonomous Container Database

Initiate a failover operation by using the Data Guard association of the standby database.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
  4. Click the name of the standby database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to perform a failover, click the Actions icon (three dots), and then click Failover.
  7. In the Confirm Manual Failover to Standby dialog box, enter the name of the Autonomous Container Database you want to failover, and then click Failover.
    Note

    After successful completion of failover, the standby ACDs role will change to primary and the primay's role will become disabled-standby.

Perform a Switchover to Standby or Primary Autonomous Container Database

Initiate a switchover operation by using the Data Guard association of the primary database.

  • You can perform Switchover only when both primary and standby are in available state.
  • You cannot perform switchover if patching or maintenance is in progress on primary or standby.
  • After switchover, the maintenance preference for new standby and primary will remain same as old standby and primary.
  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
  4. Click the name of the primary or secondary database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to perform a switchover, click the Actions icon (three dots), and then click Switchover.
  7. In the Confirm Switchover to Standby dialog box, click Swichover.

    This database should now assume the role of the standby, and the standby should assume the role of the primary in the Data Guard association.

Reinstate Data Guard Enabled Standby Autonomous Container Database

After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby.

After the operations team correct the cause of failure, you can reinstate the failed database as a functioning standby for the current primary by using its Data Guard association. you can reinstate the failed database as a functioning standby for the current primary by using its Data Guard association.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
  4. Click the name of the failed database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to reinstate this database, click the Actions icon (three dots), and then click Reinstate.
  7. In the Reinstate Database dialog box, click Reinstate.

    This database should now be reinstated as the standby in the Data Guard association.

Terminate a Data Guard Enabled Primary Autonomous Container Database

Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system.

You must terminate all Autonomous Databases within a container database before you can terminate the container database itself. Terminating Autonomous Container Database will disable Autonomous Data Guard, which affects high availability and disaster recovery of your Autonomous Databases.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
  4. In the Autonomous Container Database Details page, select Terminate from the More Actions drop-down list.
  5. Click Terminate.
  6. In the confirmation dialog, type the name of the Autonomous Container Database, and then click Terminate Autonomous Container Database.

Terminate a Data Guard Enabled Standby Autonomous Container Database

Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system.

You can terminate a standby Autonomous Container Database even if there are standby Autonomous Databases inside it. However, you cannot terminate standby Autonomous Databases inside a standby Autonomoous Container Database. To terminate a standby Autonomoous Database, you must first terminate the primary Autonomous Database. Terminating Autonomous Container Database will disable Autonomous Data Guard, which affects high availability and disaster recovery of your Autonomous Databases.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.
  3. In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
  4. In the Autonomous Container Database Details page, select Terminate from the More Actions drop-down list.
  5. Click Terminate.
  6. In the confirmation dialog, type the name of the Autonomous Container Database, and then click Terminate Autonomous Container Database.

Operations Performed Using the APIs

Learn how to use the API to manage Autonomous Data Guard Enabled Autonomous Container Database.

For information about using the API and signing requests, see "REST APIs" and "Security Credentials". For information about SDKs, see "Software Development Kits and Command Line Interface".

The following table lists the REST API endpoints to manage Autonomous Data Guard Enabled Autonomous Container Database.

Operation REST API Endpoint

Creates Autonomous Container Databases (update to the existing API)

CreateAutonomousContainerDatabase

View details of the specified Autonomous Container Database

GetAutonomousContainerDatabase

View a list of Autonomous Container Databases with Autonomous Data Guard associations

ListAutonomousContainerDatabaseDataguardAssociations

Fetch details of an Autonomous Container Database Autonomous Data Guard associations

GetAutonomousContainerDatabaseDataguardAssociation

Fail over the standby Autonomous Container Database identified by the autonomousContainerDatabaseId parameter to the primary Autonomous Container Database after the existing primary Autonomous Container Database fails or becomes unreachable.

FailoverAutonomousContainerDatabaseDataguardAssociation

Switch over the primary Autonomous Container Database of an Autonomous Data Guard peer association to standby role. The standby Autonomous Container Database associated with autonomousContainerDatabaseDataguardAssociationId assumes the primary Autonomous Container Database role.

SwitchoverAutonomousContainerDatabaseDataguardAssociation

Reinstate a disabled standby Autonomous Container Database identified by the autonomousContainerDatabaseId parameter to an active standby Autonomous Container Database.

ReinstateAutonomousContainerDatabaseDataguardAssociation

View a list of the Autonomous Data Guard-enabled databases associated with the specified Autonomous Database.

ListAutonomousDatabaseDataguardAssociations

Fetch details of an Autonomous Database Autonomous Data Guard associations

GetAutonomousDatabaseDataguardAssociation

Fetches details such as peer database role, lag time, transport lag, and state

GetAutonomousDatabase

Enabling Autonomous Data Guard on an Autonomous Database

Autonomous Databases inherit Data Guard settings from the parent container database.

View Autonomous Data Guard Enablement

Autonomous Data Guard settings are configured on the Autonomous Container Databases in which the databases are running.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Container Databases.

    This page displays if an autonomous database is Data Guard enabled or not, and if enabled, then the role of the database in the Data Guard association.

Create an Autonomous Data Guard Enabled Autonomous Database

Follow these steps to create an autonomous database on an Oracle Exadata Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. Click Create Autonomous Database.
  4. In the Create Autonomous Database dialog, enter the following:

    Basic Database Information

    • Compartment: Select the compartment of the Autonomous Database.
    • Display Name: A user-friendly description or other information that helps you easily identify the resource. The display name does not have to be unique. Avoid entering confidential information.
    • Database Name: The database name must consist of letters and numbers only, starting with a letter. The maximum length is 14 characters. Avoid entering confidential information.

    Workload Type

    Select the desired workload type. See Autonomous Data Warehouse and Autonomous Transaction Processing for information about each workload type.

    Autonomous Container Database: Select the Autonomous Data Guard-enabled Autonomous Container Databases checkbox, and then select an Autonomous Container Database.

    Compartment: Specify the compartment containing the Autonomous Container Database you wish to use.

    Database CPU Core Count and Storage Configuration

    • OCPU Count: The total number of cores available to all databases within the Autonomous Exadata Infrastructure depends on the infrastructure shape and what is already allocated to other Autonomous Databases.

      Deselect Auto Scaling to disable auto-scaling. By default, auto-scaling is enabled to allow the system to automatically use up to three times more CPU and IO resources to meet workload demand.

    • Storage (TB): Specify the storage you wish to make available to your Autonomous Database, in terabytes. The available storage depends on the infrastructure shape and what is already consumed by other Autonomous Databases.

    Administrator Credentials

    Set the password for the Autonomous Database Admin user by entering a password that meets the following criteria. You use this password when accessing the Autonomous Database service console and when using an SQL client tool.

    • Contains from 12 to 30 characters
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing

    Configure network access

    You can optionally create an ACL during database provisioning, or at any time thereafter.

    1. Cick Modify Access Control.
    2. In the Edit Access Control List dialog, select the Enable database level access control checkbox.
    3. Under the Primary database access control list, specify the following types of addresses in your list by using the IP notation type drop-down selector:

      IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.

      CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.

    4. Under Standby database access control, do the following:

      (Default) Same as primary database: Leave as is if you want the same access control list for the secondary database.

      Define standby database access control: Initialized with the same details as primary. Add or modify entries, as applicable.

    Advanced Options

    Tags: Optionally, you can apply tags. If you have permission to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator. Avoid entering confidential information.

    Encryption Key: ADB inherits encryption settings from the parent ACD. If the parent ACD is configured for customer-managed OKV based encryption, then the child ADB will also have TDE Master Key generated and managed in the same OKV wallet used to store ACD master keys. Additionally, any backups taken on the Autonomous Database will have the OKV based key associated with it.

  5. Click Create Autonomous Database.
    Note

    The following naming restrictions apply to Autonomous Transaction Processing and Autonomous Data Warehouse databases:

    • Names associated with databases terminated within the last 60 days cannot be used when creating a new database.
    • A database name cannot be used concurrently for both an Autonomous Data Warehouse and an Autonomous Transaction Processing database.

View Details of a Data Guard Enabled Primary or Standby Autonomous Database

Follow these steps to view detailed information about a primary or standby Autonomous Database on an Oracle Exadata Cloud@Customer system.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. In the Autonomous Database Details page, check the Autonomous Data Guard association status and peer database state.
  5. Under Resources, click Autonomous Data Guard to view association details.

Rotate ADB Encryption Key

Follow these steps to rotate the TDE Master key. On key rotation, the ADB life cycle goes through the regular updating state and returns to available.

You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.

Note

You can rotate both Oracle-managed and customer-managed encryption keys.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. On the Autonomous Database Details page, from the More Actions drop-down list, select Rotate Encryption Key.
  5. On the Rotate Encryption Key dialog, click Rotate Encryption Key.

Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

Follow these steps to change the maintenance schedule of a Data Guard enabled Autonomous Container Database.

Configure Automatic Maintenance Schedule for a Data Guard Enabled Autonomous Container Database

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Container Databases, click the display name of the container database you are interested in.
  4. On the Autonomous Container Database details page, under Maintenance, click the edit link in the Maintenance Details field. In the Edit Automatic Maintenance dialog that opens, you can configure both the maintenance schedule and the patch type.
    Note

    The standby database will have No preference by default. Standby Maintenance depends on the primary maintenance schedule.

  5. Optionally, you can change the maintenance patch type. To edit this setting, select either Release Update (RU) or Release Update Revision (RUR).

    Release Update (RU): Autonomous Database installs only the most current release update.

    Release Update Revision (RUR): Autonomous Database installs the release update plus additional fixes.

    Note

    Standby will be always patched before primary and the default gap between standby and primary is 7 days. You have have an option to change the default gap to anytime between 1 - 7 days.

  6. To configure the maintenance schedule, select Specify a schedule in the Configure the automatic maintenance schedule section. Choose your preferred month, week, weekday, and start time for container database maintenance.
    • Under Maintenance months, specify at least one month for each maintenance quarter during which you want Autonomous Exadata Infrastructure maintenance to occur.

      Note

      Maintenance quarters begin in February, May, August, and November, with the first maintenance quarter of the year beginning in February.

    • Under Week of the month, specify which week of the month maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of 7 days. Weeks start and end based on calendar dates, not days of the week. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days.
    • Under Day of the week, specify the day of the week on which the maintenance will occur.
    • Under Start hour, specify the hour during which the maintenance run will begin.
    • Choose the buffer period between primary and standby maintenance execution. Buffer period is the number of days before which the standby Autonomous Container Database Maintenance will be scheduled before primary Autonomous Container Database Maintenance
  7. Click Save Changes.

View the Next Scheduled Maintenance Run of a Data Guard Enabled Autonomous Container Database

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Container Databases, click the display name of the container database you are interested in.
  4. On the Autonomous Container Database details page, under Maintenance, click the View link in the Next Maintenance field.
  5. On the Maintenance page, under Autonomous Database Maintenance, click Maintenance.

    In the list of maintenance events, you can the details of scheduled maintenance runs. Maintenance event details include the following:

    • The status of the scheduled maintenance run
    • The type of maintenance run (quarterly software maintenance or a critical patch)
    • The OCID of the maintenance event
    • The start time and date of the maintenance

View the Maintenance History of a Data Guard Enabled Autonomous Container Database

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Container Databases, click the display name of the container database you are interested in.
  4. On the Autonomous Container Database details page, under Maintenance, click the View link in the Next Maintenance field.
  5. On the Maintenance page, under Autonomous Database Maintenance, click Maintenance History.

    In the list of past maintenance events, you can click on an individual event title to read the details of the maintenance that took place. Maintenance event details include the following:

    • The category of maintenance (quarterly software maintenance or a critical patch)
    • Whether the maintenance was scheduled or unplanned
    • The OCID of the maintenance event
    • The start time and date of the maintenance

Immediately Patch a Data Guard Enabled Autonomous Container Database

Note

Patching primary immediately will result in standby being patched first, if standby is not already patched.
  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Container Databases, click the display name of the Autonomous Container Database that you want to patch.
  4. On the Autonomous Container Database Details page, in the Maintenance section, click the View link in the Next Maintenance field to display the Maintenance page for the Autonomous Container Database that you want to patch.
  5. In the Autonomous Container Database section, click Patch Now in the Scheduled Start Time field to display the Run Maintenance dialog.
  6. Click Patch Now to start the patching operation.

Reschedule or Skip scheduled Maintenance for Data Guard Enabled Autonomous Container Database

Note

Skipping primary will skip standby also. If standby is patched, then skipping on primary is not allowed.
  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Container Databases, click the display name of the container database that you want to manage.
  4. On the Autonomous Container Database details page, in the Maintenance section, click the View link in the Next Maintenance field.
  5. On the Maintenance page, any container database maintenance events planned for the next 15 days will appear in the list of maintenance events.

    To skip scheduled maintenance for a container database, click Skip.

    Note

    You cannot skip scheduled maintenance more than twice, consecutively.

    To reschedule maintenance, click Edit and enter a start time for the update in the Edit Maintenance dialog. Ensure that your specified container database maintenance window is later in the quarter than your scheduled Exadata infrastructure maintenance.