By default, automatic backups are enabled for an Autonomous Container Database (ACD). However, you can now disable them while provisioning the ACD, and enable them anytime later. Once the automatic backups are enabled you can not disable them for an ACD. You can set the backup retention period for the backups between 7 to 95 days.

Refer to the following for more information:

• Create an Autonomous Container Database
• Edit Autonomous Container Database Backup Settings

You can add resources to or remove them from an Autonomous Exadata VM Cluster (AVMC). This is called Autonomous Exadata VM Cluster vertical scaling.

This ability lets you scale up or scale down an AVMC by modifying the following resources:

• Number of CPUs per VM
• Number of Autonomous Container Databases (ACDs)
• Database storage

For instructions, see Manage Autonomous Exadata VM Cluster Resources.

We have added a new section to describe the strategies implemented by Autonomous Database to provide standard, hardended security configurations for your Autonomous VMs (Client VMs).

Refer to Configuration Management in Autonomous Database for details.

On Oracle Public Cloud deployments, you can enable Autonomous Data Guard and add a standby Autonomous Container Database (ACD) to Autonomous Container Databases (ACD) provisioned already.

For more information, see Enable Autonomous Data Guard on Autonomous Container Database.

You can use Oracle Real Application Testing Database Replay to capture workload from an on-premises or other cloud service database and replay it on an Autonomous Database instance. This enables you to compare workloads between an on-premises database or other cloud service database and an Autonomous Database.

You can also capture workload from an Autonomous Database on Dedicated Exadata Infrastructure and replay it on the same or any other Autonomous Database. This can be useful in scenarios where you want to test a patch or upgrade before applying it on your production database.

See Using Oracle Real Application Testing for more information.

You can now refer to Security Features in Autonomous Database on Dedicated Exadata Infrastructure for complete information about the key security features supported by Autonomous Database on Dedicated Exadata Infrastructure.

This document comes with a clickable graphic representing the building blocks for the key security features of the Autonomous Database. You can also click the block you are interested in exploring further.

You can now choose to include or exclude a time-zone file update along with your quarterly automatic maintenance patches, either while provisioning an Autonomous Container Database (ACD) or for an existing ACD.

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.

You can also 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. Refer to Schedule a Quarterly Maintenance Update for instructions.

You now have the option to choose between rolling or non-rolling maintenance methods to apply quarterly automatic maintenance patches. You can configure the maintenance method while provisioning an Autonomous Container Database (ACD) or for an existing ACD. The non-rolling maintenance method involves a full system downtime.

See Service Maintenance Types for more information and Update Autonomous Container Database Maintenance Preferences for detailed instructions.

You can configure your Autonomous Database resources using a new compute type called ECPUs.

An ECPU is an abstracted measure of compute resources. ECPUs are based on the number of cores elastically allocated from a pool of compute and storage servers.

For more information about the compute models supported by Autonomous Database, see Compute Models in Autonomous Database.

On Oracle Exadata Cloud@Customer deployments, you can monitor and track your Exadata resource allocation and usage across Autonomous Exadata VM Clusters (AVMC) and Autonomous Container Databases (ACD) with enhanced granularity and new visuals on the Oracle Cloud Infrastructure (OCI) console, in real-time.

This release lets you get a comprehensive and clear picture of the compute and storage resources' allocation and usage at the AVMC and ACD levels from their Details page on the OCI console. Depending on your choice, you can view this information in a graphical or table view.

Understanding and knowing these details can help you optimize your resource allocation to Autonomous Databases and efficiently forecast your capacity needs.

For the exact list of the resource details you can monitor from the AVMC and ACD Details page and what they mean, refer to Plan and Monitor Capacity.

When you create Autonomous Database deployments on Exadata Cloud@Customer, you can now deploy to X10M Exadata Database Machine systems.

For details about the capacities and characteristics of the X10M systems supported by Autonomous Database, see Exadata X10M Systems.

Autonomous Database on Dedicated Exadata Infrastructure lets you restrict Oracle operator access to a specific Autonomous Container Database (ACD) in an Autonomous Exadata VM Cluster (AVMC) in the diagnostic and maintenance cages.

