You can choose a compute model while provisioning an Autonomous Exadata VM Cluster resource. The compute type selected for an Autonomous Exadata VM Cluster applies to all its Autonomous Container Databases and Autonomous Database instances.

Autonomous Database instances are deployed into an Autonomous Exadata VM Cluster (AVMC) and into one of its child Autonomous Container Databases (ACD). Exadata Infrastructures are capable of running multiple AVMCs. The CPUs that you allocate while provisioning an AVMC resource will be the total CPUs available for its Autonomous Databases. When you create multiple AVMCs, each AVMC can have its own value for total CPUs.

Multiple VM Autonomous Exadata VM Cluster is not available on any Oracle Public Cloud deployment of Exadata Infrastructure (EI) resources created before the launch of the Multiple VM Autonomous Database feature. For X8M generation and above Exadata Infrastructure resources created after the Multiple AVMC feature launch, each AVMC is created with one cluster node for each of the servers of the Exadata system shape you choose. For information about constraining these total CPUs across different Groups of users, see How Compartment Quotas Affect CPU Management.

At an AVMC or ACD level, the total number of CPUs available for creating databases is called available CPUs. At the AVMC resource level, available CPUs will be equal to the total CPUs until you create the first ACD. Once you create an ACD,8 ECPUs or 2 OCPUs per node are allocated to the new ACD from the AVMC's available CPUs. So, the available CPUs at the AVMC resource level reduces accordingly. When you create the first Autonomous Database in that ACD, the new database consumes the initially allocated CPUs (8 ECPUs or 2 OCPUs per node). If the new database needs more than 8 ECPUs or 2 OCPUs, they get assigned from the parent AVMC's available CPUs, there by reducing the available CPUs at the parent AVMC level. As you create more ACDs and provision Autonomous Databases within each ACD, the available CPU value changes accordingly.

Available CPUs at the Autonomous Exadata VM Cluster level applies to all its Autonomous Container Databases. This count of CPUs available to the container database becomes important if you are using the auto-scaling feature, as described in CPU Allocation When Auto-Scaling.

Similarly, when you manually scale the CPUs of an Autonomous Database up, CPUs are consumed from the available CPUs at its parent AVMC level and its value changes accordingly.

When you create an Autonomous Database, by default Oracle reserves additional CPUs to ensure that the database can run with at least 50% capacity even in case of any node failures. You can change the percentage of CPUs reserved across nodes to 0% or 25% while provisioning an ACD. See Create an Autonomous Container Database for instructions. These additional CPUs are not included in the billing.

When an Autonomous Database is running, you are billed for the number of CPUs currently allocated to the database, whether specified at initial creation or later by a manual scaling operation. Additionally, if auto-scaling is enabled for the database, you are billed for each second for any additional CPUs the database is using as the result of being automatically scaled up. See CPU Billing Details for more information about how billing is measured and computed.

When an Autonomous Database is stopped, you are not billed. However, the number of CPUs allocated to it are not returned to the available CPUs at its parent AVMC level for the overall deployment.

When an Autonomous Database is terminated or scaled down, the number of CPUs allocated to it are not immediately returned to the available CPUs at its parent AVMC level for the overall deployment. They continue to be included in the count of CPUs available to its parent container database until that parent container database is restarted. These CPUs are called reclaimable CPUs. Reclaimable CPUs at the parent AVMC level is the sum of reclaimable CPUs of all its ACDs. When an ACD is restarted, it returns all its reclaimable CPUs to the available CPUs at its parent AVMC level.

Restarting an Autonomous Container Database (ACD) is an online operation, done in a rolling manner across the cluster, and will not result in application downtime if configured according to best practices to use Transparent Application Continuity.

An elastic pool allows you to consolidate your Autonomous Database instances in terms of their compute resource billing.

You can think of an elastic pool like a mobile phone service "family plan," except this applies to your Autonomous Database instances. Instead of paying individually for each database, the databases are grouped into a pool in which one instance, the leader, is charged for the compute usage associated with the entire pool. See Consolidate Autonomous Database Instances Using Elastic Resource Pools for complete details about elastic resource pools.

Elastic resource pool usage:

• Is billed to the pool leader, and billing is based on the elastic resource pool size and the actual hourly ECPU usage of the pool leader and the members.
• Can exceed the pool size (pool capacity can be up to four times greater than the pool size).
• Billing consists of only compute resources, that is, ECPU usage, and all compute usage is charged to the Autonomous Database instance that is the pool leader.

