About Autonomous Container Database

Autonomous Container Database (ACD) is one of the four components of the four-level database architecture model, which is the foundation for an Autonomous Database on Dedicated Exadata Infrastructure. ACDs are provisioned inside an Autonomous Exadata VM Cluster (AVMC) and serve as containers for one or more Autonomous Databases.

You can create multiple ACD resources in a single AVMC resource, but you must create at least one before you can create any Autonomous Databases. To gain a comprehensive understanding of the four-layer architecture used with the an Autonomous Database on Dedicated Exadata Infrastructure and to understand the positioning of ACD within this architecture, refer to Components of Autonomous Database on Dedicated Exadata Infrastructure.

ACDs provide the benefit of operating in isolation from each other, allowing you to separate Autonomous Databases by their intended uses. For example, you can create different ACDs for purposes like production and testing, or even have multiple ACDs using different database versions.

Although Fleet Administrators create, monitor, and manage ACDs, Application DBAs primarily use them to create Autonomous Databases. See User Roles Associated with Autonomous Database on Dedicated Exadata Infrastructure to learn more.

Parent topic: Create and Manage Autonomous Container Databases

Autonomous Container Database Requirements

Note

Autonomous Container Databases (ACD) with the 23ai database software version can only be provisioned on ECPU-based Autonomous Exadata VM Clusters (AVMC) created on or after the launch of 23ai support, with the appropriate Tags. See 23ai Database Software Version Tag Requirements for details.

IAM Policy Requirements

You must have an Oracle Cloud Infrastructure account with privileges granted through required IAM Policies. The required policies depend on the operation you are performing. For a list of IAM policies pertaining to Autonomous Container Databases, see Policies to Manage Autonomous Container Databases.

Minimum Resource Requirements

To create one Autonomous Container Database, you need at least:

2 OCPUs or 8 ECPUs
50GB local storage

Note

If you are deploying on Oracle Public Cloud, make sure your service limits show at least one supported Exadata system shape available. Before attempting to create the infrastructure resources, request a service limit increase if necessary. Refer to Request a Service Limit Increase for more details.

Parent topic: About Autonomous Container Database

Database Features Managed from Autonomous Container Database

The following features of Autonomous Database can be defined and managed at the Autonomous Container Database (ACD) level.

Autonomous Database Feature Notes Further Reference

