Scaling Exadata Cloud Service

One of the most useful properties of Exadata Cloud Service is that it scales without the disruption that scaling traditional database hardware used to require. On current generations you can add compute cores online, grow storage, and even expand the underlying infrastructure, with the database staying available throughout most of these operations. Used well, this elasticity lets you size for today and grow into tomorrow without overprovisioning. Used poorly, it becomes a ratchet that only ever clicks upward. This article explains how Exadata scaling works and how to use it economically.

For the wider picture, see our complete guide to Exadata Cloud Service, and for the initial sizing that scaling builds on, sizing Exadata Cloud Service.

The layers you can scale

Exadata scaling happens at three distinct layers, and confusing them leads to poor decisions. The first and most flexible is enabled compute cores, which you can increase or decrease online within the infrastructure you have provisioned. This is the lever for matching compute to changing workload, and it is fast and reversible. The second is storage, which grows by adding capacity within the infrastructure. The third and least flexible is the infrastructure itself, the engineered system, which on elastic configurations can be expanded by adding servers but which has a ceiling, beyond which growth means moving to a larger system. The art of scaling Exadata is to do as much as possible at the flexible core layer and to size the infrastructure so you rarely hit its ceiling.

Scaling cores: the everyday lever

Enabling and disabling cores is the operation you should reach for most often, because it is online and reversible. A workload that grows steadily gets more cores as it needs them. A workload with a predictable daily or seasonal peak can have cores scaled up for the peak window and back down afterward, so you pay for peak capacity only during the peak. This rhythm, scaling up for demand and down for quiet, is where Exadata's elasticity translates directly into cost savings, and it is the discipline most estates neglect. Many enable cores for the highest peak they will ever see and leave them pinned there, paying for peak capacity around the clock. We cover the cost implications in cost of Exadata Cloud Service.

Scaling storage

Storage growth is driven by data, and on current generations it can usually be added online within the infrastructure. The key is to monitor capacity against growth so that expansion is planned rather than forced by running out. Storage also interacts with performance, because the storage servers do the offload work, so adding storage capacity can also add offload capacity. Planning storage growth alongside the data growth projections from your sizing exercise keeps the platform ahead of demand without provisioning years of unused capacity up front.

Scaling the infrastructure

The infrastructure is the layer you want to scale least often, because it is the largest operation and the one that, at its limit, forces a move to a bigger system. This is precisely why the original infrastructure sizing matters so much: provisioning enough ceiling that core and storage scaling handle ordinary growth means you rarely touch the infrastructure. When you do approach the ceiling, the expansion needs careful planning, and if you have genuinely outgrown the infrastructure, the move to a larger system is a migration with the effort and risk that implies. The lesson is to size the infrastructure generously enough at the outset that you grow into it through the flexible layers rather than repeatedly rebuilding the foundation.

A scaling framework

The discipline that makes elasticity pay

Exadata's elasticity is only valuable if it works in both directions. Scaling up to meet demand is easy because the pressure to do it is obvious. Scaling down when demand falls is the discipline almost everyone neglects, because nothing breaks when you leave cores enabled, the only consequence is a quietly larger bill. An estate that only ever scales up turns elasticity into a one way ratchet and ends up at the cost of a permanently maxed out platform. The teams that get the most from Exadata are the ones that treat scaling down with the same attention as scaling up, continually trimming enabled cores back to real demand. This continuous right sizing is at the heart of our cost optimization practice, and the ongoing operation that makes it happen is part of our managed services practice.

If your Exadata has only ever scaled upward, there is almost certainly cost to reclaim by introducing a scaling rhythm and trimming idle cores. An assessment can quantify the opportunity against your actual utilisation.