Oracle Cloud Infrastructure Documentation

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.

About Elastic Pools

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.

Benefits of Using Elastic Pools

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.

Requirements to Create an Elastic Pool

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.
  • 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.

Requirements to Join an 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.
  • 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.

Pool Leader and Member Instance ECPU Allocation

When an Autonomous Database instance is part of an elastic pool:

  • The minimum allowed individual ECPU allocation for an instance is 1 ECPU.

  • Increments of 1 ECPU are allowed for individual Autonomous Database instance ECPU allocation.

Pool Capacity for an 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.

Note

These examples do not consider Autonomous Data Guard enabled leader or members. See Autonomous Data Guard Standby Database Billing in Elastic Pools for information on using elastic pools with Autonomous Data Guard.

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.

Elastic Pool Leader Operations

The Autonomous Database instance that creates an elastic pool is the pool leader.

The following operations are valid only for the pool leader:
Operation Description
Create an elastic pool.

The Autonomous Database instance that creates an elastic pool is the pool leader.

When an Autonomous Database with Autonomous Data Guard configuration is used to create an elastic pool, its standby database is automatically added to the same elastic pool.

See Create an Elastic Pool for more information.

Remove an elastic pool member.

An elastic pool leader can remove a member from the elastic pool.

When an Autonomous Database with Autonomous Data Guard configuration is removed from an elastic pool, its standby database is automatically removed, and its ECPU allocations are returned to the pool.

See Remove Pool Members from an Elastic Pool for more information.

Terminate an elastic pool. When an elastic pool has no pool members, the pool leader can terminate the elastic pool. See Terminate an Elastic Pool for more information.
Modify elastic pool size. An elastic pool leader can modify the pool size. See Change the Elastic Pool Shape for more information.
List elastic pool members. A pool leader can list pool members. See List Elastic Pool Members for more information.

Elastic Pool Member Operations

The Autonomous Database instance that are added to an existing pool are pool members.

The following operations are valid only for a pool member or a pool leader:
Operation Description
Join an elastic pool.
  • You can addan Autonomous Database instance to an elastic pool as a member only when:
    • There are sufficient ECPUs remaining in the pool for allocation (4x the Pool Size ).
    • The instance is one of the supported workload types, that is, Transaction Processing or Data Warehouse.
    • Its compute model is ECPU.
    • It is not already a member of a different pool.
  • When an Autonomous Database with Autonomous Data Guard configuration joins an elastic pool, its standby database is automatically added to the same elastic pool.
  • When you perform an Add standby operation on an Autonomous Container Database (ACD), all the Autonomous Databases in that ACD that are part of an elastic pool will also have their new standby databases added to their respective pools. In this process, if any pool does not have enough free ECPUs to accommodate the standby database(s), the Add standby ACD operation fails.

See Join an Elastic Pool and Join an Elastic Pool While Provisioning or Cloning an Autonomous Database for guidance.

Leave an elastic pool. 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.
  • When an Autonomous Database with a standby database leaves an elastic pool, both the primary and standby databases will be removed, and their ECPU allocations will be returned to the pool.

See Leave an Elastic Pool Autonomous Database for instructions.