Autonomous Database Feature	Notes	Further Reference
Oracle Database software version You can set the container database software version while provisioning an ACD.	You can choose the Oracle Database software version either from a base image version or an Autonomous Database software imagethat was created from another ACD. While selecting version from the base image, 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.22.0.1.0. Then, the Select base image drop-down lists 19.22.0.1.0 and 19.21.0.1.0. for you to choose. Note The only available Container Database Software Version is 23ai for ACDs being provisioned on an ECPU-based AVMC with the DatabaseVersion tag set to 23ai.	-
Autonomous Data Guard Configuring Autonomous Data Guard enables you to keep your critical production databases available to mission critical applications despite failures.	You can configure Autonomous Data Guard to create primary and standby ACDs. The primary and secondary ACDs can also be deployed in different regions (cross-region). However, in a cross-region Autonomous Data Guard setup, 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. Minimum fast start lag limit value supported by ACDs with 19.17 and older versions is 30 seconds. You can enable Autonomous Data Guard for both new and existing ACDs.	Protect Critical Databases from Failures and Disasters Using Autonomous Data Guard
Maintenance Schedule In general, Oracle schedules and performs entire fleet maintenance spread throughout each quarter and monthly infrastructure security fixes for vulnerabilities with CVSS scores greater than or equal to 7. You can let Oracle handle maintenance scheduling, or you can set a specific maintenance window when Oracle can begin maintenance operations.	You can choose between Rolling or Non-rolling maintenance methods for an ACD. If you choose non-rolling maintenance method in an Autonomous Data Guard configuration, there will be a downtime for the ACD and all associated Autonomous Databases until the patching completes. Optionally, you can also select Enable time-zone update. Time-zone files can only be updated using the non-rolling configuration method. You can define or modify the maintenance schedule settings for an ACD to be managed by Oracle or you can set a custom maintenance schedule. While customizing the maintenance schedule of an ACD, you can choose to skip patching for a quarter. However, you cannot skip patching for two consecutive quarters. When you choose to skip patching for a quarter, you need to select at least one month from that quarter. This acts as a fallback in case maintenance did not occur in the previous un-skipped quarter. In this scenario, Oracle will automatically perform the maintenance in the selected month, even if skipping is chosen for that quarter. You can view the number of one-off patches available for an ACD on its Details page. Clicking the Copy link next to it copies all those one-off patch numbers. When you reschedule an ACD maintenance event that is already scheduled, Oracle may place it in a queue if its Exadata Infrastructure resource or Autonomous Exadata VM Cluster resource is: Already undergoing a maintenance update, or Scheduled for a maintenance activity simultaneously as the ACD. You can schedule an on-demand maintenance to update RU (Release Update) along with the time-zone file or just the time-zone file for an ACD. You can also choose to update using an existing custom database software image. You may experience downtime for your ACD and the associated Autonomous Databases depending on the configuration of your ACD's maintenance schedule.	Service Maintenance Schedule a Quarterly Maintenance Update
Backup Retention Policy To support high availability, Autonomous Database automatically backs up your database for you. The retention period for backups is up to 60 days depending on the backup retention policy/period chosen for the ACD. You can restore and recover your database to any point-in-time in this retention period.	Once enabled, automatic backups can not be disabled for an ACD. You can define the backup retention policy/period while provisioning an ACD or modify it later from its details page on the Oracle Cloud Infrastructure console console. On Oracle Public Cloud deployments, the backup retention policy value defaults to 15 days. On Exadata Cloud@CustomerExadata Cloud@Customer deployments, the backup retention policy: Defaults to 30 days for Object Storage and Network File System (NFS) backup destination types. Is controlled by the Recovery Appliance protection policy for the Recovery Appliance backup destination type. All the backups are automatically deleted after the backup retention period.	Backup and Restore Autonomous Databases.
Backup Destination A backup destination defines the properties that are required to connect to a backup location, and each backup destination must be accessible in your data center from the VM cluster nodes.	APPLIES TO: 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. 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.	To learn more about configuring NFS backup destination for Cloud@Customer, see Prerequisites for Backup Destinations for Exadata Cloud@Customer. Refer to Edit Autonomous Container Database Backup Settings for instructions on changing the backup destination type after provisioning the ACD.
Resource Management Attributes Resource management attributes affect how resources are managed to either consolidate more databases or have the highest database availability.	Optionally, while provisioning an ACD, 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.	For more information on how these ACD attributes affect the performance of your databases, see Compute Management and Billing.
Shared Server Connections 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.	While provisioning an ACD, you can optionally enable shared server connections. You cannot disable shared server architecture after provisioning the ACD.	Special-Purpose Connection Features.
Encryption Key By default, Autonomous Database creates and manages all the master encryption keys used to protect your data, storing them in a secure PKCS 12 keystore on the same Exadata systems where the databases reside. If your company security policies require, Autonomous Database can instead use keys you create and manage.	While provisioning an ACD, you can optionally configure the ACD to use customer-managed encryption keys instead of Oracle-managed encryption keys. You can choose between the following options when using customer managed encryption keys: OCI Vault Service: With this option you select a Vault and a Master Encryption Key. This option is only available on Oracle Public Cloud. Oracle Key Vault: You select a Key Store with this option. You can use customer-managed encryption keys with Autonomous Data Guard-enabled ACDs with the primary and standby databases located in different availability domains within the same region.	About Master Encryption Keys Rotate the Encryption Key of an Autonomous Container Database. Prepare to Use Oracle Key Vault

Oracle Database software version

You can set the container database software version while provisioning an ACD.

You can choose the Oracle Database software version either from a base image version or an Autonomous Database software imagethat was created from another ACD.

While selecting version from the base image, 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.22.0.1.0. Then, the Select base image drop-down lists 19.22.0.1.0 and 19.21.0.1.0. for you to choose.

Note

The only available Container Database Software Version is 23ai for ACDs being provisioned on an ECPU-based AVMC with the DatabaseVersion tag set to 23ai.

Autonomous Data Guard

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

You can configure Autonomous Data Guard to create primary and standby ACDs.

The primary and secondary ACDs can also be deployed in different regions (cross-region). However, in a cross-region Autonomous Data Guard setup, 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.
Minimum fast start lag limit value supported by ACDs with 19.17 and older versions is 30 seconds.
You can enable Autonomous Data Guard for both new and existing ACDs.

Protect Critical Databases from Failures and Disasters Using Autonomous Data Guard

Maintenance Schedule

In general, Oracle schedules and performs entire fleet maintenance spread throughout each quarter and monthly infrastructure security fixes for vulnerabilities with CVSS scores greater than or equal to 7.

You can let Oracle handle maintenance scheduling, or you can set a specific maintenance window when Oracle can begin maintenance operations.

You can choose between Rolling or Non-rolling maintenance methods for an ACD. If you choose non-rolling maintenance method in an Autonomous Data Guard configuration, there will be a downtime for the ACD and all associated Autonomous Databases until the patching completes. Optionally, you can also select Enable time-zone update. Time-zone files can only be updated using the non-rolling configuration method.

