Does CPU Pinning Reduce Your Oracle License Count? The Evidence Test

CPU pinning is a mechanism, not a policy entitlement, and Oracle counts the whole physical server unless your platform, configuration, and documentation all line up with the Partitioning Policy. This page sets out exactly what evidence survives an Oracle LMS review, where pinning fails, and how to combine controls into a core cap you can defend in writing.

What Oracle Actually Says About Pinning, and What It Does Not Say

Start with the document hierarchy, because that is where every pinning argument is won or lost. Your ordering document and the Oracle Master Agreement define a Processor by counting all cores in the server where the program is installed and/or running, multiplied by the applicable core factor. Nothing in that contract mentions pinning, affinity, cpusets, or vCPU-to-pCPU binding. The only place those concepts appear is the Oracle Partitioning Policy PDF, a document Oracle publishes with a stated effective date (policies in effect as of February 14, 2022 on the version most estates are working from), that states plainly it "may not be incorporated into any contract," "does not constitute a contract or a commitment to any specific terms," and is "subject to change without notice." Oracle also reserves the right to modify the definitions and conditions from time to time. Read that carefully: the policy is the instrument that grants you a sub-capacity exception from the contractual Processor definition, and Oracle can withdraw or narrow it unilaterally. It is a concession, not an entitlement.

The definition of hard partitioning inside that policy is physical, not logical. Oracle says hard partitioning "physically segments a server, by taking a single large server and separating it into distinct smaller systems," where each system "acts as a physically independent, self-contained server, typically with its own CPUs, operating system, separate boot area, memory, input/output subsystem and network resources." A pinned VM shares the hypervisor scheduler, the host kernel, the memory bus, and usually the storage and network stack with every other guest on the box. On the plain wording, pinning does not physically segment anything. Layered on top is the universal condition that ends most informal designs: "All approved hard partitioning technologies must have a capped or a maximum number" of cores. Uncapped, burstable, or administratively adjustable at runtime means no cap, and no cap means the full physical server.

There is exactly one Oracle document that equates hard partitioning with pinning, and it is narrow: the Oracle Linux KVM hard partitioning data sheet, which describes hard partitioning "also known as CPU pinning" as binding vCPUs to physical CPU threads or cores and preventing them from being scheduled elsewhere, and which conditions acceptance on following the instructions in that paper exactly. That is a product-specific implementation note for Oracle's own hypervisor. It is not a general statement that pinning equals sub-capacity on any platform you happen to run. Treat any vendor rep, reseller, or integrator who cites it in a VMware, Nutanix, or generic Red Hat KVM context as making a claim they cannot put in writing, and ask them to do exactly that.

Your contract says Processor, the policy says pinning, and only one of those is enforceable against you.

The Approved List Is Closed, and Pinning Is Not On It By Itself

The approved list is enumerated, finite, and closed. Oracle names Physical Domains (PDomains, Dynamic Domains, Dynamic System Domains), Solaris Zones and Solaris Containers (capped only), IBM LPAR including DLPAR from AIX 5.2, IBM Micro-Partitions (capped only), vPar, nPar, Integrity Virtual Machine (capped only), Secure Resource Partitions (capped only), and Fujitsu PPAR, with Oracle Linux KVM and Oracle VM Server accepted only as prescribed in Oracle's own instructions. Anything not on that list defaults to the contractual rule: license the entire physical environment. In 25 years of these arguments, the same four technologies keep failing at the same point, because none of them appear above.

Two mobility traps deserve separate billing, because they defeat caps that are otherwise valid. First, IBM PowerVM Live Partition Mobility is not an approved hard partitioning technology, and Oracle's position is that all cores on both the source and the destination server must be licensed. A perfectly capped LPAR loses its cap the moment LPM is enabled in the environment, and auditors ask for the HMC configuration to prove it. Second, live migration of CPU-pinned VMs to another Oracle Linux KVM node is not permitted under the hard partitioning policy. If your OLVM cluster has live migration enabled at cluster level, the pinning is documentation without effect. Disable the capability, evidence the disablement, and keep the change control record.

