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

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.

Oracle LMS audit outcomes are settled, not adjudicated. The audit findings Oracle delivers are an opening commercial position, not a fact. Every claim is challengeable — Core Factor calculations, option-usage interpretations, partitioning evidence, NUP counting, Java SE applicability. The audit defence playbook is described in our Oracle audit master guide; this compliance guide covers the preventive discipline that makes any audit defence stronger.

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:

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:

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

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 — 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.

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.

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.

• 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.

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.

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

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:

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

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.

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

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.

A global pharmaceutical group received an LMS audit notice with Oracle's standard opening position: Oracle Database EE was licensed on 240 cores, but Oracle's scope claim covered 1,872 cores across the vCenter linked-mode estate. Oracle's preliminary findings asserted $32.4M in additional licence liability.

We ran a four-month pre-audit compliance reconstruction. Step 1: full deployment inventory with Oracle workloads confirmed running on 14 hosts only. Step 2: vCenter configuration reconfigured to isolate Oracle hosts from non-Oracle clusters; DRS Host Affinity Groups created with documented operational policy. Step 3: DBA_FEATURE_USAGE_STATISTICS scans on all instances, disabling four database options that were enabled-but-unused, documented with timestamps. Step 4: Audit response submitted with the compliance evidence, counter-position on Oracle's scope claim, and contract-language analysis of the customer's OMA.

Final audit settlement: $0 . Oracle accepted the compliance evidence, the cluster isolation, and the option-usage cleanup. The customer retained the existing 240-core licence position with no additional purchase.