You can define or modify the maintenance schedule settings for an ACD to be managed by Oracle or you can set a custom maintenance schedule.

While customizing the maintenance schedule of an ACD, you can choose to skip patching for a quarter. However, you cannot skip patching for two consecutive quarters. When you choose to skip patching for a quarter, you need to select at least one month from that quarter. This acts as a fallback in case maintenance did not occur in the previous un-skipped quarter. In this scenario, Oracle will automatically perform the maintenance in the selected month, even if skipping is chosen for that quarter.

You can view the number of one-off patches available for an ACD on its Details page. Clicking the Copy link next to it copies all those one-off patch numbers.

When you reschedule an ACD maintenance event that is already scheduled, Oracle may place it in a queue if its Exadata Infrastructure resource or Autonomous Exadata VM Cluster resource is:

Already undergoing a maintenance update, or
Scheduled for a maintenance activity simultaneously as the ACD.

You can schedule an on-demand maintenance to update RU (Release Update) along with the time-zone file or just the time-zone file for an ACD. You can also choose to update using an existing custom database software image.

You may experience downtime for your ACD and the associated Autonomous Databases depending on the configuration of your ACD's maintenance schedule.

Service Maintenance

Schedule a Quarterly Maintenance Update

Backup Retention Policy

To support high availability, Autonomous Database automatically backs up your database for you. The retention period for backups is up to 60 days depending on the backup retention policy/period chosen for the ACD. You can restore and recover your database to any point-in-time in this retention period.

Once enabled, automatic backups can not be disabled for an ACD.

You can define the backup retention policy/period while provisioning an ACD or modify it later from its details page on the Oracle Cloud Infrastructure console console.

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

On Exadata Cloud@CustomerExadata Cloud@Customer deployments, the backup retention policy:

Defaults to 30 days for Object Storage and Network File System (NFS) backup destination types.
Is controlled by the Recovery Appliance protection policy for the Recovery Appliance backup destination type.

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

Backup and Restore Autonomous Databases.

Backup Destination

A backup destination defines the properties that are required to connect to a backup location, and each backup destination must be accessible in your data center from the VM cluster nodes.

APPLIES TO: 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.

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.

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

Refer to Edit Autonomous Container Database Backup Settings for instructions on changing the backup destination type after provisioning the ACD.

Resource Management Attributes

Resource management attributes affect how resources are managed to either consolidate more databases or have the highest database availability.

Optionally, while provisioning an ACD, 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.

For more information on how these ACD attributes affect the performance of your databases, see Compute Management and Billing.

Shared Server Connections

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.

While provisioning an ACD, you can optionally enable shared server connections. You cannot disable shared server architecture after provisioning the ACD.

Special-Purpose Connection Features.

Encryption Key

By default, Autonomous Database creates and manages all the master encryption keys used to protect your data, storing them in a secure PKCS 12 keystore on the same Exadata systems where the databases reside.

If your company security policies require, Autonomous Database can instead use keys you create and manage.

While provisioning an ACD, you can optionally configure the ACD to use customer-managed encryption keys instead of Oracle-managed encryption keys.

You can choose between the following options when using customer managed encryption keys:

OCI Vault Service: With this option you select a Vault and a Master Encryption Key. This option is only available on Oracle Public Cloud.
Oracle Key Vault: You select a Key Store with this option.

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

About Master Encryption Keys

Rotate the Encryption Key of an Autonomous Container Database.

Prepare to Use Oracle Key Vault

Parent topic: About Autonomous Container Database

Autonomous Container Database Management Operations

You can perform the following management operations on an Autonomous Container Database.

Operation	Task Instructions
Create an Autonomous Container Database	Create an Autonomous Container Database
Create an Autonomous Database software image	Create an Autonomous Database Software Image
View a list of Autonomous Container Databases	View a list of Autonomous Container Databases
View details of an Autonomous Container Database	View details of an Autonomous Container Database
Change the backup retention policy of an Autonomous Container Database	Edit Autonomous Container Database Backup Settings
Edit the maintenance preferences of an Autonomous Container Database	Update Autonomous Container Database Maintenance Preferences
Restart an Autonomous Container Database	Restart an Autonomous Container Database
Move an Autonomous Container Database to another compartment	Move an Autonomous Container Database to a Different Compartment
Rotate an Autonomous Container Database encryption key	Rotate the Encryption Key of an Autonomous Container Database
Terminate an Autonomous Container Database	Terminate an Autonomous Container Database

The above listed operations can also be achieved using API. See API to Manage Autonomous Container Databases for further reference.

Parent topic: About Autonomous Container Database

Oracle Cloud Infrastructure Documentation

Autonomous Container Database Requirements

Database Features Managed from Autonomous Container Database

Autonomous Container Database Management Operations