With this restriction enabled, you receive an approval request with the details to which the operators are requesting access. Once you review and approve the access request, the operators will get SQL access to only those approved ACDs.

Refer to Auditing Oracle Operator Activities to know more about about Oracle operator access control.

On Oracle Public Cloud deployments, you can monitor and track your Exadata resource allocation and usage across Autonomous Exadata VM Clusters (AVMC) and Autonomous Container Databases (ACD) with enhanced granularity and new visuals on the Oracle Cloud Infrastructure (OCI) console, in real-time.

This release lets you get a comprehensive and clear picture of the compute and storage resources' allocation and usage at the AVMC and ACD levels from their Details page on the OCI console. Depending on your choice, you can view this information in a graphical or table view.

Understanding and knowing these details can help you optimize your resource allocation to Autonomous Databases and efficiently forecast your capacity needs.

For the exact list of the resource details you can monitor from the AVMC and ACD Details page and what they mean, refer to Plan and Monitor Capacity.

You can enable Database In-memory for your Autonomous Database by allocating a percentage of its System Global Area (SGA) to the In-Memory column store (IM column store).

You can enable or disable Database In-memory while or after provisioning the database with at least 4 OCPUs enabled. Scaling down the CPU count to less than 4 OCPUs later automatically disables it.

You can also enable Database In-Memory on databases cloned from a database instance or backup, irrespective of whether the clone source has Database In-memory enabled.

Please see Database In-Memory for the requirements and guidelines to use this feature with Autonomous Database.

Refer to Enable or Disable Database In-Memory or Create an Autonomous Database on Dedicated Exadata Infrastructure for detailed instructions.

When you create Autonomous Database deployments on Oracle Exadata Cloud@Customer, you can now deploy to X10M Exadata Database Machine systems.

For details about the capacities and characteristics of the X10M systems supported by Autonomous Database, see Exadata X10M Systems.

On Exadata Cloud@Customer deployments, you can specify an Exadata Infrastructure and Autonomous Exadata VM Cluster that is in a different region from the primary database's Exadata Infrastructure and Autonomous Exadata VM Cluster.

This choice provides the highest level of protection against disasters, including a catastrophic loss of external network connectivity or power to an entire region.

For more details about Autonomous Data Guard and related concepts, refer to Protect Critical Databases from Failures and Disasters Using Autonomous Data Guard.

On Exadata Cloud@Customer deployments, you can:

• Clone an Autonomous Database, with or without Autonomous Data Guard, to an Autonomous Container Database, with or without Autonomous Data Guard, on another Exadata Infrastructure in the same or a different region. In the case of Autonomous Databases with Autonomous Data Guard, you can clone only from the primary database.
• Create a new Autonomous Database from a backup on the same or another Exadata Infrastructure in the same or a different region. In the case of Autonomous Databases that use Autonomous Data Guard, create a new database instance from either primary or standby database backups in the same or a different region.

For step-by-step instructions, see:

• Clone an Autonomous Database Instance
• Clone Autonomous Database from Backup

The existing documentation related to the high-performance features supported by Autonomous Database on Dedicated Exadata Infrastructure is improvised to provide comprehensive information in a single article.

Refer to High Performance Features in Autonomous Database on Dedicated Exadata Infrastructure for more information.

Oracle Autonomous Database on Dedicated Exadata Infrastructure comes in different infrastructure shapes to support workloads of different sizes. In this release, the capability of Autonomous Database on Dedicated Exadata Infrastructure has been extended to support Base shape.

See Resource Limits and Characteristics of Infrastructure Shapes for more information.

You can use DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION to enable Kerberos, Microsoft Azure AD, or Identity and Access Management (IAM) Authentication as an external authentication scheme for your Autonomous Database.

As an alternative to an object store location URI, you can now specify a directory with DBMS_CLOUD procedures to load or unload data from files in a directory, including directories created on attached network file systems.

The following procedures support specifying files in a directory with the file_uri_list parameter:

• DBMS_CLOUD.COPY_COLLECTION
• DBMS_CLOUD.COPY_DATA
• DBMS_CLOUD.CREATE_EXTERNAL_TABLE

The following procedures support specifying files in a directory with the partitioning_clause parameter:

• DBMS_CLOUD.CREATE_EXTERNAL_TABLE
• DBMS_CLOUD.CREATE_HYBRID_PART_TABLE

Refer to DBMS_CLOUD for Objects and Files for more details.

You can now directly query and load data stored as Apache Avro, Apache Parquet, or ORC format files into Autonomous Database. You can also create external tables for Avro, Parquet or ORC format data files.

Autonomous Database on Exadata Cloud@Customer now supports the compartment quotas feature of Oracle Cloud Infrastructure. Using this feature you can restrict, on a compartment by compartment basis, the availability of dedicated infrastructure resources in your tenancy.

For more information, see Manage Resource Availability with Compartment Quotas . For general information about the compartment quotas feature, see Compartment Quotas.

On Oracle Public Cloud, you can now select the DB Servers while deploying a new Autonomous Exadata VM Cluster (AVMC) resource. This option is available only while provisioning an AVMC resource, and you can not change the selection after creating the AVMC successfully.

For more details, refer to Create Autonomous Exadata VM Cluster.

Oracle schedules and performs monthly infrastructure security maintenance alongside quarterly maintenance. This maintenance activity is scheduled to be applied during a 21-day window that begins after the 15th of each month. You will receive notification of the proposed schedule at least 7 days before the start of the monthly maintenance window, and you can reschedule monthly maintenance to another date in the window if desired.

These security patches are applied only in those months with critical security updates, including fixes for vulnerabilities with CVSS scores greater than or equal to 7. Please refer to Service Maintenance in Autonomous Database on Dedicated Exadata Infrastructure for more details.

The existing documentation explaining the High-Performance features supported by Autonomous Database on Dedicated Exadata Infrastructure is improvised and consolidated into a single article. This new article describes how to use the different performance monitoring and tuning features supported by Autonomous Database, referencing the related how-to guides.

For more details, see High Performance Features in Autonomous Database.

On Oracle Public Cloud deployments, you can now seed your own security certificates with an Autonomous Exadata VM Cluster (AVMC) using the Oracle Cloud Infrastructure (OCI) console. This feature lets you use your CA-signed server-side Oracle REST Data Services (ORDS) or Secure Socket Layer (SSL) certificates while rotating the security certificates of your AVMC resource.

Refer to Manage Security Certificates for an Autonomous Exadata VM Cluster Resource for more details.

You can now add additional storage servers to an existing Exadata Infrastructure resource and can create new Autonomous Exadata VM Clusters (AVMCs) using the newly added storage. In simple terms, you can scale your Exadata Infrastructure storage on-demand in an automated, elastic fashion.

The initialization parameter SYSDATE_AT_DBTIMEZONE parameter enables special handling in a session for the date and time value returned in calls to SYSDATE and SYSTIMESTAMP. Depending on the value of SYSDATE_AT_DBTIMEZONE, you see either the date and time based on the default Autonomous Database time zone, Coordinated Universal Time ‎(UTC)‎, or based on the time zone that you set in your database.

See SYSDATE_AT_DBTIMEZONE for more information.

See Create an Autonomous Exadata VM Cluster for more details.

You can now attach external NFS devices provided by the customer or OCI FSS using the DBMS_CLOUD_ADMIN procedures. This allows you to load data from external file storage in your Virtual Cloud Network (VCN) or any other Network File System in on-premises data centers.

Oracle Autonomous Database on Dedicated Exadata Infrastructure comes in different infrastructure shapes to support workloads of different sizes. In this release, the capability of Oracle Exadata Cloud@Customer has been extended to support Base shape.

See Resource Limits and Characteristics of Infrastructure Shapes for more information.

You can now seed your own security certificates with an Autonomous Exadata VM Cluster (AVMC) on Exadata Cloud@Customer using the Oracle Cloud Infrastructure console.

This feature lets you use your CA-signed server-side Oracle REST Data Services (ORDS) or Secure Socket Layer (SSL) certificates while rotating the security certificates of your AVMC resource.

