Consolidate Autonomous Database Instances Using Elastic Pools
Use an elastic pool to consolidate your Autonomous Database instances, in terms of their allocation of compute resources, and to provide up to 87% cost savings.
Elastic pools help you improve operating efficiency and reduce costs by bringing all of your databases to the Cloud. This also supports consolidating resources and simplifying administration and operations by using Autonomous Database. When you need a large number of databases, that can scale up and down elastically without downtime, you can benefit by creating and using elastic pools.
When you create an elastic pool you select a pool size from a predefined set of pool sizes. Pool size determines how much you pay for compute as well as how many ECPUs you can provision in a given pool.
Note
Elastic pools are only available for Autonomous Database instances that use the ECPU compute model without Autonomous Data Guard.
There are several terms to use when you work with elastic pools:
Pool Leader: The Autonomous Database instance that creates an elastic pool.
Pool Member: An Autonomous Database instance that is added to an elastic pool.
Pool Size: A value you set when creating an elastic pool. The pool size must be one of the available elastic pool shapes.
Pool Shape: When you create an elastic pool, you select a pool shape from among the valid pool sizes. The shape must have one of 128, 256, 512, 1024, 2048, or 4096 ECPUs.
Pool Capacity: The maximum number of ECPUs that an elastic pool can use. It is four times (x4) the pool size.
The following apply with elastic pools:
Provisioning a pool leader or a member is subject to service limits enforced at the tenancy or compartment levels.
Starting and stopping a pool member database does not depend on the pool leader's state. You can independently stop and start the databases part of an elastic pool, including the pool leader and members.
In an elastic pool, the pool leader's licensing selections determine the license requirements for the entire pool. That is, as long as an Autonomous Database is a member of an elastic pool, its license selections do not apply, and they come into effect only after it leaves the elastic pool.
Elastic pools provide the following benefits. They:
Enable operating with a fixed budget for a group of databases while delivering performance elasticity for each individual database.
Allow for easy migration from on-premise Oracle environments that include oversubscription to provide a cost-effective way to move to an Autonomous Database.
Support SaaS vendors with a large number of individual customer databases.
Provide resources for using a microservices architecture, where the ability to supply a large number of databases is required.
The pool members in an elastic pool are not billed individually (the pool leader is billed based on the pool shape). You can allocate additional ECPUs per instance for pool members without worrying about the cost associated with the ECPU usage for the individual members.
Autonomous Database memory allocation is directly correlated with the ECPU count, so selecting a greater number of ECPUs for instance allows you to run with more memory without paying for the additional resources. This means using a larger number of ECPUs per instance will enable you to use more memory per instance, where the cost is based on the pool shape and not on an individual instance's ECPU count.
The following are the requirements for an Autonomous Database instance to create an elastic pool and become a pool leader:
The instance must use the ECPU compute model without Autonomous Data Guard.
The instance must be an Autonomous Database with Autonomous Transaction Processing workload type. This only applies to the pool leader. An elastic pool can hold a mix of databases with Autonomous Transaction Processing and Autonomous Data Warehouse workloads.
Auto scaling must be disabled.
The instance must not be a member of an existing elastic pool.
The maximum allowed individual ECPU count for an Autonomous Database instance that creates an elastic pool is 4 times the pool size specified when you create the pool.
The instance that creates an elastic pool is subject to tenancy limits. To create an elastic pool, you must have a sufficient number of ECPUs available, below the tenancy limit, to accommodate the size of the elastic pool.
The following are the requirements for an Autonomous Database instance to join an elastic pool:
The instance must use the ECPU compute model without Autonomous Data Guard.
An elastic pool can contain Autonomous Database instances with Autonomous Transaction Processing and Autonomous Data Warehouse workload types.
Auto scaling must be disabled.
The instance must not be a member of an existing elastic pool.
The available pool capacity is the maximum allowed individual ECPU count for an Autonomous Database instance. When an instance's ECPU count is greater than the available pool capacity, it is not allowed to join that elastic pool.
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 Database instances that could be in an elastic pool with a pool size of 128 and a pool capacity of 512 ECPUs:
Each of these are valid for pool members in an elastic pool with a pool size of 128 ECPUs:
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
Similarly, each of the following are valid for pool members in an elastic pool with a pool size of 128 ECPUs:
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.
As a pool member, you can remove your instance from an elastic pool.
When a pool member leaves an elastic pool:
Auto-scaling is disabled. After leaving the elastic pool, you can enable auto-scaling for the instance.
The pool will have more resources available. For example, if the elastic pool were fully allocated up to the pool capacity, and an instance with 10 ECPUs leaves the pool, the elastic pool would have 10 available ECPUs.