Blog

You are dying to get a reservation at that hot new restaurant for you and another couple. You get a tip that a table may be available for this weekend. Since you want to keep the spot, you call them and make the reservation for a table of 4, then try to track down your friends.

Saturday comes around, and your friends still have not committed, so you head to the restaurant anyway. They seat the 2 of you at a table of 4, and your friends never show. Afraid the restaurant will charge you for no-show friends, you are pleasantly surprised to pay for the meal for the two even though you had a lovely big table ready for 4.

Autonomous Database Elastic Pools

Similarly, Autonomous Database Elastic Pools (Elastic Pools) allow you to plan for what you could use but only pay for what you actually do use in terms of ECPUs. You choose a set pool of ECPUs (e.g., 128, 256, 512,1024, 2048, 4096) but can use up to 4X that amount of ECPU (e.g., 4 * 128 = 512, 4* 256 = 1024) when needed. Because you have allocated the required space in the pool for each database when it needs to expand to that size, the capacity is there for you, but you only pay based on the pool utilization each hour. Elastic Pools also give you finer-grained controls via ECPUs with any database in the pool since Elastic Pools only require a minimum of 1 ECPU instead of the standard 2 ECPU for non-pooled databases. For further explanation of the benefits of ECPU, see the Autonomous Database ECPU FAQ.

Development and Test Environments

Your development and test environments are probably notorious for having resources that are either overallocated or have resources sitting idle. Idle and overallocated resources contradict the benefits of running in the cloud. I worked with a financial services customer that runs 11 non-production databases for every major application. All these environments, though, are not required to be fully on all the time. This is the situation where the elasticity of the cloud starts to pay off. With hundreds of applications spawning many different non-production copies, the chance of you having idle or overallocated databases is high if not properly managed.
Autonomous Database Autoscaling and scheduled startup and stops can help you at a database level by controlling the minimum ECPUs and shutting them down when they are not in use. Although this will help to cut down on unused asset costs, it does not take advantage of the economies of scale with a large amount of highly transitory databases you find in development.
Moving your development databases to an Elastic Pool minimizes or eliminates the time and effort to manage resources for transitory databases, which may start and stop multiple times per sprint. The Elastic Pool allows you to manage resources at a pool level with databases able to consume what they need and then release those resources back to other development databases without administrator intervention.

Example

Assume you have a shared development environment for 50 applications with five development/test environments each. Development may use these databases for a single sprint or less, but they must be sufficiently sized when in use and able to start up on demand without administrative wait time.

Configuring with Autoscaling

Using an Autoscaling Autonomous Database, you would also have to start and stop each database and individually manage each database.

• With 50 Applications * 5 environments = 250 possible databases
• In a non-pooled environment, you could start with a 2 ECPU with autoscaling up to 3X the initial size for each database.

Configuring with Elastic Pools

If you run this in an Elastic Pool, you can improve your efficiency further and get more resources and finer-grained controls.

• The first benefit is that each database minimum is 1 ECPU
• Some of these databases could be allocated to as low as 1 ECPU, while you may allocate test databases to a higher capacity.
• As long as you stay below the 512 (4X of 128) pool capacity of a 128 ECPU Elastic Pool, you would only need a 128 ECPU Elastic Pool.
• If a database only uses 1 ECPU but suddenly needs more capacity, it would have up to the allocated amount ready, which you should reflect in the allocation level. Elastic Pools immediately release those extra ECPUs to the pool when the workload scales back down.

Development High Peak Use Case

In the rare case that all 250 databases ran at low usage during a peak hour, in an autoscaling configuration, you would consume 250 databases at 2 EPCU each = 500 ECPU for that hour. Elastic Pools would handle this differently by scaling the Elastic Pool to meet the concurrent databases. At 250 databases with a minimum of 1 ECPU, this is half of the autoscale usage, and you could handle with a 256 ECPU Elastic Pool for that hour and scale back to 128 as the demand drops. The result is nearly halving the cost of development ECPUs for that hour.

Idle Development Database Use Case

If databases are used but left idle and not shut down, they will continue to be billed at the minimum ECPU in an autoscaling configuration. Databases in an Elastic Pool will consume the ECPUs in the Elastic Pool only when utilized. For example, 20% of the 250 development databases, each with a minimum configuration of 2 ECPUs, are left running by mistake. In an autoscaling configuration, this would be 25 databases * 2 ECPU, or 50 ECPU consumption for every hour they are left on. In Elastic Pools, unless you are utilizing these databases, they will not consume ECPUs from the pool, resulting in a savings of the cost of up to 50 ECPUs.

Conclusion

Autoscaling is a way to manage your capacity for individual databases. Elastic Pools takes this further by providing an innovative way to consolidate your database environment by simplifying Autonomous Databases’ overall management and capacity planning across large estates of development databases. By understanding and using the concept of 4X capacity and allocating databases properly, you can put a pool in place that will lower overall costs and ensure the capacity is there when needed. The development environment is one of many use cases in which Elastic Pools can simplify and cut costs in a modern database estate. To learn more about Elastic Pools, see Use and Manage Elastic Pools on Autonomous Database.