Refer to Manage Security Certificates for an Autonomous Exadata VM Cluster Resource for details.

While provisioning an Autonomous Container Database (ACD), you can now set the container database name of your choice from the Oracle Cloud Infrastructure (OCI) console. See Create an Autonomous Container Database for more details.

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.

You can now use Kerberos to authenticate your Autonomous Database users.

For detailed guidance on configuring Kerberos authentication, its prerequisites and limitations, refer to Authenticate Autonomous Database Users With Kerberos.

You can now use SQL tracing to help you identify the source of an excessive database workload, such as a high load SQL statement in your application.

See Use SQL Tracing on Autonomous Database for more information.

You can now create and alter user profiles on Autonomous Database on Dedicated Exadata Infrastructure with a Password Verification Function (PVF).

See Manage User Profiles with Autonomous Database for more information.

You can now download and use Oracle Client for Microsoft Tools (OCMT), which is a graphical user interface (GUI) native Microsoft Software installer (MSI) that simplifies ODP.NET setup and Oracle database connectivity to multiple Microsoft data tools.

Refer to Connect Power BI and Microsoft Data Tools to Autonomous Database for more details and instructions on using OCMT.

We have now removed the requirement of one available Autonomous Container Database (ACD) and lowered the initial resource requirements to 1 OCPU for cloning an Autonomous Database from a backup.

Refer to Clone Requirements for more details.

You can now create long-term backups on Autonomous Database with a retention period anywhere from 90 days to 10 years. If needed, you can also update the retention period of a long-term backup to a different value after creating it.

Refer to Backup and Restore Autonomous Databases for more details.

DBMS_CLOUD package reference is now updated with more procedures and functions.

Support to save resource configuration as a stack

While provisioning new Autonomous Database resources from the Oracle Cloud Infrastructure console, you can now save the resource configuration as a stack with the click of a single button. You can then use the stack to create the resource through the Resource Manager service.

A stack is a collection of Oracle Cloud Infrastructure resources corresponding to a Terraform configuration. Each stack resides in the compartment you specify in a single region. You can then deploy the resources on a given stack across multiple regions. For more information, see stack.

Support for Autonomous VM Cluster node subsetting on Autonomous Database on Exadata Cloud@Customer

On Exadata Cloud@Customer deployments, you can now select the DB Servers while deploying a new Autonomous Exadata VM Cluster (AVMC) resource. This option is available only while provisioning an AVMC resource, and you can not change the selection after creating the AVMC successfully.

For more details, refer to Create Autonomous Exadata VM Cluster.

Support for snapshot standby database in an Autonomous Data Guard setup

You can now convert a standby database to a snapshot standby database by changing the standby Autonomous Container Database (ACD) to a snapshot standby ACD. See Convert Physical Standby to Snapshot Standby for step-by-step instructions.

A snapshot standby database allows read-write operations on its data while maintaining minimum or zero data loss based on the protection mode. It receives and archives, but does not apply, redo data from the primary database.

A snapshot standby database is helpful when you need to use your standby database for read-write operations, for instance, to test a patch before applying it to the primary database. Refer to Snapshot Standby Database for the requirements and limitations of the snapshot standby database.

Ability to update Protection mode and Fast start failover lag time

You can now change the protection mode of an Autonomous Data Guard setup. You can also modify the Fast start failover lag limit to any value between 5 to 3600 seconds for a primary ACD with automatic failover in an Autonomous Data Guard setup.

See Update Autonomous Data Guard Settings for detailed instructions.

Oracle Home version control

You can now choose the Oracle Home version while provisioning an Autonomous Container Database on Dedicated Exadata Infrastructure. You have an option to choose between the latest Oracle Database version supported by Autonomous Database 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 on the Create Autonomous Container Database page lists 19.18.0.1.0 and 19.17.0.1.0. for you to choose.

Refer to Create Autonomous Container Database for more details.

Ability to configure maintenance version of an Autonomous Container Database

You can now configure the maintenance type of an Autonomous Container Database to either Next RU or Latest RU to update to the next release update or the latest release update in the next maintenance window, respectively.

Refer to Change the Maintenance Type of an Autonomous Container Database for more details.