Using an elastic pool, you can provision up to four times the number of ECPUs over your selected pool size, and you can provision database instances that are in the elastic pool with as little as 1 ECPU per database instance. Outside of an elastic pool the minimum number of ECPUs per database instance is 2 ECPUs. For example, with a pool size of 128, you can provision 512 Autonomous Database instances (when each instance has 1 ECPU). In this example, you are billed for the pool size compute resources, based on the pool size of 128 ECPUs, while you have access to 512 Autonomous Database instances. In contrast, when you individually provision 512 Autonomous Database instances without using an elastic pool, you must allocate a minimum of 2 ECPUs for each Autonomous Database instance. In this example, you would pay for 1024 ECPUs. Using an elastic pool provides up to 87% compute cost savings.

After creating an elastic pool, the total ECPU usage for a given hour is charged to the Autonomous Database instance, that is the pool leader. Except for the pool leader, individual Autonomous Database instances that are pool members are not charged for ECPU usage while they are members of an elastic pool.

Elastic pool billing is as follows:

• If the total aggregated peak ECPU utilization is equal to or below the pool size for a given hour, you are charged for the pool size number of ECPUs (one times the pool size).
• After an elastic pool is created, ECPU billing continues at a minimum of one-time the pool size rate, even when pool member databases and the pool leader are stopped.
• In other words, if the aggregated peak ECPU utilization of the pool is less than or equal to the pool size for a given hour, you are charged for the pool size number of ECPUs (one times the pool size). This represents up to 87% compute cost savings over the case in which these databases are billed separately without using elastic pools.
• If the aggregated peak ECPU utilization of the pool leader and the members exceeds the pool size at any point in time in a given billing hour:
  • Aggregated peak ECPU utilization of the pool is equal to or less than two times the pool size number of ECPUs: For usage that is greater than one times the pool size number of ECPUs and up to and including two times the number of ECPUs in a given billing hour: Hourly billing is two times the pool size number of ECPUs.
  • In other words, if the aggregated peak ECPU utilization of the pool exceeds the pool size but is less than or equal to two times the pool size for a given hour, you are charged twice the pool size number of ECPUs (two times the pool size). This represents up to 75% compute cost savings over the case in which these databases are billed separately without using elastic pools.
  • Aggregated peak ECPU utilization of the pool is equal to or less than four times the pool size number of ECPUs: For usage that is greater than two times the pool size number of ECPUs and up and including to four times the pool size number of ECPUs in a given billing hour, hourly billing is four times the pool size number of ECPUs.
  • In other words, if the aggregated peak ECPU utilization of the pool exceeds twice the pool size for a given hour, you are charged for four times the pool size number of ECPUs (four times the pool size). This represents up to 50% compute cost savings over the case in which these databases are billed separately without using elastic pools.
• For example, consider an elastic pool with a pool size of 128 ECPUs and a pool capacity of 512 ECPUs:
  • Case-1: The aggregated peak ECPU utilization of the pool leader and the members is 40 ECPUs between 2:00 pm and 2:30 pm and 128 ECPUs between 2:30 pm and 3:00 pm.
  • The elastic pool is billed 128 ECPUs, one-time the pool size, for this billing hour (2–3 pm). This case applies when the peak aggregated ECPU usage of the elastic pool for the billing hour is less than or equal to 128 ECPUs.
  • Case 2: The aggregated peak ECPU utilization of the pool leader and the members is 40 ECPUs between 2:00 pm and 2:30 pm and 250 ECPUs between 2:30 pm and 3:00 pm.
  • The elastic pool is billed 256 ECPUs twice the pool size for this billing hour (2–3 pm). This case applies when the peak aggregated ECPU usage of the elastic pool for the billing hour is less than or equal to 256 ECPUs and greater than 128 ECPUs.
  • Case-3: The aggregated peak ECPU utilization of the pool leader and the members is 80 ECPUs between 2:00 pm and 2:30 pm, and 509 ECPUs between 2:30 pm and 3:00 pm.
  • The elastic pool is billed 512 ECPUs, four times the pool size, for this billing hour (2–3 pm). This case applies when the peak aggregated ECPU usage of the elastic pool for the billing hour is less than or equal to 512 ECPUs and greater than 256 ECPUs.

For more details, see How to Achieve up to 87% Compute Cost Savings with Elastic Resource Pools on an Autonomous Database.