What is a Named User Plus minimum?
Named User Plus is Oracle's metric for counting authorised individuals and the non human operated devices that use a program. For analytics and technology products, the metric does not simply count people; it imposes a contractual floor expressed as a minimum number of Named User Plus per processor. The licensable quantity is the greater of two numbers: the actual count of authorised users, and the per processor minimum applied across the hardware the program runs on. Whichever is higher is what you owe.
That floor exists to stop customers running large deployments for a handful of named users and paying almost nothing. From Oracle's perspective it ties the minimum cost to the scale of the infrastructure, not just the user list. From the buyer's perspective it means the metric has a hidden lower bound set by hardware, and a deployment that looks cheap on a user count basis can be expensive once the floor is applied. This article sits beneath the BI and analytics pillar and explains a mechanic that recurs across every named metric in the cluster.
How the per processor floor is calculated
The floor is derived in two steps. First, the processor count for the hardware is calculated exactly as it would be for a Processor licence: physical cores multiplied by the Oracle core factor from the Processor Core Factor Table. Second, that processor count is multiplied by the per processor minimum, commonly ten Named User Plus per processor for analytics products, to give the minimum licensable user quantity. The result is the floor below which the Named User Plus count cannot fall regardless of how few people actually use the system.
A concrete example makes the mechanic clear. Consider an Oracle Analytics Server deployment on a server with two sixteen core x86 processors. That is thirty two cores at a 0.5 core factor, or sixteen processors. At ten Named User Plus per processor, the floor is one hundred and sixty Named User Plus, even if only forty people are authorised to use the system. The user count is irrelevant until it exceeds the floor; below that point, the hardware sets the bill.
| Hardware | Cores | Core factor | Processors | NUP minimum (×10) |
|---|---|---|---|---|
| 1 × 8 core x86 | 8 | 0.5 | 4 | 40 |
| 2 × 16 core x86 | 32 | 0.5 | 16 | 160 |
| 4 × 16 core x86 | 64 | 0.5 | 32 | 320 |
Why the minimum catches analytics buyers
Analytics buyers select Named User Plus precisely when the user community is small and defined, expecting to pay for those users rather than for the whole infrastructure. That instinct is correct only when the user count comfortably exceeds the floor. The trap is choosing Named User Plus for a small community deployed on large or over provisioned hardware, where the per processor floor exceeds the actual user count and the buyer ends up paying a minimum that bears no relation to who uses the system.
Named User Plus was supposed to save you money on a small user base. On big hardware, the per processor floor quietly hands the saving back.
The error compounds because hardware tends to grow over time while user communities do not. A deployment sized correctly at signing, with the user count above the floor, can fall below it after a hardware refresh adds cores, silently converting a usage based bill into a hardware based one. The buyer side discipline is to recompute the floor every time the infrastructure changes, not only at the original purchase. The detailed platform context is in the BI Server licensing guide.
When to switch from Named User Plus to Processor
The decision between Named User Plus and Processor is arithmetic, and the floor is what makes it so. If the actual user count sits well above the per processor floor, Named User Plus is usually cheaper, because you pay for users rather than the full processor count. If the user count sits at or below the floor, Processor is frequently the better metric, because under Named User Plus you are paying the floor anyway and Processor removes the user counting burden entirely while costing roughly the same.
The crossover point is where the two metrics cost the same, and modelling it requires both the genuine authorised user count and the processor count for the hardware. Many analytics estates carry the wrong metric simply because no one recomputed the crossover after the deployment or the user base changed. Recalculating it is one of the quickest wins in an analytics review, because switching metric at a renewal can lock in a lower cost with no change to the deployment itself.
How virtualisation inflates the floor
Virtualisation interacts with the Named User Plus floor in the same punishing way it interacts with Processor licensing. Where the analytics workload runs on a soft partitioned hypervisor, Oracle may count the cores of the entire cluster the workload could migrate to, not the hosts it actually runs on. Because the floor is derived from the processor count, inflating the processor count inflates the floor: a sixteen processor deployment that Oracle treats as sixty four processors carries a Named User Plus floor four times higher.
This means the virtualisation boundary is not only a Processor licensing issue; it sets the minimum even for customers who chose Named User Plus to avoid Processor counting. Establishing the partitioning boundary with evidence, before Oracle asserts the whole cluster, protects the Named User Plus position as much as the Processor one. The full treatment of soft and hard partitioning in analytics is in the analytics virtualisation guide.
The minimum in an audit
In an audit, the Named User Plus minimum produces a specific and common finding: the authorised population is below the per processor floor, and Oracle asserts the floor as the licensable quantity. Customers are frequently caught off guard, having counted their users carefully and concluded they were compliant, only to learn that the hardware sets a higher number. The finding is not a discovery of hidden users; it is the application of a contractual floor the customer overlooked.
The defence is to have computed the floor first and chosen the metric deliberately. Where Named User Plus is genuinely the right metric and the user count exceeds the floor, clean user data settles the question quickly. Where the floor exceeds the user count, the conversation shifts to whether Processor would have been cheaper and whether a metric change at renewal resolves it going forward. Either way, the prepared buyer controls the discussion, which is the substance of our audit defence practice.
Modelling the metric decision
Modelling the Named User Plus decision requires three inputs: the genuine count of authorised users and operated devices, the processor count for the hardware after the correct core factor, and the per processor minimum from the contract. With those, the floor is a simple multiplication and the comparison against the user count is immediate. The model should be rerun whenever the user base or the hardware changes, because either can move the deployment across the crossover point.
The broader lesson is that metric selection is never a one time decision. It is a position that should be revisited at every renewal, every hardware refresh, and every significant change in the user community, because the arithmetic that made Named User Plus right last year can make it wrong this year. Treating the metric as a living decision rather than a fixed choice is a core part of the analytics advisory service.
The buyer side view
The Named User Plus minimum rewards the buyer who does the arithmetic before choosing the metric. Compute the per processor floor from the cores, the core factor, and the contractual minimum. Compare it honestly against the genuine authorised user count. Choose Named User Plus only when the user count comfortably exceeds the floor, and choose Processor when it does not. Recompute the floor every time the hardware changes, because a refresh can silently push a usage based bill into a hardware based one. And establish the virtualisation boundary, because it sets the floor as surely as it sets the Processor count.
A buyer who treats the floor as a known input rather than a surprise never receives the finding that the hardware owes more than the users. To run the metric model on your own analytics estate, start with the BI and analytics pillar and the BI Server guide, or engage the advisory practice directly.
Oracle analytics Named User Plus minimums: frequently asked questions
What is the Named User Plus minimum for Oracle analytics?
Oracle analytics products commonly carry a minimum of ten Named User Plus per processor. The licensable count is the greater of the actual authorised users and this per processor floor. See the BI and analytics pillar.
How is the per processor minimum calculated?
Multiply physical cores by the Oracle core factor to get the processor count, then multiply by the per processor minimum. A 2 by 16 core x86 server is 16 processors, giving a floor of 160 Named User Plus at ten per processor.
Why does a small user base sometimes owe a large licence count?
Because the per processor floor is set by hardware, not users. A lightly used system on large hardware can owe the floor even though few people use it. This is the classic Named User Plus trap in analytics.
When should I switch from Named User Plus to Processor?
When the actual user count sits at or below the per processor floor, Processor is usually the better metric, because you are paying the floor anyway. When the user count comfortably exceeds the floor, Named User Plus is usually cheaper.
Does virtualisation affect the Named User Plus minimum?
Yes. Because the floor is derived from the processor count, soft partitioning that inflates the processor count inflates the floor. Establish the partitioning boundary first. See the analytics virtualisation guide.
How do I avoid a minimum based finding?
Compute the floor before choosing the metric, recompute it whenever hardware changes, and choose Processor where the floor exceeds the user count. Our audit defence practice models this in advance.