The buyer-side action is unglamorous but decisive. Inventory every Oracle workload against the enumerated list, mark each as approved-and-capped, approved-but-uncapped, or absent from the list. Anything in the second or third bucket is a full-server exposure today, whatever your architecture diagram claims, and should be priced at the contractual Processor count before you decide whether to remediate, migrate, or negotiate it away at renewal.

The Evidence Test: Nine Artifacts an LMS Auditor Will Ask For

A pinning claim is worth nothing until you can hand an auditor a folder that proves the cap existed continuously, not just on the day they asked. Oracle's KVM data sheet is explicit that hard partitioning "also known as CPU pinning" requires binding vCPUs to specific physical CPU threads or cores and following the instructions in that paper, and the Partitioning Policy adds the universal condition that all approved technologies must have a capped or maximum number of cores. Neither statement is self-proving. In practice LMS asks for the same nine artifacts every time, and the burden of production sits entirely with you: the vm.cfg or libvirt XML domain definitions showing an explicit vcpu pin list per guest, the output of Oracle's own prescribed verification commands captured with visible timestamps and hostnames, the hypervisor version and patch level for each node, change-control tickets covering every pinning modification in the look-back window, evidence that live migration is disabled at cluster level with the configuration export to back it, cluster membership records showing which physical hosts were in scope on which dates, LMS collection scripts run on the physical host rather than inside the guest, an inventory reconciling guests to hosts across the period, and a signed internal control statement from someone with authority. Miss one and the reviewer does not haggle over it; they revert to the contractual Processor definition and count every core in the physical environment.

The point most teams miss is temporal. Auditors price the gaps, not the good months. A perfect configuration snapshot taken this quarter does nothing for a three-year look-back if you cannot show the same cap held in month seven, and the standard LMS response to an evidence gap is to assume the unrestricted state for the entire uncovered period. Build the pack as a running record from day one, not as an audit-response scramble, and keep it with the same discipline you would apply to a structured internal Oracle license audit. If your platform is KVM or OLVM specifically, cross-check the pin syntax and host-level collection expectations against the detail in how many cores actually count on KVM and OLVM before you rely on it in a negotiation.

Auditors price the gaps, not the good months.

What a Failed Pinning Defense Costs: The Arithmetic

Run your own numbers before Oracle runs theirs, because the gap between a defended cap and a cluster finding is not incremental. Under the Oracle Technology Global Price List effective 16 April 2026, Database Enterprise Edition lists at 47,500 dollars per Processor and 950 dollars per Named User Plus, with a floor of 25 NUP per Processor on EE. A two-socket, 64-core Intel server at core factor 0.5 produces 32 Processor licenses, roughly 1.52 million dollars at list before any option. That is the base case. The option stack is where a miscount compounds: Partitioning at 11,500 dollars per Processor, RAC at 23,000, Diagnostics Pack at 7,500, Tuning Pack at 5,000. Stack all four onto the same 32 Processors and you add another 1.76 million dollars at list. Then apply support at 22 percent of net license fees escalating 8 percent per year, which is why a dollar taken off the net is worth roughly 2.10 dollars across a five-year hold.

The delta is 2.65 million dollars in license at list plus 582,120 dollars in year-one support, before the 8 percent annual escalator compounds it. Note the NUP alternative rarely rescues you at this scale: 32 Processors triggers a 800-user floor at 950 dollars, 760,000 dollars, and that floor applies per program in the stack. Two practical instructions. First, price the failure scenario in writing before you enter any audit conversation, so your negotiating team knows what the exposure actually is rather than reacting to Oracle's number. Second, treat the option stack as the primary lever: options attach to the same Processor count, so every core you legitimately remove from scope cuts five line items at once. Sequence that work into your pre-renewal footprint reduction rather than mid-audit, when your leverage is gone.

Core Factor and Cloud: Where the Multiplier Changes the Answer

