Oracle Hard Partitioning Licensing

Hard partitioning is the most important lever an estate has for bounding Oracle core counts on shared infrastructure, and it is also one of the most misunderstood, because it lives in a published Oracle policy rather than in the licence contract. This article explains what hard partitioning is, exactly how it differs from soft partitioning, which technologies Oracle approves, the contractual status of the policy, and how a buyer side estate uses it to limit cost without creating new exposure. It sits beneath the database licensing pillar and pairs with the soft partitioning analysis.

What is hard partitioning?

Hard partitioning is a method of physically segmenting a server so that an Oracle database can only ever run on a defined, bounded subset of the machine's processor cores. When the segmentation meets Oracle's criteria, you license only the cores in that partition, not every core in the server. On a large machine, this is the difference between licensing a handful of cores and licensing dozens, which makes it the single most valuable architectural lever in database licensing.

The qualifying characteristic, in Oracle's framing, is that the binding must be physical or firmware enforced and incapable of being changed without a documented, deliberate reconfiguration. A technology that can dynamically move a workload across more cores does not qualify, because Oracle reasons that the database could run on cores you have not licensed.

Hard partitioning versus soft partitioning

The distinction between hard and soft partitioning is the entire game. Hard partitioning bounds the licensable cores to the partition; soft partitioning, in Oracle's view, does not bound anything, so the database must be licensed for every physical core the software could run on. The same physical server can therefore carry a small licence or an enormous one depending purely on which category its partitioning technology falls into.

VMware vSphere is the most consequential example, and Oracle classifies it as soft partitioning. The full treatment of that position is in the database on VMware analysis, and the general soft partitioning rules are in the soft partitioning guide. The essential point for hard partitioning is that only the technologies on Oracle's approved list deliver the bounded core count; everything else defaults to the soft, unbounded treatment.

Which technologies does Oracle approve?

Oracle's partitioning policy document lists the specific technologies it accepts as hard partitioning. The list has historically included physical domains and certain processor and operating system level partitioning capabilities on enterprise hardware, along with named methods of capping CPUs at the firmware level. Certain Oracle engineered and Oracle virtualised approaches are also recognised, configured in the prescribed bounded manner.

Two cautions apply. First, the list is specific and version dependent, so the only safe practice is to verify the current policy document for the exact technology and configuration in use, not to rely on a general recollection of what was once approved. Second, approval is conditional on configuring the technology in the bounded way Oracle specifies; the same technology configured to allow dynamic core expansion will not qualify. The core counting that flows from a qualifying configuration uses the standard core factor applied to the bounded cores.

The policy is a document, not a contract

The single most important fact about hard partitioning is that the partitioning policy is a published Oracle document, not a term of the licence agreement. It is referenced by Oracle as the basis for its position, but unless your contract incorporates it by reference, it is Oracle's stated interpretation rather than a binding obligation you signed. This distinction is the foundation of any serious negotiation about partitioning.

In practice this means two things. An estate relying on hard partitioning should confirm that its chosen technology is approved under the current policy and configured correctly, because Oracle will assert the policy in an audit. But an estate facing a soft partitioning claim should recognise that the policy's status is contestable, a point developed in the audit defence approach. The policy governs the practical conversation even where its contractual force is open to challenge.

How hard partitioning changes core counting

When a qualifying hard partition is in place, the licensable processor count is calculated only on the cores assigned to the partition, multiplied by the core factor for the chip. A server with 64 physical cores, partitioned to give the Oracle database 8 cores, with a 0.5 core factor, requires 4 processor licences rather than the 32 that the whole server would demand. The saving is proportional to how tightly the database is bounded.

This is why hard partitioning is an architecture decision with a direct price. Designing infrastructure so that Oracle databases live on tightly bounded, approved partitions, rather than on large shared clusters, is one of the highest leverage moves in the whole discipline, and it interacts directly with the metric choice because a small bounded core count can change whether Processor or Named User Plus is cheaper.

Common hard partitioning pitfalls

The recurring failures are configuration drift and assumption. Configuration drift occurs when a partition that was correctly bounded at install is later widened, or when a capping mechanism is relaxed, so that the database can now reach cores beyond the licensed set; the bounded treatment is lost the moment that happens. Assumption occurs when a team believes a technology is approved when it is not, or applies an approved technology in an unapproved configuration.

• Widening a partition. A bounded partition is later given more cores, or a cap is lifted, silently expanding the licensable footprint.
• Wrong technology. A virtualisation layer assumed to be hard partitioning is in fact treated as soft, defaulting to the whole cluster.
• Live migration reach. The database can be moved to other hosts, which Oracle reads as the database being able to run on those cores.

Each pitfall converts a small, bounded licence into a large, unbounded claim, which is why hard partitioning must be treated as a controlled configuration, not a one time setup.

How to use hard partitioning safely

Using hard partitioning safely rests on verification and control. Before relying on a partition to bound a licence, verify that the technology and configuration are approved under the current policy, and document the configuration so it can be demonstrated in an audit. After deployment, monitor the partition so any widening, cap change, or migration capability that would break the binding is detected and corrected before it becomes exposure.

The preventive control is to treat the partition boundary as a licensing control under change management, so that no change which would let the database reach additional cores is made without a licensing review. Designing the bounded architecture, verifying its policy compliance, and instrumenting it for drift is the work the database licensing service brings to virtualised estates, and it converts the largest cost lever in the discipline into a stable, defensible position rather than a source of surprise findings.

The buyer side view

The buyer side position on hard partitioning is that it is the most powerful core counting lever available, but only when the technology is on Oracle's approved list, configured exactly as specified, and held stable under change management. Verify approval against the current policy, document the bounded configuration, monitor for drift, and recognise that the policy itself is a document rather than a contract term when a soft partitioning claim is asserted. Done deliberately, hard partitioning turns a whole server licence into a small bounded one. To model your own partitioning position, start with the database pillar, review the database licensing white paper, or request a consultation.