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 or 8 available ECPUs 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. Choose Container DB software version.
   • Select version from base images: Create a database with the Oracle Database version selected.
     • Select base image: The latest version is selected by default. Select a database version (N, N-1) if needed.
7. 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: Select a peer 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.

       The primary and standby Autonomous Container Databases must be on two different Autonomous VM Clusters on the same Exadata infrastructure or different Exadata infrastructures.

       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.

   • Enable automatic failover: Select this checkbox to enable automatic failover and set the FSFO lag limit.

     Fast-Start Failover (FSFO) lag limit: Set Fast-Start Failover (FSFO) lag limit in increments of 1. Minimum: 5 and Maximum: 3600 seconds. Default: 30 seconds.

     Note
     
     FSFO Lag Limit is applicable only to Maximum Performance protection mode.
8. Optionally, you can configure an automatic maintenance schedule.
   1. Click Edit Maintenance Preferences.
   2. Configure Container Database maintenance version
      • Next Release Update (RU): Update to the next release update in the next maintenance cycle.
      • Latest Release Update (RU): Update to the latest release update in the next maintenance cycle.

      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.
9. Enable automatic backups.

   By default, automatic backups are enabled for an ACD. Optionally, you can choose to disable them by deselecting the Enable automatic backups check box.

   While provisioning an ACD with Autonomous Data Guard, you can not disable the automatic backups.

   Note
   
   

   If disabled for an ACD, automatic backups can be enabled anytime later from the Oracle Cloud Infrastructure (OCI) console by following the steps outlined in Edit Autonomous Container Database Backup Settings. However, once enabled you can not disable automatic backups for the ACD.

   If enabling automatic backups fail for some reason, the ACD provisioning also fails with an error message. As a workaround, you can provision the ACD with automatic backups disabled, and enable them from the ACD's Details page later.

10. Select a Backup Destination Type:
    Note
    
    The backup destination type can only be set while enabling automatic backups on an ACD and cannot be changed later.

    The possible options are:

    • Object Storage: Stores backups in an Oracle-managed object storage container on Oracle Cloud Infrastructure.

      If you choose Object Storage as the type, you can optionally specify an internet HTTP proxy to use when connecting to the storage container. Oracle recommends using a proxy when possible for enhanced security.

    • Network File System (NFS): Stores backups in a Network File System (NFS) storage location.

      If you choose Network File System (NFS) as the type, select a previously defined Backup Destination that uses Network File System (NFS) storage.

    • Recovery Appliance: Stores backups in one of your previously defined backup destinations that use Oracle Zero Data Loss Recovery Appliance.

      If you choose Recovery Appliance as the type, select a previously defined Backup Destination that uses Oracle Zero Data Loss Recovery Appliance, the DB_UNIQUE_NAME of the Autonomous Container Database, and the VPC user name password.

      Provide the connection string that connects to the recovery appliance in an Oracle "easy connect" string format, that is, <host>:<port>/<service name>, where <host> is the SCAN hostname of the Zero Data Loss Recovery Appliance.

11. The following Advanced Options are available:
    • Backup retention period: Specify a Backup retention period value to meet your needs. You can choose any value between 7 to 95 days.

      For the Object Storage and Network File System (NFS) backup destination types, the backup retention policy value defaults to 30 days.

      For the Recovery Appliance backup destination type, this value is controlled by the Recovery Appliance protection policy.

      All the backups are automatically deleted after the backup retention period.

    • 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.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • Database In-memory:
      • Enable database In-memory: It requires at least four OCPUs and a percentage of the System Global Area (SGA) to enable in-memory. If you enable In-memory, select the percentage of SGA to allocate to the IM Column Store. In-memory may have an impact on the autonomous database's performance if a large amount of memory is allocated or if it is disabled.
        Note
        
        

        If you enable In-memory in a primary database with Data Guard enabled, the configuration will be replicated to the standby database as read-only.

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

      Your tenancies come with a library of standard tags that would apply to most resources. These tags are currently available as a set of Tag Namespaces that your governance administrators can deploy. OCI best practices recommend applying these tags to all resources. Besides reporting and governance, OCI service automation can deliver workload-specific optimizations based on standard tag values.

      For example, database deployments for the PeopleSoft application require a specific configuration. Setting the appropriate application tag key in the Oracle-ApplicationName tag namespace while deploying an Autonomous Database, can ensure that the database is configured and ready for the particular application, for example, PeopleSoft out of the box.

      For more information, see Tagging Oracle Exadata Database Service on Cloud@Customer Resources.

12. Click Create 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. To change the protection mode and Fast-Start Failover (FSFO) lag limit of the primary database, select Update Autonomous Data Guard from the More Actions drop-down list.
   1. In the resulting Update Autonomous Data Guard dialog, make changes and click Save Changes.
6. Under Resources, click Autonomous Data Guard to view association details.

If automatic backups were disabled while provisioning an Autonomous Container Database (ACD), you can enable them later from the Oracle Cloud Infrastructure (OCI) console.

1. Go to the Details page of the Autonomous Container Database whose backup settings you want to change.
2. Under More actions, click Edit Backup Settings.
   Note
   
   

   You can also edit the backup settings by clicking the Edit link under the Backup section on the Autonomous Container Database Information tab.

   The Edit Backup Settings dialog opens.

