Oracle Compliance Master Guide — virtualisation, partitioning, multi-tenancy.

What Oracle compliance actually means

Oracle compliance is the state of having every deployed Oracle product covered by a valid licence with all options, metric rules and partitioning rules correctly applied — and being able to prove it under an LMS audit. The key word is prove. Compliance you cannot evidence is, in audit context, indistinguishable from non-compliance.

Oracle's licensing model is unusually unforgiving compared to other enterprise software vendors. The rules are detailed, the contractual definitions are tight, and Oracle's LMS team is structured as a margin-generating function inside Oracle Field Operations. Compliance is therefore both an architectural discipline and an evidentiary discipline. The buyer's job is to design deployments that fit the rules cleanly and maintain the documentation that lets them demonstrate the fit.

The five compliance pressure points across virtually every Oracle estate are virtualisation, options usage, partitioning, Java SE deployment, and DR/standby. The rest of this guide covers each in operational detail.

Virtualisation and the Oracle position

Oracle's published position on virtualisation is straightforward: an Oracle product is licensed on every processor where the product is "installed and/or running". On a physical host with no virtualisation, that's simple. On a virtualised environment, Oracle's interpretation becomes: every processor in every host the workload could migrate to.

This is not just an academic claim. It is the LMS audit-team's standard opening position on every virtualised customer, and it is the reason VMware-hosted Oracle workloads attract disproportionate audit attention.

The defence against the "could migrate to" claim rests on three structural choices:

1. Approved hard partitioning that contractually limits scope.
2. Physical isolation (separate clusters, separate SANs, separate networks).
3. Soft-partitioning configurations that are evidenced and operationally enforced — even though Oracle does not contractually recognise them.

VMware compliance — the high-risk zone

Oracle Database licensing on VMware is the single most contentious topic in enterprise Oracle compliance. Oracle's position has shifted over years but never to the buyer's advantage. The current state:

• vSphere 5.x — Oracle position: every host in every cluster where vCenter could migrate the VM must be licensed.
• vSphere 6.x / 7.x / 8.x — Oracle position: every host in every cluster connected by vCenter linked mode can be in scope. With vMotion, Storage vMotion, Storage DRS, the migratable scope expands further.
• Court treatment — the Mars Inc. v Oracle litigation produced findings critical of Oracle's interpretive position but did not change Oracle's contractual stance. Customers who go to litigation on VMware can win; customers who do not have to settle.

Three defensive postures work in practice:

1. Isolated dedicated cluster — physically separate ESXi hosts, separate vCenter, separate SAN, separate Layer-2. Documented Oracle-only purpose. Licensing limited to the cluster.
2. Hardware affinity rules + Host Affinity Groups — DRS rules pinning Oracle VMs to nominated hosts. Operationally enforced. Defended by evidence in vCenter logs and configuration documentation.
3. Migration to Oracle-approved virtualisation — replatform to IBM LPAR, Solaris Containers, Oracle VM, or move to OCI where the licensing model is different. For estates with large Oracle EE footprints on VMware, this is usually the cheapest long-term answer.

Our virtualised environments compliance playbook covers each posture in tactical detail.

Oracle-approved hard partitioning

Oracle maintains a closed list of partitioning technologies it accepts as limiting licence scope. The list has not changed materially in over a decade. As of 2026 the accepted technologies are:

The approved hard partitioning playbook covers each technology's configuration and evidence requirements. For the contractual side, see Oracle partitioning policy vs contract terms.

Soft partitioning and where it fails

Soft partitioning — CPU caps, resource controls, processor sets at the OS level — does not satisfy Oracle's contractual position on hard partitioning. The Oracle Partitioning Policy document is explicit: only the technologies named in the approved list bind scope. Everything else is "soft" and licensed at full physical capacity.

However, soft partitioning still has defensive value in three scenarios:

• Cgroups + cpuset on Linux — for KVM, container or bare-metal workloads, pinning Oracle to a defined CPU set creates strong operational evidence and is sometimes accepted in audit settlement as a basis for reduced scope (though never contractually).
• Solaris resource controls without capped pools — same logic; defensive, not contractual.
• Hyperthreading / SMT controls — Oracle's Core Factor is applied to physical cores, not threads, so SMT alone is not partitioning but does affect the Processor count.

Cloud compliance — AWS, Azure, GCP, OCI

Oracle's "Authorized Cloud Environments" document recognises AWS, Microsoft Azure, and Google Cloud Platform as approved for Oracle Database licensing under specific counting rules. The headline rule: count two vCPUs (with hyperthreading) as one Oracle Processor licence, or one vCPU (without hyperthreading) as one Processor licence.

This rule produces meaningfully different economics across the cloud venues:

