What is Oracle Private Cloud Appliance?

Oracle Private Cloud Appliance (PCA) is an engineered, rack-based infrastructure platform that provides a private cloud environment on customer premises. Unlike Oracle's cloud-based OCI (Oracle Cloud Infrastructure), PCA brings the cloud operating model — self-service VM provisioning, elastic resource allocation, and container workloads — into the customer's own data centre.

From a licensing perspective, PCA is particularly important because it uses hypervisor technologies that Oracle explicitly recognises as capable of creating hard partitions for software licence counting purposes. This recognition is the foundation of PCA's licensing value proposition: the ability to licence Oracle software only on the vCPUs assigned to specific VMs rather than on all cores in the physical system.

PCA is available in two current configurations. The X9-2 configuration — now succeeded by the X10-2 — was based on Oracle Server X9-2 compute nodes (1U) with 3 to 20 nodes per rack and an Oracle ZFS Storage Appliance ZS9-2. The current X10-2 configuration uses Oracle Server X10-2 compute nodes and supports higher core densities per node. Both configurations run Oracle's PCA software stack, which includes the Oracle Cloud Native Environment for container workloads, Oracle VM (OVM) for virtualised workloads, and the PCA management infrastructure.

The Core Licensing Principle: Hard Partitioning

Oracle's software licensing is based on the processor metric by default: every physical core in the server where Oracle software is installed and running must be licenced (subject to the applicable core factor). This creates a significant cost challenge for virtualised environments where Oracle software runs on a subset of the total physical hardware capacity.

Oracle's response to virtualisation licensing is the concept of hard partitioning. A hard partition is a virtualisation or partitioning mechanism that is physically constrained — the virtual machine or partition cannot access processor resources beyond those explicitly allocated to it, and that constraint is enforced by the hardware or a hypervisor that Oracle has verified and approved.

Why Hard Partitioning Matters for Cost

In a soft-partitioned environment — such as VMware ESXi, Microsoft Hyper-V, or any hypervisor not on Oracle's approved hard partitioning list — Oracle requires licences for all physical cores in the server regardless of how many cores are assigned to the VM running Oracle software. If Oracle Database runs on a VM with 4 vCPUs in a server with 80 physical cores, Oracle's position is that all 80 cores require licensing. At a list price of $47,500 per processor licence for Oracle Database Enterprise Edition (with the Intel/AMD core factor of 0.5), that is 40 processor licences, or $1.9 million in licence cost plus annual support of approximately $418,000 per year increasing at 8 percent annually.

With hard partitioning on an Oracle-approved hypervisor, only the 4 cores assigned to the Oracle Database VM require licensing — 2 processor licences at $95,000, plus annual support of $20,900. The difference in this example is $1.8 million in initial licence cost and more than $400,000 annually in support.

For a structured framework, download our Oracle Cloud at Customer Licensing Playbook — a step-by-step resource built from 500+ Oracle advisory engagements.

Are you maximising PCA licensing savings?

Our Oracle licensing specialists review PCA configurations and identify licence reduction opportunities.
Request a Review →

Oracle VM on PCA: The Hard Partitioning Standard

Oracle VM Server for x86 is on Oracle's approved hard partitioning list and is the primary hypervisor used in Oracle Private Cloud Appliance deployments. When Oracle VM is used to create VMs on PCA, Oracle recognises the CPU pool assignment as a hard partition — meaning licence obligations extend only to the physical cores assigned to the CPU pool allocated to that VM.

How Oracle VM Hard Partitioning Works

In an Oracle VM environment on PCA, each VM is assigned to a CPU pool. The CPU pool defines the physical cores from which the VM can draw processing resources. Critically, the VM cannot access cores outside its CPU pool — this constraint is enforced by the Oracle VM hypervisor at a level Oracle recognises as physically constraining the software's access to processor resources.

To qualify for hard partitioning treatment under Oracle VM, the deployment must satisfy specific technical requirements: the VM must be assigned a dedicated CPU pool that is not shared with non-Oracle-licenced workloads, the CPU pool must not be dynamically expanded to draw from unlicenced core pools, and the configuration must be documented and reproducible for audit purposes. Organisations should retain the Oracle VM configuration files and CPU pool assignments as part of their licence documentation.

Oracle VM and the Trusted Partitioning Model

