About Elastic Pools

Elastic pools offer the following advantages:

• Operate within a fixed budget across a group of databases while delivering performance elasticity for each individual database.

• Migrate easily from on-premises Oracle environments that use oversubscription, to provide a cost-effective pathway to the Autonomous AI Database.

• Support SaaS vendors managing a large number of individual customer databases.

• Facilitate the use of microservices architecture when numerous databases are required.

• Pool members in an elastic pool are not billed individually. Instead, billing is applied to the pool leader based on the pool shape. This approach enables you to allocate additional ECPUs per instance to pool members without concern for the ECPU usage costs of individual members.

• In Autonomous AI Database, I/O capacity and memory allocation are directly correlated with the ECPU count. By assigning a greater number of ECPUs to an instance, you can benefit from increased I/O capacity and more memory without incurring additional resource charges. Since the cost is determined by the pool shape rather than the ECPU count of each instance, you can take advantage of higher I/O capacity and memory per instance within the same pricing structure.

Starting and stopping pool members does not depend on the state of the leader. That is, you can independently stop and start each instance that is part of an elastic pool, including the leader and members of the elastic pool that are not the leader.

An elastic pool is a logical construct that imposes no physical constraints on its members. The pool leader and pool members do not need to reside on the same infrastructure. However, you can create an elastic pool with all pool members and the pool leader located in the same infrastructure. These are called Dedicated Elastic Pools, and they offer additional options, including custom scaling for compute and storage, enhanced database consolidation and governance, simplified billing, and improved control over patching. See About Dedicated Elastic Pools for more details.

If your organization uses Oracle Cloud Infrastructure (OCI) parent and child tenancy model as described in Organization Management Overview, you can achieve elastic pool cost savings by creating an elastic pool that spans both parent and child tenancies. In this configuration, the elastic pool leader is in the parent tenancy and the pool members are in child tenancies. See Elastic Pools Across Parent and Child Tenancies for more details.

To create an elastic pool and become a pool leader, an Autonomous AI Database instance must:

• Use the ECPU compute model.

• Have compute auto-scaling disabled.

• Not be a member of an existing elastic pool.

• Have a sufficient number of ECPUs available, below the tenancy limit, to accommodate the elastic pool's size.

• Provisioning a pool leader is subject to service limits enforced at the tenancy level.

The maximum allowed individual ECPU count for an Autonomous AI Database instance that creates an elastic pool is four (4) times the pool size specified while creating the pool.

To join an elastic pool, an Autonomous AI Database instance must:

• Use the ECPU compute model.

• Have compute auto-scaling disabled.

• Not be a member of an elastic pool.

• Have an ECPU count below the available pool capacity.

• Provisioning a pool member is subject to the available pool capacity.

The grouping of resources and billing for an elastic pool consists of only compute resources, that is ECPU usage, and all compute usage is charged to the Autonomous AI Database instance that is the elastic pool leader. Any storage related resource allocation and billing for storage usage is charged separately to individual Autonomous AI Database instances, independent of whether the instance is in an elastic pool. Autonomous AI Database bills all compute usage for an elastic pool to the pool leader at the Transaction Processing compute usage rate, regardless of whether the elastic pool leader uses the Transaction Processing, Lakehouse, JSON, or APEX workload type. See Autonomous AI Database Serverless Billing for Elastic Pools and ECPU Compute Model Billing Information for more information.

However, in dedicated elastic pools, resource grouping and billing include both compute (ECPU usage) and storage resources. The total resource consumption is charged to the pool leader. See About Autonomous AI Database Dedicated Elastic Pool Billing for details.

An Autonomous Data Guard primary database can use a local or a cross-region standby that is part of an elastic pool, either as a leader or a member. Elastic pool billing varies depending on whether the pool leader or any member is associated with Autonomous Data Guard or not. See About Billing Autonomous AI Database Elastic Pools with Autonomous Data Guard for more information.

An elastic pool has a pool capacity of 4 times the pool size. For example, a pool with pool size of 128 ECPUs can hold up to 512 ECPUs for its leader and the members.

The following are examples of Autonomous AI Database instances that could be in an elastic pool with a pool size of 128 and a pool capacity of 512:

• Each of these are valid for pool members in an elastic pool with a pool size of 128:

  • 1 instance with 512 ECPUs, for a total of 512 ECPUs

  • 128 instances with 4 ECPUs, for a total of 512 ECPUs

  • 256 instances with 2 ECPUs, for a total of 512 ECPUs

  • 50 instances with 10 ECPUs and 3 instances with 4 ECPUs, for a total of 512 ECPUs

• Similarly, each of the following are valid for pool members in an elastic pool with a pool size of 128:

  • 1 instance with 128 ECPUs, 2 instances with 64 ECPUs, 32 instances with 4 ECPUs, and 64 instances with 2 ECPUs, for a total of 512 ECPUs

  • 256 instances with 1 ECPU, 64 instances with 2 ECPUs, for a total of 384 ECPUs, which is less than the pool capacity of 512 ECPUs.

  • 100 instances with 4 ECPUs and 50 instances with 2 ECPUs, which is less than the pool capacity of 512 ECPUs.

These are examples, you can add pool members to a pool to match the number of instances and the number ECPUs per instance to meet your needs, based on the pool size you select.

In an elastic pool, the pool leader's licensing selections determine the license requirements for the entire pool. If you want to use BYOL for an elastic pool and set a BYOL License Limit, you must set the limit value on the pool leader's instance. The license selections for pool members, including any BYOL License Limit do not apply while an instance is a member of a pool. The license selections, including any BYOL License Limit, come into effect only if a pool member or the pool leader leaves the elastic pool. For example, if an elastic pool includes a member instance that uses Autonomous Data Guard with an 8 ECPU primary with the BYOL license type set, the primary and standby instance's licensing selection is set as follows:

• When the primary is a pool member, the license type of the primary can be set but it is does not apply for the primary; the primary uses the license type of the elastic pool leader. The license type selection on the primary will apply when and if the primary leaves the elastic pool.

• For a local standby, the standby instance is in the elastic pool. In this case, the local standby uses the same license type as the primary.

• For a cross-region standby, the standby instance is either in the pool (as a pool member or as the pool leader), or is not in the elastic pool, as follows:

  • When a cross-region standby is not in the elastic pool, that is it is not either the pool leader or a pool member, then the cross-region standby license type can be set but it is does not apply; the standby uses the license type of the elastic pool leader. The license type selection on the standby will apply when and if the standby leaves the elastic pool.

  • When a cross-region standby is not in the elastic pool, that is it is not either the pool leader or a pool member, then the cross-region standby license type can be set but it is does not apply; the standby uses the license type of the elastic pool leader. The license type selection on the standby will apply when and if the standby leaves the elastic pool.

  • When a cross-region standby is not in the elastic pool, that is it is not either the pool leader or a pool member, then the cross-region standby license type can be set but it is does not apply; the standby uses the license type of the elastic pool leader. The license type selection on the standby will apply when and if the standby leaves the elastic pool.

By default, each instance in an elastic pool is automatically assigned a maintenance window. By selecting a pool shape that is 1024 ECPUs or greater, you have the option of assigning a custom 2-hour maintenance window during which the leader and all elastic pool members are patched together. To select a custom maintenance window for your elastic pool, file a Service Request at Oracle Cloud Support.

When you create an elastic pool in Autonomous AI Database, your instance becomes the pool leader. Instances that you add to an existing pool become pool members. The operations you can perform depend on your role as a leader or member.

You can perform the following operations only as the pool leader:

Both pool members and the pool leader can perform these operations: