Create an Autonomous Container Database

You create an Autonomous Container Database from the Autonomous Container Databases page.

Required IAM Policies

Deployment Choice IAM Policies
Oracle Public Cloud

manage autonomous-container-databases

use cloud-exadata-infrastructures

use cloud-autonomous-vmclusters
Exadata Cloud@Customer

manage autonomous-container-databases

use cloud-exadata-infrastructures

use autonomous-vmclusters

use backup-destinations

Minimum Resource Requirements

To create one Autonomous Container Database, you need at least:
  • 2 OCPUs or 8 ECPUs
  • 50GB local storage

Related Live Labs

For a "try it out" alternative that demonstrates these instructions, see Lab 6: Provisioning an Autonomous Container Database in Oracle Autonomous Database Dedicated for Fleet Administrators Workshop.

Procedure

  1. Go to Autonomous Database in the Oracle Cloud Infrastructure Console.

    For instructions, see Access Dedicated Autonomous Database in the Oracle Cloud Infrastructure Console.

  2. In the side menu’s list of resource types, click Autonomous Container Database.

    The list of Autonomous Container Databases in your current Compartment is displayed.

  3. In the side menu’s Compartment list, select the Compartment where you want to create an Autonomous Container Database.

    The list of Autonomous Container Databases refreshes to show those in the selected Compartment.

  4. Click Create Autonomous Container Database.

    The Create Autonomous Container Database page is displayed.

  5. Fill out the Create Autonomous Container Database page with the following information:
    Setting Description Notes

    Compartment

    Select a compartment to host the Autonomous Exadata VM Cluster.

    		  

    Display name

    Enter a user-friendly description or other information that helps you easily identify the resource.

    The display name does not have to be unique and you can change it whenever you want.

    Avoid entering confidential information.

    Container Database Name

    Enter a name for the container database. It can contain only letters and numbers. Starting with a letter and a maximum of 30 characters.
    The container database name must be unique across the Autonomous Exadata VM Cluster.

    Tip:

    In Exadata Cloud@Customer deployments, container database name is used to name the Oracle Key Vault's (OKV) wallet. You can use this name to locate the OKV wallet associated with your Autonomous Container Database on your OKV console.

    Exadata Infrastructure

    The Exadata Infrastructure to host the new Autonomous Container Database.

    		 APPLIES TO: Applicable Oracle Public Cloud only

    Autonomous Exadata VM Cluster

    The Autonomous Exadata VM Cluster to host the new Autonomous Container Database.

    		  

    Container Database Software Version

    Oracle Database software version for the Autonomous Container Database.

    Depending on your preference, select one of the following options:

    • Select version from base images: When this option is selected, choose an Oracle Database software version from the Select base image list.
    • Custom database software image: With this option, you can choose a custom image from the Choose custom image dialog.

    See Create an Autonomous Database Software Image to know how to create custom software images.

    While selecting version from base images, you can choose either the latest Oracle Database software version or its immediate predecessor.

    For example: Suppose the latest Oracle Database version supported by Autonomous Database is 19.18.0.1.0. Then, the Select base image drop-down lists 19.18.0.1.0 and 19.17.0.1.0. for you to choose.

    Autonomous Data Guard

    Select Enable Autonomous Data Guard to configure Autonomous Data Guard to create primary and standby autonomous container databases.

    Configuring Autonomous Data Guard enables you to keep your critical production databases available to mission critical applications despite failures.

    Configure Autonomous Data Guard: Standby Container Database

    Provide information about the standby autonomous container database: its compartment, display name, region, the underlying Exadata Infrastructure resource, and Autonomous Exadata VM Cluster in which to place it.

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

    Configure Autonomous Data Guard: Protection mode

    Choose a protection mode from Maximum Performance and Maximum Availability.

    Maximum Performance is selected by default.

    For information about Autonomous Data Guard and guidance in choosing where to place the standby autonomous container database and which protection mode to use, see About Autonomous Data Guard and Choosing Autonomous Data Guard Configuration Options.

    Configure Autonomous Data Guard: Automatic failover

    		 Optionally, select Enable automatic failover and choose a value for Fast start failover lag limit between 5 and 3600 seconds if the protection mode is Maximum Performance.

    Note:

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

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

    Configure automatic maintenance

    The Configure automatic maintenance panel displays the following default settings:

    • Maintenance method: Rolling with time-zone file update disabled.
    • Container database maintenance version: Next release update (RU)
    • Maintenance schedule: No schedule preference specified.

    Optionally, you can configure a maintenance preference or schedule by clicking Modify Maintenance that launches the Edit automatic maintenance dialog.

    DST stands for Daylight Savings Time.

    Edit automatic maintenance

    Configure maintenance method: Choose between Rolling or Non-rolling maintenance methods.

    Optionally, you can also select Enable time-zone update.

    See Service Maintenance Types for more information.

    Configure container database maintenance version: Choose either Next RU or Latest RU to configure the next maintenance version of the ACD.

    Configure automatic maintenance schedule: Optionally, you can change the maintenance schedule from the default (No preference, which permits Oracle to schedule maintenance as needed) to Custom schedule. For guidance on choosing a custom schedule, see Settings in Maintenance Schedule that are Customizable.

    Click Save to close this dialog.

    Updating the time-zone file would require a complete downtime for the ACD and the associated Autonomous Databases. The downtime is dependent on the amount of data that is time-zone sensitive.

    All the RUs that include a time-zone update will be patched in the non-rolling maintenance method (with full system downtime) only. So, if you configure your maintenance to the rolling method and enable time-zone update, all the RUs that include a time-zone update are applied in the non-rolling method only. Only those RUs without a time-zone update are applied in the rolling method.

    In an Autonomous Data Guard configuration, the non-rolling maintenance method results in downtime for the primary and standby ACDs during their respective maintenance window until the patching completes.

    Configure backups: 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.

    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.

    Configure backups: Backup destination type

    After enabling automatic backups, select a Backup destination type and then specify options based on the selected type.

    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.

    		APPLIES TO: Applicable Exadata Cloud@Customer only

    As of the current release, the backup destination type can only be set while enabling automatic backups on an ACD and can not be changed later.

    To learn more about configuring NFS backup destination for Cloud@Customer, see Prerequisites for Backup Destinations for Exadata Cloud at Customer.

    Refer to Edit Autonomous Container Database Backup Settings to change the backup destination type after provisioning the ACD.

    Configure backups: Backup retention period (in days)

    After enabling automatic backups, specify a Backup retention period value to meet your needs. You can choose any value between 7 to 95 days.

    On Oracle Public Cloud deployments, the backup retention policy value defaults to 15 days.

    On Exadata Cloud@Customer deployments, for 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.

    Show/hide advanced options

    By default, advanced options are hidden. Click Show advanced options to display them.

    		 

    Advanced options: Management

    Optionally, you can define a suitable value for the following resource management attributes to suit your needs:

    • Database split threshold (CPU): The CPU value beyond which an Autonomous Database will be opened across multiple nodes. The default value of this attribute is 16 for OCPUs and 64 for ECPUs.
    • Node failover reservation (%): Determines the percentage of CPUs reserved across nodes to support node failover. Allowed values are 0%, 25%, and 50%, with 50% being the default option.
    • Distribution affinity: Determines whether an Autonomous Database must be opened across a minimum or maximum of nodes. By default, Minimum nodes is selected with Maximum nodes being the other option.

    Optionally, select the Enable shared server connections checkbox to support the Net services architecture.

    If the Node failover reservation is set to 0%, your Autonomous Database may face a complete outage during VM failure and maintenance operations such as database patching and container database restart.

    The shared server architecture enables a database server to allow many client processes to share very few server processes, so the number of users that can be supported is increased. You cannot disable shared server architecture after provisioning the ACD. See Special-Purpose Connection Features for more details.

    Advanced options: Encryption Key

    Optionally, you can configure the Autonomous Container Database to use customer-managed encryption keys instead of Oracle-managed encryption keys.

    Select Encrypt using customer-managed keys and then select either the Vault and Master encryption key or the Key Store to use for the Autonomous Container Database, depending on whether you are creating the container database on Oracle Public Cloud or on Exadata Cloud@Customer.

    By default, Encrypt using Oracle-managed keys is selected.

    You can use customer-managed encryption keys with Autonomous Data Guard-enabled Autonomous Container Databases with the primary and standby databases located in different availability domains within the same region.

    For information about using customer-managed keys, see About Master Encryption Keys.

    Advanced options: Tags

    If you want to use tags, add tags by selecting a Tag Namespace, Tag Key, and Tag Value.

    You can not modify the time zone settings for an Autonomous Exadata VM Cluster already provisioned. If needed, you can create a service request in My Oracle Support. For help with filing a support request, see Create a Service Request in My Oracle Support.

  6. Optionally, you can save the resource configuration as a stack by clicking Save as Stack. You can then use the stack to create the resource through the Resource Manager service.

    Enter the following details on the Save as Stack dialog, and click Save.
    • Name: Optionally, enter a name for the stack.
    • Description: Optionally, enter a description for this stack.
    • Save in compartment: Select a compartment where this Stack will reside.
    • Tag namespace, Tag key, and Tag value: Optionally, apply tags to the stack.

    For requirements and recommendations for Terraform configurations used with Resource Manager, see Terraform Configurations for Resource Manager. To provision the resources defined in your stack, apply the configuration.

  7. Click Create Autonomous Container Database.

The list of Autonomous Container Databases refreshes to show the new Autonomous Container Database with a status of Provisioning until it is available.

Related Topics