Simplifying Database Consolidation with Elastic Pools
My buddy Tony Politano recently posted this article on the Oracle Database Insider blog. Tony is an expert on all things related to databases and consolidation. It’s an interesting case study — so, I’m adding it here as well.
Database consolidation is a time-tested practice that lowers the total cost of ownership (TCO) for database estates and simplifies database operations. Traditionally, consolidation requires physically moving databases to a consolidated or shared platform. A physically consolidated platform fits more databases into less infrastructure, which saves costs by having less infrastructure to acquire, manage, patch, and upgrade. Oracle Autonomous Database Elastic Pools (elastic pools) is a new innovative way to achieve consolidation financial and operational benefits without physically consolidating databases. Databases can be easily added to elastic pools and, if needed, can just as easily be moved out of an elastic pool.
Let’s look at an estate of 500 Oracle RAC and non-RAC databases running on a combination of VMs and dedicated Linux servers with database versions ranging from 12c to 19c. With a target environment of Oracle Autonomous Database, we see up to 49% TCO savings. To confirm the technical feasibility and financial benefits of moving to Autonomous Database, we selected 135 databases running on the equivalent of 2,850 VCPUs with 87 TB of database storage. The selected databases ranged from the equivalent of 1 to 128 VCPUs, with a mean database VCPU size of 21 and a median database size of 16 VCPUs.
Using Oracle Estate Explorer, a free tool from Oracle that evaluates current database estates and their suitability for Oracle Autonomous Database, allowed us to examine multiple migration scenarios. Let’s focus on two of these scenarios. First, by targeting Oracle Autonomous Database Serverless with Autoscaling, we could anticipate a yearly TCO savings of 35% compared to continuing with on-premises VMs. Second, targeting Oracle Autonomous Database Serverless with Elastic Pools, the overall TCO savings increased to 49% vs. continuing with on-premises VMs. This additional savings is because elastic pools handle many databases of different sizes with varying workloads at an overall lower cost. Elastic pools provide a way for each database to get its required portion of the elastic pool database resources while still providing the 4X capacity if needed and alleviating operations from having to micromanage the starting and stopping of each database. These first 135 databases give a realistic view of moving a part of the estate. They can form the basis for a phased migration approach of all 500 databases to Oracle Autonomous Database.
To better understand the power of elastic pools, let’s compare traditional consolidation methodology with an elastic pool based consolidation methodology.
Traditional consolidation
Organizations have been deploying database consolidation platforms for years as a best practice. Consolidation can reduce infrastructure and operational costs by moving away from one-off dedicated servers and storage devices for each database. The generally accepted practice is to size and migrate multiple separate databases to a shared platform. This type of consolidation requires understanding and architecting a database platform that can coexist and still meet individual service-level agreements. Some organizations use virtualization technologies to consolidate, but they still need a deep understanding and must spend effort designing an optimized virtualized environment.
For example, you may have 100 databases on 40 distinct servers, some using shared storage and some using dedicated storage. Consolidating these 100 databases to Oracle Exadata may allow you to run all the databases on an Exadata X9, allowing workloads with different performance profiles (e.g., high memory, high throughput) to maximize the compute and storage capabilities. This consolidated platform enables you to enjoy the financial benefit of lower TCO with more databases coexisting on the same infrastructure. With less infrastructure to acquire and maintain, the average cost per database will be lower. Additionally, operations are usually simplified by managing a single Exadata environment containing many databases instead of managing many different servers and storage.
Best of both worlds with Elastic Pools
Elastic pools are a new capability in Oracle Autonomous Database that provides the financial benefits of consolidation without requiring you to design a physical consolidation platform. Elastic pools work with existing Autonomous Databases or newly migrated databases to Autonomous Database. By adding databases to an elastic pool, you are utilizing ECPUs, whose cost is shared across all databases in the elastic pool. The elastic pool utilization is an aggregate utilization of the total ECPUs used in a specific time period (e.g., hourly). The financial benefits of elastic pools can be almost immediate as elastic pools do not require any physical movement or relocation of databases; it is just a change to add to an elastic pool for billing purposes.
Adding databases to an elastic pool does not require database design or architecture changes beyond having the databases run as Autonomous Databases. If the database runs on Autonomous Database Serverless, it is already running on a managed Exadata platform and is eligible to run in an elastic pool. Elastic pools simplify management by shifting billing to a single pool instead of database-by-database billing, giving the financial benefits of consolidation without moving any database physically. You can quickly move databases in or out of an elastic pool with a single console operation, API call, or automation scripts.
Previously, development, test, and production databases had to be both physically and financially separated to get the financial benefits of consolidation. This was because the financial benefit of consolidation was tied to physical consolidation, whether co-locating in hosts, racks, or sets of servers, and many organizations try to keep development and production physically separated. With elastic pools, you can now get the financial benefit of combining the billing and utilization of critical production, test, and noncritical lower environments without moving them to the same rack or frame. Your databases remain separated, but from a billing perspective, you get the benefits of elastic pooling, which drives down overall TCO per database.
From an operations perspective, elastic pools are especially beneficial for databases that may be idle for extended periods or have variable workloads subject to high short processing spikes. Only the database’s actual utilization is counted toward the elastic pool during that time period, and shutting down databases in elastic pools is optional, simplifying data lifecycle operations.
Since elastic pools allow up to 4X the pool size for scaling workloads, you get capacity for spikes in workloads and periodic heavy processing times by having an available capacity that elastic pools can automatically handle. Elastic pools are available in 128, 256, 512, 1024, 2048 and 4096 ECPU shapes. Each shape includes up to 4X capacity if needed (e.g., 256 shape has a pool capacity of up to 1024 ECPUs). This 4X added pool capacity also does not require any changes to the database or physical consolidation. It is automatically available when you set up the database’s capacity in an elastic pool.
Summary
Elastic Pools are an innovative and straightforward way to achieve the financial benefits of database consolidation. You still have the option of physically consolidating specific databases to Exadata, Exadata Cloud @ Customer, or Exadata Cloud Service. However, this new option of Elastic Pools for databases running on Autonomous Database provides the financial benefits of consolidation without having to consolidate databases physically. To learn more about elastic pools, visit Using Elastic Pools. To learn more about Oracle Estate Explorer for evaluating your existing Oracle estate, visit Oracle Estate Explorer.
