What are the two Oracle Database licensing metrics?
Oracle Database is licensed under one of two metrics, Processor or Named User Plus, and choosing the wrong one is where most over spend on Oracle Database licensing begins. The metric you sign decides whether you count people or cores, and Oracle will read an ambiguous estate in the direction that sells more licenses. Getting the metric right is the foundation everything else in this guide rests on.
Named User Plus (NUP) licenses the individual people and devices that access the database, subject to a per processor minimum. On Enterprise Edition that minimum is 25 named users per processor, so even a lightly used server carries a floor. A named user is a real, identifiable person or device, and the count has to include people who access the data indirectly through middleware or a reporting layer, which is the part most internal counts miss.
Processor licensing covers all access regardless of headcount and is priced on the cores in the server, adjusted by the core factor. It suits large, public facing or uncountable populations, where naming every user is impossible or where the named count would exceed the processor count anyway. The practical rule is simple: when the user population is small, stable and countable, Named User Plus is usually cheaper; when it is large, growing or anonymous, Processor is usually safer.
The NUP minimum is the trap. Auditors apply the 25 user per processor floor to every Enterprise Edition processor, so a server with ten real users can still carry a count of 25 per processor. Multiplexing through an application server does not reduce the count either. We test both points on every estate before accepting a number.
How does the Oracle core factor table work?
Under Processor licensing you do not pay per core directly. You pay per core multiplied by Oracle's published core factor for that chip, which is where two identical looking servers can carry very different counts. The factor is a number Oracle maintains, not a law of physics, so the right factor for your hardware is something you confirm against the current table, not something you accept from a finding.
| Processor type | Core factor | 32 cores equals |
|---|---|---|
| Current x86, Intel or AMD | 0.5 | 16 licenses |
| Oracle SPARC, varies by model | 0.25 to 0.5 | 8 to 16 licenses |
| IBM POWER | 1.0 | 32 licenses |
The arithmetic is simple, the exposure is not. A claim that applies the wrong factor, or quietly ignores it, can double the apparent requirement. A 32 core x86 server at a factor of 0.5 needs 16 Processor licenses; the same server counted at a factor of 1.0 needs 32. Recomputing the factor correctly is one of the fastest ways to bring a Database number down before any negotiation starts, and it costs nothing but the time to check.
What is Standard Edition 2 and where are its limits?
Standard Edition 2 is licensed by socket and capped deliberately, which makes it far cheaper than Enterprise Edition until a hardware change pushes you out of eligibility. It runs on servers with a maximum of two populated sockets, is licensed per socket with no core factor applied, and limits CPU threads per database. The cap is the point: SE2 trades scale for price.
- Maximum of two populated sockets per server
- Licensed per socket, with no core factor applied
- Thread limits per database instance
The risk is silent. A server refresh onto a larger host, a consolidation that moves the database onto a four socket machine, or a virtualization change that exposes more sockets can break SE2 rules without anyone making a licensing decision. When SE2 eligibility breaks, the fallback is Enterprise Edition at a far higher cost, so any infrastructure change near an SE2 database is a licensing event that needs checking first.
Which options and management packs create surprise costs?
Options and management packs are the single most common source of unexpected Oracle Database liability, because many install by default and some can be switched on by ordinary administration. Enterprise Edition ships with Partitioning, Advanced Compression, Advanced Security, the Diagnostics Pack, the Tuning Pack and more, all separately licensable, and Oracle's scripts detect any usage written to the data dictionary.
The trap is that usage can accrue with no purchase decision. A database administrator exploring performance in Enterprise Manager can register the Diagnostics or Tuning Pack with a single click. A developer enabling compression to save space can trigger Advanced Compression. None of this requires buying anything, and none of it is obvious until a finding lists it at list price.
The fix is to verify what is actually enabled, switch off what is not operationally needed, and dispute usage that was never meaningful. A line by line review of a packs finding typically removes most of it. Read the detail in the Options and Packs Detection Guide and technical locks that prevent accidental use.
Does Oracle recognise VMware as hard partitioning?
No, Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, so Oracle may argue you must license every host the software could run on. That cluster wide argument is the largest single source of inflated Database findings in virtualized estates, and it rests on a policy paper rather than the signed agreement.
A policy paper is not the contract. Where the signed Oracle Master Agreement is silent on partitioning or narrower than the policy, contract language beats policy, and the defensible position depends on your real architecture and what you can demonstrate. Dedicated clusters, host affinity rules and evidence of where the software can and did run all narrow the count. The virtualization licensing guide and dedicated clusters as the standard defense walk through the evidence that holds.
How does Oracle Database licensing work in the cloud?
In an authorized cloud, Oracle counts licensing against vCPUs rather than physical cores, and the rules differ by provider. On AWS and Azure, Oracle's policy for authorized cloud environments converts vCPUs to a license requirement, and bring your own license lets you carry existing entitlements across, subject to the same options and metric rules. On Oracle's own OCI, counting and incentives such as Support Rewards can favour the buyer, which is part of why Oracle steers settlements toward OCI commitments.
The buyer move is to model the metric in the cloud before migrating, not after, because a lift and shift that looks cost neutral on compute can change your license count materially. Disaster recovery in the cloud is governed by the same 10 day rule that applies on premises, so a warm standby that runs for more than the permitted period becomes licensable.
What triggers an Oracle Database audit?
Oracle Database audits rarely arrive at random, and the usual prompts are predictable. Audits run through GLAS, formerly LMS, under the audit clause in the Oracle Master Agreement, with a 30 to 45 day response window you can negotiate. Audits are also a sales channel, and analysts estimate that 20 to 30 percent of Oracle's on premises license revenue flows from them, so a trigger event often produces a letter within months.
- A hardware refresh or data centre consolidation
- A cloud migration, especially to a non Oracle cloud
- A ULA approaching certification or expiry
- A fall in support or new license spend
- A merger, acquisition or divestiture
- A rejected sales proposal
If any of these sit on your roadmap, the time to order your position is before the notice, not after. The audit defense guide covers the response end to end, and the stages of an Oracle audit end to end shows what each phase looks like.
How do you defend an Oracle Database licensing position?
A defensible Database position rests on four things: an independent and accurate measurement of the estate, the correct core factor and edition applied, options and packs verified and where possible disabled, and a virtualization argument built on your real architecture rather than Oracle's default assumption. Get those right and most opening claims fall by 60 to 80 percent, because the opening number was an inflated list price position, not a bill.
The discipline matters as much as the analysis. Agree scope in writing, decide what data to provide rather than running every script by reflex, and verify each line of a finding before conceding anything. Running Oracle's collection scripts is a decision, not an obligation, and the scripts can overcount across virtualization layers, so their output is reviewed before submission.
| Line | Opening position | Defended outcome |
|---|---|---|
| Core factor | Wrong factor applied | Recomputed correctly |
| Options and packs | Several flagged | Verified, most disputed |
| Virtualization | Whole cluster | Hosts in scope only |
| Overall claim | List price | Cut 60 to 80 percent |
This guide takes you a long way alone. When the number is large or the deadline is close, an independent database licensing advisory review produces the figure you can defend. For related detail see multitenant and pluggable database licensing, the SE2 socket rules and their limits, and term licenses versus perpetual.
Download the Options and Packs Detection Guide, or get a quote for a defensible Database figure.