• Oracle Database on AWS — EC2 vCPUs counted, RDS for Oracle license-included available, no automatic BYOL recognition for RDS Custom.
• Oracle Database on Azure — Azure VM vCPUs counted, Oracle Database@Azure as a managed first-party service.
• Oracle Database on Google Cloud — vCPUs counted, Oracle Database@Google Cloud also available.
• Oracle Cloud (OCI) — OCPU/ECPU model, Core Factor of 0.5 for x86 implicit in the OCPU definition.

Compliance traps in the cloud:

1. Burstable instance types (T-series on AWS, B-series on Azure) — Oracle counts the maximum vCPU, not the average. Avoid these for Oracle workloads.
2. Auto-scaling groups — every scaled-out instance carries licence implications. Cap the auto-scale ceiling at your licence ceiling, not the cloud limit.
3. Snapshots and backups — restoring a snapshot to a new instance is a deployment for licensing purposes if the new instance runs Oracle.
4. Lift-and-shift via marketplace images — marketplace images often default to high-vCPU shapes that don't match your licence position.

Multi-tenancy and pluggable databases

Oracle Database 12c introduced the Multitenant Architecture — Container Database (CDB) holding multiple Pluggable Databases (PDBs). From 19c the PDB-without-Multitenant-option model permits up to 3 PDBs without licensing the Multitenant option (priced at $17,500 per Processor). From 21c forward, more PDBs are permitted in some configurations but the rules are precise.

Compliance landmines:

• Each PDB inherits the option licence position of the CDB. If the CDB has Partitioning enabled, all PDBs are using Partitioning.
• Move PDBs between CDBs with different licence positions creates compliance drift. Documented governance is mandatory.
• Multitenant-related options (Diagnostics Pack, Tuning Pack on RAC One Node, etc.) carry their own metric rules.

See Oracle Multitenant licensing for the operational mechanics.

Options and packs — feature-usage compliance

The highest-volume LMS audit finding across the industry is options usage. Oracle's database options — Partitioning, Advanced Compression, Active Data Guard, RAC, Real Application Testing, Multitenant, Diagnostics Pack, Tuning Pack, Advanced Security, Database Vault, GoldenGate, and more — are licensed separately at significant prices. Most are enabled by default in 19c/23ai installations.

The compliance discipline:

1. Scan DBA_FEATURE_USAGE_STATISTICS on every Oracle database in the estate, every quarter.
2. Disable options not licensed (or not used). Document the disablement.
3. Reconcile the surviving usage against licence entitlement.
4. Run an internal pre-audit scan annually using the same scripts Oracle LMS uses.

See Oracle audit and database options for the LMS perspective and Diagnostics & Tuning Pack licensing for the two highest-volume option findings.

Java SE deployment compliance

Oracle Java SE under the Universal Subscription Employee Metric is fundamentally an employee-count licence, but the underlying compliance question is "is Oracle JDK actually installed?". Three rules:

1. Oracle JDK 8u202 and later requires a paid Universal Subscription (or NFTC use only) for commercial deployment.
2. OpenJDK distributions — Temurin, Corretto, Liberica, Microsoft OpenJDK, Red Hat OpenJDK — carry zero Oracle subscription requirement.
3. Mixed estates create the highest audit risk. Oracle's audit position assumes any unknown JVM is Oracle JDK until proven otherwise.

Compliance requires a comprehensive JVM inventory. See how to inventory Java installations and the broader Oracle Java licensing master guide.

DR and standby compliance

Disaster recovery configurations attract specific compliance treatment. Oracle's rule of thumb: a passive cold standby that is unpowered until DR invocation does not require a licence; an active standby running Data Guard does; an Active Data Guard read-only standby requires the Active Data Guard option.

Three configurations and their compliance:

• Cold standby (powered off) — no licence required during steady state. Licence required during failover. 10-day failover allowance per year is a contractual courtesy in many OMAs but explicit terms vary.
• Warm/active standby with Data Guard — full Database EE licence required on the standby plus the same options as the primary.
• Active Data Guard (read-only standby) — full EE plus Active Data Guard option ($11,500/Processor) required.

See Oracle audit and DR environments for the audit-defence specifics.

Documentation is your defence

The single highest-leverage compliance investment is documentation. Three artefacts pay back across every Oracle audit:

1. Deployment inventory — every Oracle product, every instance, every host, every option, every metric, updated quarterly.
2. Partitioning evidence — IBM LPAR configurations, OVM CPU pinning, Solaris resource pool definitions, with screenshots and logs.
3. Feature-usage scans — quarterly DBA_FEATURE_USAGE_STATISTICS output, archived. Disabled options noted with timestamps.

In audit, the value of these artefacts is that they shift the burden of proof. Oracle's standard tactic is to assert maximum scope and ask the customer to prove otherwise. Documentation pre-emptively does the proving.

Reference engagement

Frequently asked questions

Related guides