With PCA's X9-2 and later configurations, Oracle introduced the concept of Trusted Partitioning, which extends the hard partitioning principle to flexible VM shapes. Under Trusted Partitioning, VMs on PCA use flexible OCPU (Oracle CPU) shapes that allow the precise number of cores to be specified at VM creation. Oracle recognises these flexible VM shapes as valid for licence counting purposes, enabling organisations to deploy Oracle Database on a VM with the minimum number of OCPUs required for the workload and licence only those OCPUs.

The Trusted Partitioning model is significant because it eliminates the historical constraint of fixed VM sizes for Oracle Database workloads. In traditional Oracle VM environments, VM shapes had to match predefined configurations to qualify for hard partitioning treatment. PCA's flexible OCPU model allows more granular licence optimisation — particularly valuable for development, test, and lower-traffic production workloads where fixed large VM shapes would have over-licenced the deployment.

KVM on PCA: An Alternative Hard Partitioning Path

In addition to Oracle VM, PCA supports KVM (Kernel-based Virtual Machine) as a hypervisor option in PCA software version 3.0 and later. Oracle has confirmed that KVM database systems on PCA support hard partitioning for Oracle Database licensing, where each KVM database system can have its own CPU pool that enforces the same physical constraint as Oracle VM.

Comparing Oracle VM and KVM on PCA

Oracle VM and KVM on PCA offer equivalent licensing treatment when correctly configured, but differ in their operational characteristics. Oracle VM has the longer history on Oracle engineered systems and a more established track record in Oracle licence audits. KVM on PCA is the newer option, available from PCA software version 3.0 onwards, and aligns with Oracle's broader KVM adoption across OCI and Oracle Linux KVM deployments.

The key decision criterion for most organisations is operational preference and existing expertise. From a pure licensing perspective, both hypervisors deliver the same hard partitioning treatment when properly configured. What matters is the quality of the CPU pool configuration, the documentation maintained to support audit scrutiny, and the consistency with which the partitioning rules are applied across the PCA deployment.

Licensing Oracle Database on PCA

Oracle Database Enterprise Edition is the most commonly licenced product on PCA, and the licensing mechanics are the most directly impactful in terms of cost. Understanding the Oracle Database licence calculation on PCA requires applying both the hard partitioning principle and Oracle's Processor Core Factor Table.

The Calculation Methodology

The number of Oracle Database processor licences required for a PCA deployment is calculated as: (number of OCPUs assigned to the Oracle Database VM) × (applicable core factor for the PCA compute node processor) = processor licences required, rounded up to the nearest whole number. PCA X9-2 and X10-2 compute nodes use Intel Xeon processors, which carry a core factor of 0.5. Therefore, an Oracle Database VM assigned 8 OCPUs on a PCA node requires 8 × 0.5 = 4 processor licences.

This calculation must be applied at the time of deployment and updated whenever VM shapes are changed. CPU pool reassignments — intentional or accidental — that temporarily increase a VM's core allocation to more than the licenced count create a compliance exposure for the duration of the expanded allocation. PCA administrators should implement change management controls that require licence review before any CPU pool modification affecting Oracle-licenced VMs.

Oracle Database Options on PCA

Oracle Database options — such as Oracle Real Application Clusters (RAC), Oracle Active Data Guard (ADG), Oracle Partitioning, and Oracle Advanced Security — require separate processor licences for each active option in each Database running on licenced cores. Organisations that deploy RAC on PCA must licence all nodes of the RAC cluster. If Oracle Database is licenced on 4 cores per node and the RAC cluster has 3 nodes, the RAC licence requirement is 4 × 0.5 × 3 = 6 processor licences per option.

A common PCA licensing error is underestimating the options footprint. Organisations that deploy RAC for availability purposes, run ADG for disaster recovery, and use Partitioning for data management may have three or more separately licenceable options applied to their PCA database deployment. Each option must be identified and licenced at the same processor count as the Oracle Database licence itself.

"The value of PCA hard partitioning is captured only when the CPU pool assignments are maintained with discipline. Temporary overallocations for performance testing, development spikes, or emergency response scenarios all create licence exposure if the VM's core count exceeds the licenced amount — even for hours."

Licensing Oracle Middleware and Applications on PCA

