The Oracle Database Licensing Guide

How is Oracle Database licensed?

Oracle Database is licensed mainly by two metrics, Processor and Named User Plus, with the Processor count derived from physical cores multiplied by the core factor table, and options and management packs licensed separately on top. Almost every Oracle database licensing question reduces to which metric applies, how the count is calculated, and what additional options have been enabled. Get those three right and the licensing position is clear. Get them wrong and an audit finding follows.

The reason this matters to buyers is that Oracle reads each of these elements in the way most favourable to a finding. Processor counts can be inflated through the core factor table or through virtualization claims, Named User Plus counts can fall below contractual minimums, and options can appear enabled that were never meant to be used. Understanding the mechanics is what lets a buyer hold each element to the contract rather than the policy. This guide is the database companion to the wider Oracle database licensing pillar guide.

How does the Processor metric work?

The Processor metric works by multiplying the number of physical cores by a core factor drawn from Oracle's core factor table, which varies by chip type, to produce the number of Processor licenses required. The same core count can therefore require different numbers of licenses depending on the hardware, because each processor family has its own factor. This is the metric most often used for servers with many users or with users that cannot easily be counted.

The Processor metric is also where virtualization findings live. Because the partitioning policy does not recognise VMware, Hyper V, or KVM as hard partitioning, Oracle can claim that every core in a cluster requires Processor licenses, not just the cores where Oracle ran. That policy is not the contract, and contract language beats policy, so the buyer move is to reconcile the count to the hosts that actually ran Oracle. The detail of that count and where it goes wrong is covered in the database licensing mistakes auditors find.

How does Named User Plus work?

Named User Plus licenses the database by counting the individual users and devices that access it, subject to contractual minimums per processor, which means the metric never falls below a defined floor regardless of how few users there are. This metric suits environments with a known, limited user population, such as internal applications, where counting users is cheaper than licensing every core.

The audit risk with Named User Plus is the minimum. Organisations sometimes license to their actual user count and overlook the per processor minimum, which sets a floor that can be higher than the headcount. An audit then finds an undercount against the minimum rather than against real usage. The buyer move is to count both ways, against actual users and against the contractual minimum, and license to whichever is higher. Where this metric is used in non production systems, the rules have their own subtleties, set out in licensing development and test environments.

How are options and management packs licensed?

Options and management packs are licensed separately from the database, on the same metric as the underlying database, and this is one of the most common sources of unexpected audit findings. Options such as Partitioning, Advanced Compression, and Advanced Security, and management packs such as Diagnostics Pack and Tuning Pack, each carry their own license, and each can appear in usage data through default installation or a stray administrative action.

The mechanism that catches buyers is how easily these are enabled. A single Enterprise Manager click can enable Diagnostics Pack or Tuning Pack, and many options install by default with the database, so a routine scan can report usage no one intended. Because the feature usage view records the touch rather than the intent, the raw output overstates genuine adoption. The buyer move is to reconcile reported usage to actual business use, disable what was enabled in error, and document the basis, before any data is shared.

How do you choose the right metric?

You choose the right metric by comparing the Processor cost against the Named User Plus cost for each deployment, accounting for the core factor on one side and the per processor minimum on the other, and selecting the lower compliant option. For a public facing system with many or uncountable users, Processor usually wins. For an internal system with a known, limited population above the minimum, Named User Plus often costs less.

This choice is not made once and forgotten. As deployments grow, as hardware changes, and as user populations shift, the cheaper metric can change, and a metric that fit at purchase can become expensive later. Reviewing the metric mix as part of ongoing license management, rather than only at audit time, is what keeps a database estate efficient and defensible. Spreading deployment across sites adds further considerations, covered in licensing across data centers.

Your next step

Oracle database licensing rewards buyers who understand the metrics and hold each count to the contract. Our free guide goes deeper on the Processor and Named User Plus metrics, the core factor table, and options, alongside the full Oracle database licensing pillar guide.