Treat the cap and the multiplier as two separate levers, because Oracle does. The cap answers "how many physical cores are in scope?" and the multiplier answers "how many Processor licenses does each of those cores consume?" A pinning argument that shaves 32 cores off a scope on an Intel platform at core factor 0.5 saves 16 Processor licenses. The same argument on IBM Power, which sits at core factor 1.0, saves 32. That is why a 24-core POWER9 box costs exactly what a 48-core x86 box costs, and why we tell clients to spend their scarce engineering and negotiation effort on the 1.0 platforms first. The governing document is Oracle's Processor Core Factor Table, doc 070634. The current revision, dated 28 January 2026, added the Intel Xeon 69xxP, 67xxE, 67xxP, 65xxP and 63xxP families (plus the -B variants, X55xx, E54xx/X54xx, X34xx and 51xx) at 0.5 and clarified the AMD EPYC and Opteron entries. The ARM rows go back to the 30 June 2023 revision: Ampere Altra, AltraMax and AmpereOne at 0.25, and all other ARM at 1.0, which is the line that quietly punishes Graviton-based bring-your-own-license deployments.

Two procedural traps cost real money and both are entirely avoidable. First, aggregate the core-factor-adjusted count across the estate per program before you round up, not server by server; rounding at each host inflates the total. Second, confirm the factor against the table version in force on the date your ordering document was signed, not today's PDF, since Oracle revises 070634 without notice. Separately, the Core Factor Table is excluded entirely in AWS, Azure and Google Cloud under the authorized cloud policy, where the conversion is two vCPUs per Processor with hyper-threading enabled and one vCPU per Processor with it disabled. OCI BYOL uses its own rule of two OCPUs per Processor, which you should check against the shape math in our note on counting Processor licenses on OCI bare metal versus VM shapes.

Building a Defensible Cap: Layering Controls Instead of Relying on Pinning

Pinning is one layer in a stack of five, and on its own it has never survived an LMS review we have worked. Build the stack in priority order. Layer one is physical separation or a genuinely approved technology: a dedicated host, or capped Solaris Zones, capped LPARs, nPars, vPars, or Oracle Linux KVM configured exactly per Oracle's own data sheet. Layer two is contractual language, and this is where most organizations leave the money on the table. An amendment or an ordering document clause that names the specific hosts, the specific core counts, and the specific technology converts a policy document Oracle says "may not be incorporated into any contract" into an enforceable term. Layer three is technical enforcement: pinning plus live migration disabled plus cluster isolation, since PowerVM Live Partition Mobility and KVM live migration both void the cap and pull the destination server into scope. Layer four is continuous evidence capture, dated configuration exports and change tickets held for the full audit lookback. Layer five is an internal audit cadence, reviewed at least quarterly using the approach in our guide to running internal Oracle license audits before Oracle does.

Oracle will write partitioning language into a contract at renewal or on a new purchase, and will almost never write it during an audit.

Time the ask correctly. Oracle will negotiate written partitioning language at renewal or attached to a new purchase, when the sales team owns the outcome and needs the revenue recognized in-quarter. During an audit, the file sits with LMS, whose incentive is the size of the finding, and a cap concession then costs you the finding plus a compliance purchase at weak discount. Price the concession before you trade for it: realistic per-Processor bands we see are roughly $33,000 to $40,000 for Tier 1 deals ($50K to $500K), $19,000 to $28,500 for Tier 2, and $11,800 to $19,000 for Tier 3, against a $47,500 Database Enterprise Edition list. A cap that removes 16 Processors from scope is therefore worth $190,000 to $640,000 in license, plus 22 percent annual support on the net figure escalating at 8 percent per year. Quantify that number before you sit down, present the layered controls as the reason the cap is real, and make the written clause the deliverable you refuse to close without. Cross-check your starting position against our breakdown of the Oracle Partitioning Policy and what it actually decides.

What To Do First

