Oracle hard partitioning that holds up in an audit. A named platform, the right settings, and three years of proof.

Oracle hard partitioning means you license only the cores you allocate to Oracle instead of the whole server, but only when a named technology is set up to Oracle's own document and dated records show the cap held all along.

What is Oracle hard partitioning and how much does it save?

With hard partitioning you license only the cores allocated to an Oracle workload, instead of every core in the server. On a 64 core two socket server, capping Oracle to 8 cores takes the Database Enterprise Edition requirement from 32 Processor licenses to 4. At list, that is $1,520,000 against $190,000.

The counts come from Oracle's core factor of 0.5 for Intel Xeon and AMD EPYC processors, applied to the physical cores in scope. The price is the $47,500 per Processor list line for Enterprise Edition in the technology price list.

Why does the saving keep paying after the first year?

Oracle charges annual support as a percentage of the net license fee, 22 percent on the current price list. Every license you avoid buying also removes a support line that would otherwise renew every year for as long as the database runs. In the example above the support gap alone is $292,600 a year.

Options multiply the effect. Each database option or management pack is licensed on the same Processor count as the database, so a cap that takes the count from 32 to 4 cuts every option line by the same ratio.

What has to be true for the saving to count?

Three conditions have to hold at the same time. If any one fails, Oracle licenses the whole server, and on a cluster it goes further.

• A named technology. The platform must appear on Oracle's list of approved hard partitioning technologies.
• Oracle's configuration. The cap must be set exactly as Oracle's own document for that technology describes.
• Continuous dated evidence. You must be able to show the cap was in place for the whole period an audit reviews.

Two of those failures look like success from inside the data center. A wrong configuration means the saving never existed, even though the console shows a cap. Missing evidence means the saving existed only until Oracle asked for proof.

Which platforms count as hard partitioning under Oracle's policy?

Oracle approves a short, closed list, set out in its partitioning policy. The current English version is dated February 14, 2022. Membership of the list is the only test. Everything absent from it is soft partitioning, and soft partitioning does not limit the license count.

Why doesn't an equally capable hypervisor qualify?

Because the policy is a list of names. A hypervisor does not qualify because it isolates cores as well as one that does. Pinning, affinity rules, host groups and dedicated resource pools do not change Oracle's position on a platform it has not named.

This is why engineering and licensing teams read the same architecture diagram and reach opposite answers. The engineer sees a VM locked to eight cores. Oracle sees a VMware or Nutanix AHV host, and every core on it.

Why does a cluster make a soft partition so much more expensive?

On a standalone host, the exposure from soft partitioning is that one server. On a clustered platform with shared storage, Oracle argues for every host the workload could reach. That is a boundary question rather than a partitioning one, and it usually costs far more than the host itself.

If you must keep Oracle on vSphere, the usual containment is a dedicated Oracle cluster sized to what you are willing to license in full. It is not hard partitioning, and it should not be described to Oracle as if it were.

When is hard partitioning worth setting up?

It pays most where a small Oracle workload sits on a large host that already runs a listed platform. Moving Oracle onto a few Oracle Linux KVM hosts is often cheaper than licensing a whole vSphere cluster. The cost is operational: pinned guests cannot live migrate, so host maintenance means planned database downtime.

Which configuration mistakes void an approved hard partition?

Two rules break most caps on approved platforms. Oracle counts the maximum capacity a partition can reach, and with hyperthreading on it counts any core touched by even one thread. In roughly 1 in 3 environments we reviewed on an approved technology, the cap was set in a way the policy does not accept.

• Maximum capacity decides the count. Oracle licenses the most a partition can reach, whatever its average use or entitlement, as the IBM Power example below shows. This is the most common reason an approved platform yields no benefit.
• Every thread sibling must be pinned. With hyperthreading enabled, a half pinned core is still a licensable core. This is the most frequent defect we find in otherwise correct configurations.
• Uncapped means the whole server. Solaris Zones and IBM Micro Partitions qualify only in their capped form. The uncapped variant licenses the whole machine.
• Trusted Partitions need live tooling. Without the management tooling installed and actively reporting the cap, the mechanism is not valid, however the hardware is set.
• Pinned guests must stay put. Oracle's documents for Oracle Linux KVM and Oracle VM forbid live migration of pinned VMs. The KVM cluster must not use any Oracle Linux Virtualization Manager scheduling policy, and Oracle VM 3 servers running pinned guests must be excluded from DRS and DPM.

How does the maximum capacity rule play out on IBM Power?

IBM POWER processors carry a core factor of 1.0, so every virtual processor Oracle counts is a full Processor license. Say a capped micro partition runs with 4 processing units entitled and a profile maximum of 16 virtual processors. The team sized it for 4 and believes it licenses 4.

The maximum was usually set high for burst headroom and forgotten. A dynamic LPAR change can raise the partition to that maximum without a restart, which is why the maximum is the figure to control. Lower it to the number you intend to license. Our IBM LPAR licensing guide covers the Power specifics.

What does a half pinned core look like on x86?

On an x86 host with hyperthreading, the hypervisor presents each thread as a CPU, and two threads share one physical core. Oracle licenses cores. A VM pinned to one thread of a core makes that whole core licensable, even if another workload uses the other thread.

Take a VM with 16 vCPUs on the 64 core server from the first example. How the pinning list maps onto thread siblings decides the bill.

• Pinned to 8 complete sibling pairs. 16 threads on 8 cores, so 4 Processor licenses and $190,000 at list.
• Pinned to 16 threads on 16 different cores. 16 cores touched, so 8 Processor licenses and $380,000 at list, for the same VM.

