Capacity-on-demand is the only Oracle mechanism that lets you buy a 64-core box and license 8 cores without arguing about partitioning. This guide shows exactly how the odacli core activation works, where the one-way ratchet and patch-time re-enablement will cost you money, and what evidence to keep so an LMS reviewer accepts your active-core count.
Capacity-on-demand is the only Oracle mechanism that lets you buy a 64-core box and license 8 cores without arguing about partitioning. This guide shows exactly how the odacli core activation works, where the one-way ratchet and patch-time re-enablement will cost you money, and what evidence to keep so an LMS reviewer accepts your active-core count.
Capacity-on-demand is not a clever technical workaround, it is a contractual exception Oracle wrote into its own documentation, and that distinction is the whole reason it survives audits. Oracle's ODA Licensing Information User Manual (Release 19.16) defines CoD as an appliance that has a subset of its cores turned off so the Oracle Database Enterprise Edition license cost can be reduced, and it permits the reduction either before or after deployment. The 19.25 manual (27 January 2025) goes further and states that all Oracle products deployed on ODA can take advantage of Capacity-on-Demand licensing, which directly contradicts the older X6-2M text limiting CoD to Enterprise Edition alone. If you are still licensing options and management packs against full physical cores on an ODA because someone read the X6-2M page in 2019, you are overpaying and you should re-read the current manual before your next true-up.
Set this against general x86 processor licensing, where Oracle rejects soft partitioning outright and expects you to license every physical core in the server regardless of what the hypervisor or the OS says is running. CoD and Oracle approved hard partitioning are effectively the only two sanctioned routes to license fewer cores than you own, and CoD is by far the cleaner of the two because the reduction is executed by Oracle's own appliance tooling rather than by a third-party technology Oracle can dispute.
The money is not subtle. An ODA X11-L carries 64 cores (per the 19.25 manual), and at the 0.5 x86 core factor that is 32 Processor licenses of Database Enterprise Edition, roughly $1.52M at the $47,500 list price. Activate 8 cores instead and you need 4 Processors, roughly $190,000 list. That is an 8x delta on the same physical box, driven entirely by one command and a reboot. Every option you layer on top (RAC, Advanced Security, Multitenant, the management packs) scales off that same active-core count, so the multiplier compounds. Treat the activation decision as a purchasing decision, not an install step, and get the target core count agreed in writing before the appliance ships.
The same 64-core box is either $1.52M or $190,000 of Enterprise Edition list, and the only variable is one command.
The mechanic is a single command. On bare metal you run odacli update-cpucore -c <cores>, for example odacli update-cpucore -c 8, and the appliance returns a jobId with the description "CPU cores service update." Field guidance from 2018 indicated that update-cpucore would be deprecated in favour of modify-cpucore, and Oracle's own 19.23 licensing overview (May 2024) uses odacli modify-cpucore to set the low water mark, so expect both names in circulation across releases and check which one your version accepts before you script anything. The constraints are fixed: cores are assigned in multiples of two, with a two-core minimum, and modifying the enabled core count requires a reboot of all nodes in the system. On HA models both server nodes must carry the same number of active cores, so plan the outage as a cluster-wide event.
Two read-only commands matter more to your audit position than the write command does. odacli list-cpucores returns the history of core configuration changes, with dates, and odacli describe-cpucore returns the current configuration with a modification timestamp. In practice that history is the strongest piece of self-generated evidence you will ever hand an Oracle reviewer, because it is Oracle's own tool on Oracle's own appliance reporting Oracle's own state change, with a date stamp. In our experience negotiating these reviews, an odacli list-cpucores output showing, say, 32 cores configured in October and 4 cores configured the following January is accepted far more readily than any spreadsheet or hypervisor screenshot.
Do not let OS tooling define your position. Hyperthreading means a 12-core configuration presents 24 processors in /proc/cpuinfo, which is expected and licenses as 12 cores. Worse, My Oracle Support Doc 2206481.1 documents a case where OEM Grid Control and OS utilities such as SAR continued reporting the old core count after a reduction and a restart. If your evidence pack is built on /proc/cpuinfo, SAR, or an OEM report, you are relying on sources Oracle has itself acknowledged can lag.
The single most expensive property of ODA capacity-on-demand is that core activation moves in one direction only. Oracle's own documentation is explicit: if you change the CPU core count, you can subsequently only increase it. Set the box to 12 and you can later move to 16 or 20. Set it to 16 and 20 is your only remaining path down the road. There is no supported route back to 12. In practice, this means a sizing decision made in week one by an engineer who was thinking about headroom, not license liability, becomes a permanent floor on your Enterprise Edition footprint. The database team treats the number as a performance dial. Oracle treats it as a licensed quantity. Those two mental models collide at audit, and the buyer pays the difference.
Three failure modes account for nearly every ratchet problem we see in ODA licensing engagements. First, and most common, is the max-out mistake: an administrator runs the core-count procedure and sets it to the machine maximum, or on an HA pair to the two-node total, believing the step is mandatory. It is not. Oracle's X6-2-HA documentation states plainly that if you want the full per-server core count you should use the default configuration, because there is no need to set the CPU core count to the two-node total. Running the command at maximum burns the ratchet for nothing and converts an unlicensed hardware ceiling into a licensed one. Second, if the error is caught immediately, Oracle's 19.25 Licensing Information manual tells you the recovery path: contact Oracle Support. That escalation is time-sensitive. Days matter, weeks do not work in your favor. Third, field engineers have documented an undocumented escape hatch. The unforced reduction returns "reduction in number of cores is not supported," but `odacli update-cpucore --cores 4 --force` has completed successfully, with `describe-cpucore` subsequently reporting 4 cores configured. A second reduction, for example 4 down to 2, also requires the `-f` flag, and `odacli list-cpucores` will show the full history, including a documented sequence of 32 cores configured in October 2024 followed by 4 cores in January 2025.
A sizing decision made by an engineer thinking about headroom, not license liability, becomes a permanent floor on your Enterprise Edition footprint.
Treat `--force` as what it is: an unsupported behavior that happens to work. It does not create a contractual right to reduce licensed cores. Our position with clients is unchanged after two decades of these arguments: if you use force to reduce, open a Service Request describing the before and after core counts, get Oracle Support to acknowledge the resulting configuration in writing, and file that SR number alongside the `odacli list-cpucores` output. Without written Support acknowledgement, an LMS reviewer will price the higher historical count and put the burden of disproof on you.
Initial sizing is a one-time decision you can control. The patch cycle is a recurring event that can undo it without anyone noticing. The documented case is an ODA X8-2M patched from 19.11 to 19.14 that came back with threads 0 through 63 enabled, meaning all 32 cores were live, against a materially lower configured count. Nothing in the patch log flags this. No alert fires. The database simply runs faster, which is the last thing anyone investigates.
Price the exposure before you dismiss it. Thirty-two active cores on x86 at the 0.5 core factor is 16 Processor licenses of Database Enterprise Edition. At list that is roughly $760,000, carrying about $167,200 in annual support. An auditor who finds this does not treat it as a patching artifact. They treat it as unlicensed deployment, backdated to the patch date, and they will ask for the support back-bill as well. The same mechanism applies to any option or pack you have deployed on those cores, so the real number is usually worse than the base database figure.
The control is cheap and takes under five minutes per patch event. Make it a mandatory gate in the change record, not a best practice in a wiki. Run `odacli describe-cpucore` and an OS-level thread check (`lscpu` or `/proc/cpuinfo`, remembering that hyperthreading doubles the visible count, so a 12-core configuration correctly shows 24 processors) immediately before and immediately after every patch. Capture both as screenshots and attach them to the patch ticket. Re-run `odacli list-cpucores` quarterly and reconcile the change history against your licensed quantity, the same discipline we recommend for approved hard partitioning evidence. If a patch does re-enable cores, remediate and document the same day, because the gap between the patch date and the fix date is the only period Oracle can bill.
The ceiling is fixed by the model you order, and it is the only number Oracle cannot argue upward. Per Oracle's ODA Licensing Information manual (19.25, January 2025), X11-S and X10-S are single servers of 32 cores, X11-L and X10-L are single servers of 64 cores, and X11-HA is two servers of 64 cores each for 128 physical cores. Activation moves in 2-core increments. On x86 the core factor is 0.5, so 8 active cores equals 4 Processor licenses. At the Enterprise Edition list price of $47,500 per Processor and 22 percent support, that is $190,000 in license and $41,800 per year in support for an 8-core footprint. The HA trap is structural: both nodes must carry the same active core count, so every 2-core step on an HA box is really 4 cores and double the money. Order X11, not X10: per field reporting on the Engineered Systems Price List, X11 sits alongside X10 at identical prices, so buying the previous generation buys you a shorter support runway for the same spend. See our Oracle Database Appliance licensing buyer guide for the full cost-trap inventory.
| Active cores | Processor licenses (0.5 factor) | EE list at $47,500 | Annual support at 22% | Applies to |
|---|---|---|---|---|
| 2 | 1 | $47,500 | $10,450 | S, L (per HA node: 4 cores, 2 licenses) |
| 4 | 2 | $95,000 | $20,900 | S, L, HA (2 per node) |
| 8 | 4 | $190,000 | $41,800 | S, L, HA (4 per node) |
| 16 | 8 | $380,000 | $83,600 | S, L, HA (8 per node) |
| 32 | 16 | $760,000 | $167,200 | S ceiling, L, HA (16 per node) |
| 64 | 32 | $1,520,000 | $334,400 | L ceiling, HA (32 per node) |
| 128 | 64 | $3,040,000 | $668,800 | X11-HA ceiling only |
Named User Plus is the alternative worth pricing at the low end. EE NUP lists at $950 per user with a minimum of 25 NUP per Processor, so a 4-core activation (2 Processors) carries a 50-user floor at $47,500, half the Processor cost. In our negotiation experience the crossover sits around 100 to 125 countable users per 2 Processors; above that, Processor licensing wins and NUP counting becomes an audit liability because contractors, batch identities, and multiplexed application users all count. Use NUP only where the population is small, badged, and defensible in a spreadsheet you would hand to a reviewer.
This is the least understood clause in the ODA stack and the one Oracle field teams lean on hardest. Oracle's own ODA Licensing Overview states that when you add the hardware Support Identifier to your My Oracle Support account, you establish a license for all the cores on your system. Read literally, registering an X11-L for hardware support asserts a 64-core, 32-Processor position, which at list is $1.52 million in license and $334,400 a year in support, regardless of the 8 cores you actually activated. In practice we have seen this registration used as the opening baseline in license reviews and in renewal quotes: the reviewer sizes off the appliance, not off the configuration, and asks you to disprove it. That is a negotiating posture, not a contract term, but it works on buyers who have no counter-evidence.
The counter is documentary and it is easy to assemble before you need it. Your ordering document and CSI record the Processor quantity you actually purchased, and that quantity, not the chassis, is what you are contractually entitled to run. Your odacli list-cpucores output records the full history of core configuration changes with dates, which proves the highest activation you have ever run and therefore the maximum exposure across the audit lookback period. An ordering document plus a change history beats a hardware SI record every time, because one is a contract and the other is a support entitlement artifact. Keep monthly exports of list-cpucores and describe-cpucore alongside the reboot evidence, the same discipline we recommend for Oracle-approved hard partitioning.
An ordering document plus an odacli change history beats a hardware Support Identifier record every time.
Two rules for your procurement team. First, never accept a proposal, renewal quote, or ULA certification sized off the physical core count of an appliance; send it back and demand it be rebuilt from the activated cores. Second, put language in the order that any true-up or compliance measurement on ODA is assessed against odacli evidence for the period in question. Neither costs Oracle anything at signature, and both remove the ambiguity that a reviewer will otherwise price at full chassis.
Capacity-on-demand quietly rewrites the commercial sequence of an appliance deal, and that is where your leverage lives. Because Oracle prices the X11 line alongside X10 at parity (per the Engineered Systems Price List), and because the X11-L ships 64 cores against the X11-S at 32, the hardware delta between the two chassis is usually a fraction of what a single 8-core Enterprise Edition increment costs at list. Buy the larger chassis, activate the minimum footprint you can defend (two cores, in two-core increments), and stage the Processor license purchases as workload actually shows up. That converts one large capital ask, where Oracle holds all the pressure, into three or four smaller buys where you hold it, because each increment is a fresh transaction you can time against Oracle's quarter end. Read this alongside the Oracle Database Appliance licensing buyer guide before you sign the hardware order, not after.
Oracle's counter-move is predictable, and in our negotiation experience it appears in most appliance deals: the rep bundles full-capacity Enterprise Edition licensing into the appliance transaction at a headline discount, presents it as the "one-time appliance price," and quietly lets that discount lapse on every subsequent increment. You then pay a much worse effective rate for cores 9 through 24 than for cores 1 through 8, and the ratchet means you cannot walk it back. Demand three things in writing before signature.
One ULA trap deserves explicit attention. If your certification snapshot is taken while ODA cores sit activated high, that count becomes your permanent post-ULA entitlement and your permanent support base. Deliberately reduce and verify active cores well before the certification date, and keep the odacli evidence.
Do the evidence collection today, before you need it. On every ODA in the estate, run odacli describe-cpucore and odacli list-cpucores, and export the output to a dated, read-only file with hostname and serial number in the filename. The list command gives you the full history of core configuration changes with timestamps, and that history is the artifact an LMS reviewer will accept as proof of your active-core count. Then reconcile that history against the Processor entitlements sitting on the Support Identifier the appliance is registered under, because SI registration establishes a license baseline for all cores on the system.
Next, hunt the patch exposure. For each appliance, lay the patch dates against the core history and flag any box where a patching event sits between a lower configured count and a higher current count. That gap is unlicensed active capacity, and it is the single most common finding on ODA estates.
Then read across. The ODA licensing pillar covers core scaling economics and the cost traps end to end, the KVM virtualized ODA guide covers how CPU pools count against your active cores, and if you run non-ODA hardware, the Oracle-approved hard partitioning guide shows what evidence survives audit outside the appliance world.
Older ODA documentation, including the X6-2M manual, stated CoD applied only to Oracle Database Enterprise Edition. The Release 19.25 ODA Licensing Information User Manual (27 January 2025) states that all Oracle products deployed on ODA can take advantage of capacity-on-demand licensing. If you rely on the broader position for options, packs, or middleware, cite the 19.25 manual version in writing and get your Oracle rep to confirm it against your specific product list before you size the deal.
Not through the supported path. Once you change the core count, odacli only permits increases, and an unforced reduction returns 'reduction in number of cores is not supported.' A --force (or -f) argument exists and has been documented reducing a system from 10 cores to 4 and then to 2, but Oracle does not present it as a supported customer procedure. Open a Support case and get the reduction acknowledged in writing before you assume it holds up in an audit.
You burn the ratchet permanently, because you can no longer decrease it through supported means. Oracle's own guidance is to contact Oracle Support immediately if the error is caught right away. The prevention is simpler: if you want the full per-server core count, leave the default configuration in place rather than explicitly running update-cpucore at the maximum value.
You license activated cores, not hyperthreads. A system configured for 12 cores will show 24 processors in /proc/cpuinfo, which is expected behaviour. Apply the 0.5 x86 core factor to the activated core count, so 12 activated cores equals 6 Processor licenses, and keep odacli describe-cpucore output as the authoritative record rather than OS utilities, which have been documented lagging the actual configuration.
It can, and this is the most expensive silent failure in ODA estates. A documented case of an X8-2M patched from 19.11 to 19.14 came back with all 32 cores enabled against a lower configured count. At 0.5 core factor that is 16 Processor licenses, roughly $760,000 at list, sitting unlicensed until someone notices. Verify describe-cpucore and the OS thread view immediately after every patch and attach the evidence to the change ticket.
Both server nodes must maintain the same number of active cores, so every activation increment on an X11-HA or X10-HA is effectively doubled for licensing. An X11-HA is two servers of 64 cores each, 128 in total, so a 12-core-per-node activation is 24 activated cores, 12 Processor licenses after the 0.5 core factor. Model HA increments at two nodes when you build your cost case, not one.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