Work in sequence, because the order determines how much leverage you keep. First, run an internal count on the physical host using the same scripts LMS would run, then compare the result to your entitlement rather than to your intention. Our internal Oracle license audit method exists for exactly this: you need the unfavorable number in your own hands before Oracle produces it. Second, inventory every host where a pinning claim is being made and classify each one against Oracle's closed list: approved (PDomains, capped Zones, capped LPAR, vPar, nPar, capped IVM, PPAR), prescribed-only (Oracle Linux KVM or Oracle VM Server configured exactly as the KVM data sheet requires, no live migration), or unsupported (everything else, including VMware, Nutanix AHV, and ad hoc taskset or cgroups pinning). Third, pull the last twelve months of change tickets and hypervisor exports and test whether continuity of evidence actually exists. A cap proven on the day of the audit but undocumented for the preceding year is a cap Oracle will price from the first day of the period. Fourth, price the worst case at list before deciding anything: 64 cores at a 0.5 core factor is 32 Processor licenses, roughly $1.52 million at the 2026 list price of $47,500 for Database Enterprise Edition, before options and before 22 percent support. That number, not your comfort level, decides whether you remediate the configuration or buy contractual language.

• Never volunteer a pinning claim in an audit response; answer the question asked and nothing beyond it.
• Force Oracle to state the rule it is applying and the specific contract clause or ordering document it relies on, in writing.
• Treat the Partitioning Policy as what it says it is: a non-contractual document Oracle may change without notice.
• Take partitioning language into the next renewal or a new ordering document, where you have money on the table, not into the current dispute, where you have none.

Related advisory: the full topic guide.

Frequently asked questions

Does CPU pinning on VMware reduce Oracle licenses?

No. VMware CPU affinity is not on Oracle's approved hard partitioning list, so Oracle's position is that you license every physical core in the cluster, and in many cases every cluster the VM could reach through vMotion or shared storage. Pinning on VMware may reduce actual usage, but it does not change the license count under the policy. If you have a written contractual amendment naming VMware sub-capacity, that document governs, not the policy PDF.

Is CPU pinning on Oracle Linux KVM accepted as hard partitioning?

Yes, but only if you follow Oracle's own instructions in the Hard Partitioning with Oracle Linux KVM data sheet exactly. That means binding vCPUs to specific physical CPU threads or cores, preventing rescheduling, and disabling live migration of pinned VMs to other Oracle Linux KVM nodes. Any deviation, including an untracked configuration change or a migration event, reopens the whole host to full licensing.

What evidence does an Oracle auditor accept for a pinned configuration?

Auditors want configuration files showing explicit vCPU pin lists, timestamped command output from the physical host, hypervisor version and patch records, change-control tickets covering every modification, and proof that live migration was disabled at cluster level. The evidence has to cover the entire look-back period, not just the day the audit started. A current snapshot with no history is usually treated as unproven and priced at full server capacity.

Can I get Oracle to agree to CPU pinning in writing?

You can, but almost never during an audit. The realistic window is a renewal or a new purchase, where you trade commitment for an ordering document clause or amendment that names the specific hosts, technology, and maximum core count. Once that language sits in a signed document it overrides the Partitioning Policy, which Oracle states may change without notice and is not incorporated into any contract.

Does pinning matter more on IBM Power than on x86?

Yes, substantially. IBM Power carries a core factor of 1.0 while most current Intel and AMD server processors are 0.5, so a 24-core Power server costs the same as a 48-core x86 server. That makes a defensible cap roughly twice as valuable per core on Power, which is also the platform where genuinely approved technologies such as capped LPAR and capped Micro-Partitions are available.

How much can a failed pinning claim cost?

A two-socket, 64-core Intel server at core factor 0.5 requires 32 Database Enterprise Edition Processor licenses, roughly 1.52 million dollars at the 47,500 dollar list price before options. Add Partitioning at 11,500, RAC at 23,000, and diagnostic and tuning packs, then apply 22 percent annual support escalating 8 percent per year, and a single unproven host can generate a seven-figure finding.