Exadata bundles hardware, database, and high value options together, which makes it easy to under count at certification and hard to plan around. Certify the database and options on the appliance first, then choose its future as a separate platform decision.
Exadata sits at the intersection of two decisions that buyers tend to tangle together at exit: how much to certify and where the workload should live next. The appliance is engineered to run demanding database workloads, and it tends to attract exactly the high value options that drive a certified count, so it is both an opportunity to capture entitlement and a place where counting goes wrong. At the same time Oracle uses the refresh cycle and the pull toward Cloud at Customer and OCI to shape the next commitment. This article keeps the two decisions apart, dealing first with counting Exadata correctly and then with what to do with it.
Count the database processors running on the Exadata compute nodes using the standard core factor, then add every covered option and management pack in use, because that is where Exadata estates are routinely under measured. The storage cells are not separately licensed for the database, but the options that make Exadata attractive, such as Real Application Clusters, partitioning, and the in memory option, frequently are, and they multiply across the deployed processors. Missing them understates the count and leaves perpetual value uncaptured. The general method sits in the broader exit plan in the ULA exit strategy guide.
On a standard server an option adds a layer of licensing. On Exadata the same options are often switched on by default or used heavily because the platform makes them perform, so a single appliance can carry several option entitlements per processor. Certifying the database processors but overlooking the options is the classic Exadata error, and it can leave a large share of the appliance's true entitlement on the table. The discipline is to inventory what is actually enabled, processor by processor, and certify each covered option with evidence behind it.
Exadata produces rich configuration and usage data, which works in your favour at certification because it lets you evidence exactly what runs where. The same data has to be read carefully, since feature usage views can flag an option as used from a brief or incidental activation. Building the evidence file means distinguishing genuine, intended use from incidental flags, so the certified count is both maximised and defensible if an audit looks at it later.
It depends on your workload profile, your hardware refresh cycle, and your direction on cloud, and it is a platform decision rather than a licensing one. The licensing move is to certify the database and options running on Exadata first, so you hold the perpetual entitlement regardless of where the workload goes. Only then do you choose between staying on the appliance, moving to Exadata Cloud at Customer, or migrating to OCI, each of which has its own commercial and technical case. Keeping the count and the platform choice separate stops a refresh conversation from compromising the certification.
An indicative order: inventory the database processors and every enabled option and pack on each appliance; separate genuine option use from incidental feature flags; certify the full defensible database and option count with evidence; capture the perpetual entitlement; then evaluate the platform future, whether that is staying on Exadata, Cloud at Customer, or OCI, as a clean technology and cost decision. The counting detail and the platform economics both depend on your configuration and your contract, so treat the sequence as a frame rather than a formula.
Consider a telecommunications operator, figures indicative, approaching exit with two Exadata racks. The initial internal count covered the database processors but listed only one option. A proper inventory found Real Application Clusters, partitioning, and the in memory option all in genuine use across the deployed processors, several times the entitlement first recorded. The operator certified the full database and option count with configuration evidence behind each, capturing a materially larger perpetual position. The refresh and cloud question was then handled separately, with the certified licenses available to carry to OCI under bring your own license terms if the operator chose, rather than being entangled in the certification itself.
Exadata is where options drive value, so the certification priority is to count the database and every enabled option with evidence before any platform decision, then choose the appliance's future on its own merits. Read this alongside the ULA exit strategy guide and the sibling pieces the OCI incentives Oracle will offer at exit and replacing Oracle workloads before exit. If Exadata sits in your estate at exit, the next step is an option level count before you certify. Here is the move to make now.
Count the database processors running on the Exadata compute nodes using the standard core factor, plus any covered options and packs in use such as RAC, partitioning, or the in memory option. The storage cells are not separately licensed for the database, but the database options that Exadata makes attractive often are, so the option count is where Exadata estates are commonly under measured.
It depends on your workload, your refresh cycle, and your direction on cloud. The licensing decision is to certify the database and options running on Exadata first so you hold the perpetual entitlement, then decide separately whether to stay on the appliance, move to Cloud at Customer, or migrate to OCI. Keep the count and the platform choice apart.
We inventory every enabled option on your Exadata estate, certify the full defensible count with evidence, and keep the platform decision clean and separate.