3. If automatic backups are disabled for this ACD, enable them by selecting the Enable automatic backups checkbox, and choose appropriate values for the following settings:
   • Backup destination type: Select a Backup destination type and then specify options based on the selected type.
     Note
     
     The backup destination type can only be set while enabling automatic backups on an ACD and cannot be changed later.
     The possible options are:

     • Object Storage: Stores backups in an Oracle-managed object storage container on Oracle Cloud Infrastructure.

       If you choose Object Storage as the type, you can optionally specify an internet HTTP proxy to use when connecting to the storage container. Oracle recommends using a proxy when possible for enhanced security.

     • Network File System (NFS): Stores backups in a Network File System (NFS) storage location.

       If you choose Network File System (NFS) as the type, select a previously defined Backup Destination that uses Network File System (NFS) storage.

     • Recovery Appliance: Stores backups in one of your previously defined backup destinations that use Oracle Zero Data Loss Recovery Appliance.

       If you choose Recovery Appliance as the type, select a previously defined Backup Destination that uses Oracle Zero Data Loss Recovery Appliance, the DB_UNIQUE_NAME of the Autonomous Container Database, and the VPC user name password.

       Provide the connection string that connects to the recovery appliance in an Oracle "easy connect" string format, that is, <host>:<port>/<service name>, where <host> is the SCAN hostname of the Zero Data Loss Recovery Appliance.

   • Backup retention period (in days): Specify a Backup retention period value to meet your needs. You can choose any value between 7 to 95 days.

     For the Object Storage and Network File System (NFS) backup destination types, the backup retention policy value defaults to 30 days.

     For the Recovery Appliance backup destination type, this value is controlled by the Recovery Appliance protection policy.

     All the backups are automatically deleted after the backup retention period.

4. Click Save Changes.

A snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot 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 physical standby database you are interested in.

   Autonomous Container Database Details page is displayed.

4. Select Convert to snapshot standby from the More Actions drop-down list.
   Note
   
   

   You cannot convert a physical standby to a snapshot standby with Automatic Failover enabled. Disable Automatic Failover to convert your standby database to snapshot standby mode.

5. To disable automatic failover, do the following:
   1. Under Resources, click Autonomous Data Guard.
   2. Click the name of the peer (primary) database.

      Primary ACD details page is displayed.

   3. Select Update Autonomous Data Guard from the More Actions drop-down list.
   4. In the resulting Update Autonomous Data Guard dialog, clear the Enable automatic failover checkbox.
   5. Click Save Changes.
6. After disabling automatic failover, continue with converting your physical standby to snapshot standby.

   Review the warning message on the Convert to Snapshot Standby window.

   Convert to Snapshot Standby supports two options:

   • Use New Database Services: Connect to snapshot standby database using new services that are active only in snapshot standby mode.
   • Use Primary Database Services: Connect to the snapshot standby database using the same services in the primary database.

   Selecting the Use Primary Database Services option will display an additional warning message about configuring proper connection strings to connect to primary and snapshot standby databases respectively to avoid incorrect database connections.

7. Click Convert.

   After the conversion, the role of the standby database changes to Snapshot Standby, and the Convert to Physical Standby option becomes available in the More Actions drop-down list.

   Note
   
   

   Convert to physical standby ACD will only be enabled when ACD is in SNAPSHOT_STANDBY mode.

   • Converting to physical standby ACD will discard all local updates from all ADBs and apply redo data from primary ACD.
   • Converting to physical standby will revert the standby ACD role and all its ADBs roles to STANDBY.

A snapshot standby database will automatically convert back to a physical standby database after 7 days.

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 snapshot standby database you are interested in.

   Autonomous Container Database Details page is displayed.

4. Select Convert to physical standby from the More Actions drop-down list.
   Note
   
   

   If you convert your snapshot standby Autonomous Container Database to physical standby, all local updates to your snapshot standby will be discarded and data from your primary Autonomous Container Database will be applied.

5. Click Convert.

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.

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:

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.

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 or snapshot standby associated with the primary Autonomous Container Database that you want to failover.

   The system displays a warning when you perform a failover operation when the standby ACD is in snapshot standby mode:

   WARNING:

   Your standby database is in a snapshot standby role. Failover will convert your snapshot standby database to physical standby by discarding all local updates to your snapshot standby and applying data from your primary database.
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.

Initiate a switchover operation by using the Data Guard association of the primary 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 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.

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.

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.

Follow these steps to terminate an 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. 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.

Follow these steps to terminate an 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. 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.

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.

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.

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

   • CPU 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 CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

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

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

     On the console, when you try to provision or scale an Autonomous Database, the CPU count will be validated against the list of provisionable CPUs, and if the value is not provisionable, you will be provided with the two nearest provisionable CPU values. Alternatively, if you want to see the complete list of provisionable CPU 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.

     For ECPUs, this value defaults to 2 ECPUs. For databases that need 2 or more ECPUs, you must specify the number of assigned ECPUs in increment of 1.

     Note
     
     

     CPU Overprovisioning is not allowed with ECPUs.

     For OCPUs, the default value is 1 OCPU. However, you can assign a fractional OCPU value from 0.1 to 0.9 (in increments of 0.1 OCPU) to databases that do not need a full OCPU. This allows you to over-provision CPU and run more databases on each infrastructure instance. For databases that need 1 or more OCPUs, you must specify the number of assigned OCPUs as an integer. For example, you cannot assign 3.5 OCPUs to a database. The next available number of OCPUs above 3 is 4.

     Databases with CPU over-provisioning can only connect using tp and low services.

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

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.

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.

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, click Edit Maintenance Preferences.

   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.

   Configure Container Database maintenance version

   • Next Release Update (RU): Update to the next release update in the next maintenance cycle.
   • Latest Release Update (RU): Update to the latest release update in the next maintenance cycle.
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.

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

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

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.

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.