Oracle Database is not the only Oracle product that can benefit from PCA's hard partitioning treatment. Any Oracle software product that is licensed on the Processor metric can leverage hard partitioning on PCA to limit the licence scope to the cores assigned to the relevant VM.

Oracle WebLogic Server

Oracle WebLogic Server Enterprise Edition and Suite are licenced on the Processor metric and can leverage PCA hard partitioning. Organisations running Java EE applications on WebLogic within PCA VMs should ensure CPU pool assignments for those VMs are documented as hard partitions. WebLogic Standard Edition uses the Named User Plus or Processor metric depending on the deployment, and the same hard partitioning principles apply to processor-metric deployments.

Oracle Fusion Middleware and SOA Suite

Oracle Fusion Middleware components — Oracle SOA Suite, Oracle Business Process Management Suite, Oracle Service Bus, and other integration platform products — are licensed on the Processor metric and benefit from PCA hard partitioning in the same way as Oracle Database. Integration middleware components are frequently deployed alongside Oracle Database in PCA environments, and the licensing economics of consolidating both on PCA can be significant.

Oracle Applications on PCA

Oracle E-Business Suite, JD Edwards, and other Oracle application products licensed on the Processor metric are licenceable with hard partitioning on PCA. The specific licencing terms for each application must be verified, as some Oracle applications include their own Oracle Database and technology stack licences under restricted-use terms, which may affect how the hard partitioning benefit is applied.

PCA Versus Alternative Infrastructure Options

Understanding PCA's licensing economics requires comparing it against the realistic alternative infrastructure options: standard x86 servers with VMware, Oracle Cloud Infrastructure (OCI), and Oracle Exadata Cloud@Customer.

PCA versus VMware on x86

VMware ESXi is not on Oracle's approved hard partitioning list. Oracle requires full server licensing when Oracle software runs on VMware. This creates a structural licensing disadvantage for VMware environments relative to PCA. Organisations with large Oracle estates on VMware face a binary choice: pay for all physical cores in every server running Oracle software on VMware, migrate Oracle workloads to an Oracle-approved hard partitioning technology (including PCA), or move Oracle workloads to OCI where Oracle's cloud licensing model applies.

PCA provides the closest operational equivalent to a VMware environment — on-premises, VM-based, data centre hosted — while delivering Oracle-approved hard partitioning. For organisations that prefer to maintain Oracle workloads on premises for data sovereignty, latency, or operational reasons, PCA is the primary technology available to achieve licence limitation.

PCA versus OCI

OCI is Oracle's public cloud infrastructure and uses a different licensing model: Oracle charges for OCPUs consumed via Oracle Cloud Service agreements rather than perpetual licences. For on-premises mandated workloads, OCI is not an option. For workloads without an on-premises mandate, OCI and PCA offer different economic profiles depending on usage patterns, existing licence holdings, and the available BYOL (Bring Your Own Licence) credits.

PCA versus Exadata Cloud@Customer

Oracle Exadata Cloud@Customer (ExaCC) is Oracle's on-premises Exadata deployment, managed by Oracle under a subscription model. ExaCC is purpose-built for Oracle Database workloads and offers Oracle-approved hard partitioning through its OCPU billing model. PCA supports a broader range of workloads beyond Oracle Database, making it the better choice for organisations with mixed Oracle and non-Oracle application workloads. ExaCC is the better choice for organisations with a predominantly Oracle Database workload that want Oracle to manage the infrastructure under a cloud service agreement.

PCA Licence Management: Operational Controls

The licensing benefit of PCA is only realised when the hard partitioning configuration is actively managed throughout the deployment lifecycle. The following operational controls are essential for maintaining the licence position established at deployment.

CPU Pool Change Management

Every change to CPU pool assignments for Oracle-licenced VMs must go through a formal change management process that includes a licence impact assessment. The assessment must confirm that the proposed CPU pool assignment does not increase core allocation beyond the licenced processor count. Emergency overrides — where CPU pool limits are temporarily lifted to address a performance incident — must be documented with timestamps and the licence position restored as quickly as possible.

VM Shape Tracking

Maintain a current register of all Oracle-licenced VMs on PCA with their current CPU pool assignment, corresponding licence count, and the Oracle product(s) licenced on each VM. This register is the primary document Oracle LMS will review during a PCA audit. Gaps in the register — VMs without documented licence assignments, VM shape changes without corresponding licence updates — create negotiating disadvantages in audit situations.

