Sizing Exadata Cloud Service

Sizing Exadata Cloud Service is where most of the long term cost and performance of the platform is decided, and it is the step organisations most often rush. Exadata is unusual among database platforms because its sizing splits into two separate questions that are easy to conflate: how large an infrastructure to provision, and how many compute cores to enable on it. Confusing the two leads either to a costly migration later or to paying for capacity that sits idle. This article sets out a disciplined method for both decisions.

For the wider picture of what Exadata is and when it fits, see our complete guide to Exadata Cloud Service. Here we focus on getting the size right.

The two questions of Exadata sizing

The first question is the infrastructure: the engineered system itself, defined by the number of database servers and storage servers on current elastic configurations. This decision is driven by two things, the storage capacity your databases need now and over a realistic horizon, and the ceiling of compute you might ever want to enable. Getting the infrastructure wrong is expensive because growing it later can mean a migration to a larger system. The second question is the enabled cores, which is how much compute you actually turn on and pay for at any moment. This is driven purely by current workload, and on current generations it can be scaled up and down online, so it is far more forgiving than the infrastructure decision.

Sizing the infrastructure

Start from data, not from compute. Measure the total size of the databases you intend to run, add realistic growth over the period you are planning for, and account for the overhead of redundancy, backups held on the system, and any consolidation you intend to do. Storage capacity usually sets the floor for how many storage servers you need. Then consider the compute ceiling: what is the maximum number of cores you could plausibly want to enable at peak over the life of the system? You provision an infrastructure whose maximum enabled cores comfortably exceeds that, so you have headroom to scale into without a migration. The art is leaving enough headroom to grow without provisioning a vastly oversized system whose infrastructure charge you pay regardless of how few cores you enable.

Sizing the enabled cores

Enabled cores are the lever you pull for current performance and current cost. The right number comes from understanding your workload: its CPU demand at peak, its concurrency, and whether the demand is steady or spiky. A steady transactional workload wants enough cores to handle its peak comfortably with some margin. A workload with sharp peaks and long troughs is a candidate for scaling cores up for the peak window and back down afterward, which on current generations is an online operation. The mistake to avoid is enabling cores for the highest peak you will ever see and leaving them pinned there permanently, which means paying for peak capacity twenty four hours a day to serve a peak that lasts two hours.

A sizing framework

Consolidation changes the sizing arithmetic

If you are sizing for a consolidation of many existing databases, the sizing is not the sum of their individual sizings, because their peaks rarely coincide. The whole point of consolidation is that databases share capacity, so the platform can be sized for the aggregate peak rather than the sum of individual peaks, which is almost always far smaller. This is where Exadata sizing can deliver dramatic savings, and where naive sizing that simply adds up the source systems overshoots badly. We cover the consolidation case in consolidating databases on ExaCS, and the related cost picture in cost of Exadata Cloud Service.

Growing the platform later

Sizing is not a one off event, because workloads grow and consolidations expand. The good news is that enabled cores scale online, so day to day growth is handled by turning on more cores within the infrastructure you have. The harder case is when you approach the infrastructure ceiling and need a larger engineered system, which is why the original infrastructure decision matters so much. We cover the mechanics of growth, including when to scale cores and when to grow the infrastructure, in scaling Exadata Cloud Service. And because performance depends on whether the workload exploits Exadata features, sizing should be validated against the performance behaviour described in Exadata Cloud Service performance.

Getting sizing right is worth the effort

Because Exadata is expensive and the infrastructure decision is hard to reverse, the analysis that goes into sizing pays for itself many times over. An oversized infrastructure carries a recurring charge for capacity you will never use, and an undersized one forces a disruptive migration. Enabled cores left at peak waste money every hour. The discipline of sizing the infrastructure for storage and ceiling, sizing enabled cores for today, and reviewing both regularly is what keeps Exadata economical. This sizing work is part of our implementation and migration practice, and the ongoing core trimming is part of our cost optimization practice. If you are sizing an Exadata platform and want the analysis done properly before you commit, an assessment is the right starting point.