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 Database Service on 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.
    Note

    If the selected Autonomous Exadata VM Cluster does not have 2 available OCPUs per node, which is the minimum requirement for creating an Autonomous Container Database, then this field is greyed out. Select an Autonomous Exadata VM Cluster that has enough resources to create an 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.
        Note

        If the selected Autonomous Exadata VM Cluster does not have 2 available OCPUs per node, which is the minimum requirement for creating an Autonomous Container Database, then this field is greyed out. Select an Autonomous Exadata VM Cluster that has enough resources to create an Autonomous Container Database.
    • 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 Oracle Data Guard 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 permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission 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 Database Service on Cloud@Customer system.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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.

Managing a Standby Autonomous Container Database

Enabling Autonomous Data Guard on an Autonomous Container Database creates a standby (peer) Autonomous Container Database that provides data protection, high availability, and facilitates disaster recovery for the primary database.

If the primary Autonomous Container Database becomes unavailable because of a region failure, a failure of the Autonomous Exadata Infrastructure, or the failure of the Autonomous Container Database, itself, then it automatically fails over to the standby Autonomous Container Database if Automatic Failover is enabled. The role of the failed primary database becomes Disabled Standby and, after a brief period of time, the standby database assumes the role of the primary database.

Besides hardware failures and regional outages, the following table lists database health conditions that also trigger automatic failover:

Table 6-7 Database Health Condition

Database Health Condition Description
Datafile Write Errors The system initiates a fast-start failover if write errors occur in any data files, including temp files, system data files, and undo files.
Corrupted Dictionary Dictionary corruption of a critical database. Currently, this state can be detected only when the database is open.
Corrupted Controlfile Controlfile is permanently damaged because of a disk failure.
Note

  • After automatic failover concludes, a message displays on the details page of the disabled standby database advising you that failover has occurred.
  • Automatic failover is optional while configuring Autonomous Data Guard. You can enable or disable automatic failover after configuring Autonomous Data Guard.
  • The FastStartFailoverLagLimit configuration attribute establishes an acceptable limit, in seconds, up to which the standby database can fall behind the primary database, with respect to the redo applied. If the limit is reached, then a fast-start failover does not occur. This attribute is used when fast-start failover is enabled and the configuration is operating in maximum performance mode.
    The FastStartFailOverLagLimit attribute:
    • Has a default value of 30 seconds
    • Cannot be configured
    • Is only applicable when in maximum performance protection mode

After the service resolves the issues with the former primary Autonomous Container Database, you can perform a manual switchover to return both databases to their initial roles.

Once you provision the standby database, you can perform various management tasks related to the standby database, including:
  • Manually switching over a primary database to a standby database
  • Manually failing over a primary database to a standby database
  • Reinstating a primary database to standby role after failover
  • Terminating a standby database

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 Database Service on 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 associated with the primary Autonomous Container Database that you want to failover.
  5. Click Failover.
  6. 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.

    Alternatively,

    1. Under Resources, click Autonomous Data Guard to display a list of peer databases for the primary database you are managing.
    2. For the Data Guard association on which you want to perform a failover, click the Actions icon (three dots), and then click Failover.
    3. 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 Database Service on 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. Click Switchover.
  6. In the confirmation dialog box, click Switchover.

    Alternatively,

    1. Under Resources, click Data Guard Associations.
    2. For the Data Guard association on which you want to perform a switchover, click the Actions icon (three dots), and then click Switchover.
    3. 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 Database Service on 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 Disabled Standby database.
  5. Under Resources, click Autonomous Data Guard..
  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. You can now perform a switchover operation to revert the respective databases to their original roles.

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 Database Service on 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 Database Service on 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 Database Service on 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 Database Service on Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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. 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.

      The selected OCPU count is validated against a list of provisionable OCPUs, and if the database can not be scaled up to the chosen OCPU count, you will be provided with the two nearest provisionable OCPU values.

      Based on the resource utilization on each node; not all the values of the available OCPUs can be used to provision or scale Autonomous Databases. For example, suppose you have 20 OCPUs available at the AVMC level, not all the values from 1 to 20 OCPUs can be used to provision or scale Autonomous Databases depending on the resource availability at the node level. The list of OCPU values that can be used to provision or scale an Autonomous Database is called Provisionable OCPUs.

      On the console, when you try to provision or scale an Autonomous Database, the OCPU count will be validated against the list of provisionable OCPUs, and if the value is not provisionable, you will be provided with the two nearest provisionable OCPU values. Alternatively, if you want to see the complete list of provisionable OCPU values for an Autonomous Exadata VM Cluster, you can use the following API:

      GetAutonomousContainerDatabase returns a list of provisionable OCPU values that can be used to create a new Autonomous Database in the given Autonomous Container Database. See GetAutonomousContainerDatabase for more details.

      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 permission to apply free-form tags to that resource. To apply a defined tag, you must have permission 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 Database Service on Cloud@Customer system.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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 Database Service on 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 Database Service on 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 Database Service on 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 Database Service on 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 Database Service on 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.