Annual Licence Position Review

Conduct a formal annual review of the PCA licence position, comparing the current VM inventory and CPU pool assignments against Oracle licence holdings. The review should identify any gaps created by VM additions or shape changes during the year and produce a remediation plan for any shortfalls before they become audit findings. The review should also assess whether licence holdings exceed actual deployment requirements — unnecessary over-licensing drives support cost increases at 8 percent per year without corresponding business value.

Oracle Engineered Systems Resources

Explore our full library of Oracle engineered systems licensing guides, PCA deployment strategies, and cost benchmarks in the Oracle Knowledge Hub.

PCA Licence Cost Strategy: Seven Recommendations

1. Size CPU Pools to the Minimum Required: When deploying Oracle Database or other Oracle software on PCA, assign the minimum number of OCPUs required to meet workload performance requirements. Every OCPU below the maximum available on the node represents a licence not needed. Right-size CPU pool assignments at deployment and review them at least annually.

2. Separate Oracle-Licenced and Non-Licenced Workloads: Use PCA's resource organisation features to maintain clear separation between VMs running Oracle-licenced software and those running unlicenced workloads. This separation simplifies audit documentation and reduces the risk of accidental licence scope expansion through shared CPU pool configurations.

3. Document Everything Before an Audit Requires It: Oracle LMS audits of PCA environments focus intensively on the CPU pool configuration and its consistency with licence holdings. Organisations that maintain current, accurate documentation — VM inventory, CPU pool assignments, licence register — consistently achieve faster and cheaper audit resolution than those that reconstruct documentation under audit pressure.

4. Use Trusted Partitioning for Development and Test: PCA's Trusted Partitioning with flexible VM shapes is particularly valuable for development and test environments, where Oracle Database is deployed on small core counts for occasional use. Licence the development and test databases on the minimum viable VM shape rather than replicating production configurations.

5. Challenge Support Increases at Renewal: Oracle's 8 percent annual support increase applies to PCA licence support in the same way as any other Oracle licence. The only mechanism to resist this increase is commercial negotiation at renewal. Presenting Oracle with data on reduced deployment footprint, competitive alternatives, or total cost of ownership analysis consistently produces better renewal outcomes than passive acceptance of the increase.

6. Evaluate BYOL Migration to OCI for Flexible Workloads: Oracle's BYOL programme allows organisations to apply existing perpetual Oracle licence holdings to OCI deployments. For workloads without an on-premises mandate, migrating Oracle-licenced workloads to OCI using BYOL can reduce the PCA licence footprint and associated support costs. The BYOL migration economics depend on the specific licences held, the OCI service costs, and the support cost reduction achievable on premises.

7. Engage Independent Advisory Before Major PCA Deployments: The licensing economics of PCA deployments are sufficiently complex — and the financial stakes are sufficiently high — that independent licensing advisory support should be engaged before major PCA deployments or reconfigurations. An independent review of the proposed CPU pool architecture, licence assignment, and options footprint can identify material cost optimisation opportunities that internal teams or Oracle account representatives will not surface proactively.

Key Takeaways

Oracle Private Cloud Appliance provides a uniquely powerful mechanism for limiting Oracle Database and middleware licence obligations through Oracle-recognised hard partitioning with Oracle VM and KVM. The cost savings versus licensing the same Oracle software on a standard x86 server environment — particularly a VMware environment — can be substantial, routinely reducing licence counts by 50 to 70 percent for workloads that run on a fraction of the total available server capacity.

The licensing benefit is earned through configuration discipline: CPU pool assignments must be sized appropriately, change management must govern every modification to Oracle-licenced VM configurations, and documentation must be maintained in a form that supports audit scrutiny at any point in time. Organisations that invest in this operational discipline consistently capture the full financial benefit of the PCA architecture. Those that treat CPU pool management as an afterthought frequently discover that the hard partitioning benefit they expected is partially or entirely compromised by configuration decisions made without licence awareness.

The 8 percent annual support cost increase, compounding over the life of the PCA deployment, is the other major cost variable that requires proactive management. Annual licence position reviews, combined with commercial negotiation at renewal, are the primary tools for containing long-term support cost growth on a PCA deployment.