A virtualization count in an Oracle ULA turns on three numbers: the cores in scope, the core factor, and the boundary you can prove. This worked example runs the arithmetic from a single database virtual machine to a whole cluster, and shows how isolation moves the certified number in either direction.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
You count every physical core on every host the Oracle product can reach, by current configuration or by live migration, and then apply the Oracle core factor for the processor type. The unit Oracle counts is not the host the database happens to sit on, it is the reach of the workload. So a single Oracle database virtual machine on a cluster of identical hosts puts every core in that cluster into scope, and live migration to connected clusters extends the reach further. Three numbers decide the result: the cores in scope, the core factor that converts cores to processor licenses, and the boundary you can document. Change any one and the count changes.
In scope processor licenses equals total physical cores within reach, multiplied by the Oracle core factor. Reach is set by configuration and live migration. The core factor is set by Oracle's table for the processor type. The boundary you can prove is what makes the number defensible.
Start with one Oracle Database Enterprise Edition virtual machine running on a VMware cluster. The cluster has six hosts. Each host holds two physical processors, and each processor has eight cores, so each host is 16 cores and the cluster is 96 cores. Because the named product can migrate freely across all six hosts, Oracle's position is that all 96 cores are in scope, not the 16 cores on the single host where the database currently runs. The reach, not the residence, is what counts. This is the mechanic explained in when a whole cluster counts, and it applies the same way regardless of hypervisor, as covered in Hyper V and other hypervisors at certification.
Oracle's core factor table converts physical cores into processor licenses. Common recent x86 processors carry a core factor of 0.5, so two cores equal one processor license. With 96 cores in scope and a 0.5 core factor, the count is 96 multiplied by 0.5, which is 48 processor licenses. Had the database been licensed by the single host alone, the figure would have been 16 cores multiplied by 0.5, which is 8. The difference between 8 and 48 is the entire point of the virtualization rule, and it is driven by reach, not by anything the database is actually doing. The core factor varies by processor type, so confirm the right factor for your hardware rather than assuming 0.5.
Now add a second cluster of four hosts, same specification, joined to the first by shared storage and a migration policy that permits movement between them. The reach now spans ten hosts, 160 cores, which at a 0.5 core factor is 80 processor licenses. Alternatively, dedicate just two hosts to Oracle, lock live migration to those two hosts, and document the boundary. Reach falls to 32 cores, which at a 0.5 core factor is 16 processor licenses. Same hardware, same database, three very different numbers, all decided by the boundary you set and can prove.
| Scenario | Cores in scope | Core factor | Processor licenses |
|---|---|---|---|
| Single host view (not Oracle's position) | 16 | 0.5 | 8 |
| One six host cluster, free migration | 96 | 0.5 | 48 |
| Two clusters joined, ten hosts | 160 | 0.5 | 80 |
| Two dedicated hosts, migration locked | 32 | 0.5 | 16 |
All figures are indicative. The actual core factor depends on your processor type and the actual scope depends on your configuration and contract language, so treat the table as the method to apply rather than a fixed answer.
The arithmetic is neutral. What changes is intent. In a defensive setting, the 48 or 80 processor figure is exposure to manage, because after certification an audit that finds Oracle able to run across the whole reach can count it against you. Isolation, the move to 16, limits that exposure. In a maximization setting, where the organisation genuinely uses that capacity, the larger figure is opportunity. Because certification carries no fee and support stays flat regardless of the certified count, counting the full in scope number converts deployment you are already running into perpetual entitlement at no marginal cost. The same 48 is a liability or an asset depending only on whether the capacity is real and whether you can prove it.
Whichever direction you take, the number is only as good as the file behind it. For the count, that means cluster membership, host specifications, processor types, the core factor applied, and the migration configuration as it stood inside the term, all captured with dates. The figure on the certification letter is a claim; the evidence file is what makes it stand up in the audit that often follows.
The virtualization count is rarely about the database. It is about reach, the core factor, and the boundary you can prove, and those three numbers can move a certified figure by whole clusters. Run the arithmetic honestly, decide deliberately whether each cluster is isolated to limit exposure or counted to build entitlement, and document the configuration either way. The full method, with the rest of the virtualization cluster, lives in our pillar, the ULA exit strategy guide.
Count cores within reach, apply the core factor, and prove the boundary. A single database virtual machine on a six host cluster scopes to all 96 cores, which at a 0.5 core factor is 48 processor licenses, not the 8 the host alone would suggest. Isolation lowers that; connected clusters raise it. The arithmetic is the same in defence and in maximization. Intent and evidence decide which way it serves you.
Count every physical core on every host the Oracle product can reach by configuration or live migration, then apply the Oracle core factor for the processor type. A six host cluster of two processor hosts with eight cores each and a 0.5 core factor is 96 cores, which becomes 48 processor licenses, not the single host the database sits on.
Yes. Isolation lowers scope by limiting where Oracle can run. Dedicating a small cluster to Oracle and locking live migration to those hosts means only those processors are in scope. The count follows the boundary you can prove, so a tight, documented boundary produces a smaller defensible number.
Book a confidential assessment and we will work the arithmetic across your clusters, apply the right core factors, and tell you whether to isolate or to count.