The mistake is easy to make because Linux often numbers the sibling of CPU 0 far from it, for example halfway up the list on a large two socket server. A pinning list of consecutive CPU numbers can land on one thread of many cores. Read the sibling map before you write the pinning list.

Whose configuration guide should your team follow?

Follow Oracle's own hard partitioning document for the technology, not the platform vendor's tuning guide. The two describe the same technology for different purposes, and only one of them is the licensing test.

• Solaris Zones. A dedicated cpu or capped cpu resource set in zonecfg, or a resource pool with a fixed processor set.
• Oracle Linux KVM. Pinning set with Oracle's olvm-vmcontrol utility.
• Trusted Partitions on Exadata. Exadata System Software 12.1.2.1.0 or later on two socket database servers, Enterprise Manager verifying the configuration continually, and two vCPUs counted as one physical core.

How do you check that your partitions meet Oracle's rules?

Read the configuration from the platform itself, the way Oracle's audit scripts do, and compare it with what you believe you license. The commands below are the ones Oracle's own hard partitioning documents use or that report the same values.

How do you build an evidence pack that survives an audit?

Keep three exports per partition: the partition profile, the pinning map, and the platform configuration. Each one is dated and stored outside the systems that generate it, so a platform rebuild or refresh does not take the history with it.

1. Run the exports on a fixed schedule, at least quarterly, and after every change to a partition.
2. Name each file with the host, partition and date, and keep a short change log that explains any jump in cores.
3. Store the files somewhere the platform team cannot overwrite, such as a document system with version history.
4. Keep them for the life of the license period, including hosts that have since been retired.

Done this way, it is about an hour of work a quarter. The same files let you answer partition questions from your own records, instead of from whatever the Oracle audit scripts collect on the day they run.

Why does the evidence pack decide more audits than the configuration?

Because Oracle reviews a period. It asks whether your partitions were capped throughout the period under review, typically three years, and most teams can show only the settings on the day the question arrives.

Which of the three conditions fails at the highest cost?

The evidence condition, because it fails unnoticed and backward in time. Choosing a named technology is the easy step, since the list is short and public and an architect who has read it usually makes the choice. Configuring it correctly is harder, which explains the misconfiguration rate in the previous section.

Evidence is different. The placement, profile and configuration records that would prove a historical cap generally keep only 30 to 90 days, so the proof has aged out before an audit question arrives. Our register of hidden Oracle audit exposures covers other records with the same problem.

Should hard partitioning be run as a one time project?

Most organizations run it that way. Architects design the cap, engineers configure it, licensing signs off and the file is closed. We disagree, because in our reviews the evidence decided the outcome more often than the configuration did, and a closed project produces no evidence after the day it closes.

Treat the cap as a standing control instead, with a named owner, a quarterly export and a review whenever a partition changes.

Oracle audits the three years behind the cap, so the proof has to cover three years too.

What have we seen in hard partitioning reviews in 2024 and 2025?

Across roughly 40 to 50 Oracle license positions we reviewed in 2024 and 2025, capping was the most misapplied way to cut Oracle cost that we saw. Both failure modes that produce nothing looked like success from inside the environment.

• Approved but misconfigured, roughly 1 in 3. The platform was on Oracle's list and the team believed it was capped, but the cap was set in a way the policy does not accept, so the benefit did not exist.
• Correct but unproven. Teams could routinely show the cap as it stood that morning and nothing at all for the preceding three years of the license period.
• All three conditions held. Where the technology was named, the configuration matched the policy text and the evidence was continuous, the saving on Database Enterprise Edition ran 30 to 60 percent.
• Fast evidence closed the question. Customers who produced dated exports within two weeks of the request closed partitioning questions without a finding.

Why does the size of the saving vary so much?

The range depends on how much of each server the Oracle workload needs. A small database capped on a large host saves close to the top of the range, while a database that already needed most of its host saves less. The Oracle knowledge hub collects our related guides on counting and containment.

What will Oracle's auditors say about your partitions, and how should you reply?

Expect the questions to target the maximum setting, the thread map and the history, in that order. These are the lines we hear most often, with the replies we recommend.

• "The profile maximum is 16, so we count 16." If the maximum was 16 during the period, they are right, and the time to fix it was before the audit. If it was lowered, show the dated profile export and the change record.
• "Your pinning covers only some threads on these cores." Reply with the sibling map and the pinning list side by side, showing that every allocated core is pinned in full.
• "Show us the configuration for the last three years." Hand over the quarterly exports and the change log. Offer nothing beyond the partitions in scope of the audit.
• "This host was in a cluster with live migration enabled." Produce the setting showing pinned guests excluded from migration and scheduling policies for the period, or accept that the cluster boundary applies.

What to do next

1. Confirm the platform is on the list. Check each Oracle host against the named technologies in the policy. Equivalence to a listed platform carries no weight.
2. Read the maximum on every partition profile. Compare the profile maximum with the entitlement, and lower any maximum above the count you intend to license.
3. Map thread siblings before pinning. Where hyperthreading is on, check that every allocated core is pinned in full, with no half pinned cores.
4. Confirm the tooling on engineered systems. Wherever Trusted Partitions are relied on, check that Enterprise Manager is installed and actively reporting the cap.
5. Start the quarterly exports this quarter. Platform records roll over long before a license period ends, and an export cannot be produced later for a quarter that has passed.
6. Test the pack before Oracle does. Ask someone outside the platform team to rebuild your count from the files alone. Our Oracle advisory team runs that check with you.

Frequently asked questions