Field Note · Licensing Compliance

Oracle Named User Plus Counting Rules.

Published May 2024 · Last updated May 2024

The Named User Plus metric is the second Oracle Database licence option after the processor metric. The counting rules cover human users, devices, batch processes, multiplexing, and per processor minimums.

Cluster Licensing ComplianceRead 12 minutesPriority High

The Named User Plus metric is the second principal licence metric for the Oracle Database. The metric counts the population of individuals and devices authorised to access the database. The metric is often cheaper than the processor metric for deployments with a small or stable user population. The metric is also the source of frequent audit disagreements because the definitions are technical and the counting rules cover scenarios that the buyer may not have anticipated at the time of the purchase. This article describes the metric definition, the counting rules for each scenario, and the buyer defence position.

The metric definition.

The Named User Plus metric is defined in the Oracle licensing documentation as the count of individuals authorised to use the programs, regardless of whether the individual is actively using the programs at any time. The metric also counts non human devices that access the programs. A device that reads data from the database or that writes data to the database is a Named User Plus even if the device is a sensor or an automated process. The metric is therefore broader than a count of named human users.

The metric includes both internal users and external users. External users that access the database through a customer facing application are counted. The metric does not include casual users who access publicly available data through an unauthenticated interface. The line between authenticated and unauthenticated access is determined by the technical architecture of the application. The audit position should document the technical architecture for each application that uses the database.

Per processor minimums.

The Named User Plus metric carries a per processor minimum that the buyer must meet regardless of the actual user count. The minimum is twenty five Named User Plus per processor for Database Enterprise Edition. The minimum applies per processor of the server hosting the database, calculated using the same core factor table that applies to the processor metric.

A server with eight Intel cores carries a core factor of 0.5 and produces a processor count of four. The Named User Plus minimum on that server is therefore one hundred. If the actual user population is forty the buyer must still licence one hundred. The per processor minimum often determines the choice between the two metrics. When the actual user count exceeds the per processor minimum the Named User Plus metric is potentially cheaper. When the actual user count is below the minimum the Named User Plus metric provides no advantage over the processor metric.

See the Enterprise Edition discount tactics note for the pricing considerations.

Batch processes and automated users.

Batch processes that access the database are counted as Named User Plus. The audit question is how to count the batch process. The standard Oracle position is that each batch process represents one Named User Plus. A buyer that runs a hundred different batch processes against the database adds a hundred Named User Plus to the count.

Automated users such as integration accounts and service accounts are also counted. Each integration account is a Named User Plus. Buyers that have a large number of service accounts for application integration can find that the Named User Plus count is materially larger than the human user count. The audit position should document each service account and the function it performs. Service accounts that are functionally duplicate can sometimes be consolidated to reduce the count.

Multiplexing and application layers.

Multiplexing is a technical pattern where an application layer acts as an intermediary between human users and the database. The application layer maintains a small pool of database connections and serves a large population of human users through the connection pool. The Oracle position on multiplexing is that the licence count is determined by the population of human users that access the database through the application layer, not by the count of database connections.

The audit position should document the application architecture and the user authentication model. A multiplexed application that has ten thousand authenticated users requires ten thousand Named User Plus licences even if only a hundred database connections are active at any time. The connection pool is irrelevant to the licence count. The user population that the application serves is the source of the count.

Indirect access.

Indirect access is a related question. A user that accesses the database through a downstream system that itself accesses the database is an indirect user. The Oracle position on indirect access has tightened over time. The current position is that any user whose actions cause data to be read from or written to the database is a licensed user, regardless of the path through which the action travels.

The audit position should map the data flow between applications and document which applications use the Oracle database directly and which applications use the database indirectly through another system. Indirect access can extend the licence count to populations that the buyer did not anticipate at the time of the purchase. See the EBS indirect access note for the related considerations in applications.

Device counting and IoT.

Devices that access the database are counted as Named User Plus. The device count has become a significant issue with the growth of Internet of Things deployments. A manufacturing buyer that has ten thousand sensors writing to the database adds ten thousand Named User Plus to the count. The device count can dominate the metric in IoT heavy deployments.

The buyer should consider the device count at the time of the licence purchase. A deployment with a large device population is often better licensed under the processor metric than under the Named User Plus metric. The processor metric is independent of the device count. The choice between the metrics should be made on the projected user and device population over the full term of the licence rather than on the current population.

Engaging an independent advisor.

The Named User Plus position benefits from external technical and licensing expertise. An independent advisor can build the user inventory, the device inventory, and the application architecture map, and can compare the Named User Plus position with the processor position to identify the optimal metric for each deployment.

For the wider cluster see Licensing Compliance. For the service see Contract Review. For the deal structure see the Database licensing page. For the Oracle product see the Oracle Database product page. For the full research read the Oracle Negotiation Playbook white paper.

The audit data request.

The Named User Plus audit typically begins with a request for the user inventory by application. The request asks for the list of human users authorised to access each application that uses the Database, the list of service accounts that integrate with the Database, and the list of devices that connect to the Database. The response should be coordinated and reviewed before submission.

The response should distinguish between authorised users and active users. The Named User Plus metric counts authorised users regardless of activity. A buyer that submits an active user count rather than an authorised user count produces an incorrect response. The response should also distinguish between users that access the Database directly and users that access through downstream systems. Each category should be documented separately.

A worked example.

A North American retail buyer used Database Enterprise Edition on Named User Plus licences for a customer loyalty application. The application had three thousand authorised store employees, eight hundred service accounts for the integration with the point of sale systems, and two thousand devices in store that connected directly to the Database. The buyer had originally licensed two thousand Named User Plus on the assumption that the count was limited to active store employees.

An internal compliance review identified the licensing gap. The actual Named User Plus count was five thousand eight hundred including the service accounts and the devices, against the licensed count of two thousand. The buyer engaged an independent advisor to assess the position. The advisor confirmed the gap and recommended a transition to the processor metric for the customer loyalty application based on the projected device population growth.

The buyer purchased processor licences for the Database servers running the loyalty application and surrendered the Named User Plus licences. The new position was cheaper than topping up the Named User Plus count to cover the device population, and the processor position was independent of the future device count. The transition to the processor metric produced a sustainable compliance position.

Get help on this negotiation Sitting across from Oracle and not sure your numbers are right? Most procurement teams bring in an independent advisor before signing. OracleNegotiations.com sits on your side of the table. We run the analysis, build the counter offer, and negotiate alongside your team. Fixed fee or success fee. We only get paid when you save. Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line. We work alongside them on the most complex ULA exits, audit defence cases, and renewal negotiations.