Oracle Database Licensing: Data for Calculating Processor and NUP

The calculation task: what data is needed and why

Oracle Database licensing usually comes down to two questions: how many licenses are needed and which model to use — Processor or Named User Plus (NUP). Mistakes normally don’t come from the formula but from the source data: incomplete information about hardware, virtualization and where Oracle is running.

Processor is calculated from compute resources (processors, cores and Core Factor). NUP is calculated from the people and systems that have access to the database. But even for NUP you first need to understand which servers run Oracle and what minimums apply. So in both cases everything starts with an accurate inventory of installations.

Oracle rarely lives on a single “database server.” More often it’s a set of environments: physical hosts, virtual clusters, test and prod, failover nodes and sometimes a separate DR site. Virtualization also affects the result: in some setups you can limit to allocated resources, while in others you must account for the whole cluster.

It’s useful to separate information into two layers:

• Source data: where Oracle software is installed, CPU characteristics (model, sockets, cores), virtualization type and cluster boundaries, environment membership (prod, test, dev, DR), user and integration access.
• Calculation result: number of Processor licenses after applying the Core Factor, number of NUP (with minimum checks), and the list of nodes and environments included in licensing.

If you start with only “4 servers and about 200 users,” you won’t get a correct calculation. You need specifics: which hosts actually run Oracle, how many cores they have and how virtualization is set up. With that, the calculation becomes repeatable and verifiable.

Briefly about the models: Processor and Named User Plus

Oracle Database has two basic licensing models: Processor and Named User Plus (NUP). The choice determines what data to collect and how to interpret it. It’s important that figures can be backed by documents and exports, not by rough estimates.

Processor: license by computing power

Processor licenses are calculated by the number of processors and cores, taking into account Core Factor coefficients for the specific CPU architecture. The more compute resources allocated to Oracle, the more licenses you need, even if there are few users.

Processor is usually chosen when there are many users or when user numbers change frequently, when external clients connect (portals, mobile apps, partners), when it’s hard to verify the exact number of users, or when there’s a risk of hidden connections through service accounts and integrations.

Named User Plus: license by people/devices

NUP ties to the number of users (or devices) entitled to use the database directly or indirectly. This can be advantageous for closed systems: small staff, limited access and clear roles.

A common divergence is NUP minimums per processor. Even if you have 10 users, the rules may require more licenses because of server capacity. Therefore NUP almost always needs a parallel check: how many minimums result from the hardware.

To properly compare Processor and NUP, prepare in advance:

• an inventory of Oracle installations (which servers, where, which instances);
• CPU and configuration data (with virtualization mapping);
• information about environments (prod, test, dev, DR) and their operating modes;
• details about users and access methods (applications, integrations, service accounts);
• supporting materials: inventory reports, hypervisor exports, architecture descriptions.

When these data are gathered carefully, the calculation becomes mechanical rather than speculative.

Step 1: collect the list of systems and installation points

The first risk is counting the wrong environment. So start not from cores and factors but from listing where Oracle is actually installed or may be present (including admins’ temporary installs).

Collect a list of physical servers, virtual hosts and clusters that host the databases. For virtualization, note not only the guest VMs but also the management layer: hosts, pools, clusters where VM templates are stored and whether migration between nodes is possible.

Next, mark which Oracle components are used. Distinguish editions (EE or SE) and separately record options and packs that were enabled even briefly (for example, “for testing”). Even temporary enabling can affect the calculation.

At the same time label environments: prod, test, dev, stage and DR. The goal is simple: ensure the same database isn’t recorded twice under different names and that DR isn’t hidden as a normal test stand.

Assign data owners. Without responsible people the inventory quickly becomes a list of guesses. Typically you need:

• the application or service owner;
• the OS or virtualization platform administrator;
• the DBA or database owner;
• the infrastructure owner (cluster, storage, site).

Choose a single table format and don’t change it during collection. Minimum columns:

• system (server or VM), site, environment;
• role (DB, app, standby, DR);
• product and Oracle edition;
• list of options and packs (as used);
• installation point (host, VM, cluster), owner and contact.

Example: “DB-PROD-01” as a VM in a vSphere cluster, environment prod, Oracle Database EE, Diagnostic Pack enabled, owner — the ERP team. This detail level is enough to move on to CPU data collection.

Step 2: correctly capture processor and core data

Processor and some NUP checks require physical CPU parameters. Errors here can change license counts by multiples, so treat these numbers like accounting: they must be verifiable.

Collect data for each physical system where Oracle is installed (or could be run). The server record should include: CPU model, number of sockets, cores per socket and total physical cores. Record the CPU model fully (including generation and index) because it affects which Core Factor applies.

Note Hyper-Threading (or SMT) separately. It increases the number of threads but not physical cores. OS reports of “logical processors” often mislead: 16 cores with HT on appear as 32, but Processor calculations usually use physical cores, not threads.

Clarify platform type: a rack server, blade, HCI node or specialized system. This helps avoid confusing the physical host boundary with the chassis or cluster boundary.

It’s best to have at least two independent confirmations:

• BIOS/UEFI data (CPU model, sockets, cores);
• inventory report (CMDB, asset systems, delivery specs);
• server specification or equipment passport;
• serial number and server model.

Record units: physical cores, logical threads, vCPU. A VM may have 8 vCPU while the host has 2 sockets of 12 cores. Processor calculation starts from the host’s physical specs, while vCPU values are useful for describing virtualization and accounting boundaries.

Step 3: Core Factor coefficients and CPU mapping

Core Factor is the coefficient Oracle applies in the Processor model to convert physical cores into Processor license counts. It’s used only for platforms and CPU models listed in the Oracle Core Factor Table. If no factor exists (or a platform has a special rule), the calculation differs. So define which source document you use right away.

The key point is the exact CPU model. “2 sockets and 16 cores” is not enough: different CPU families may have different Core Factors. In your inventory record at minimum: CPU vendor, exact model (as output by the OS or BIOS), sockets, and cores per socket.

Also record which version of the Core Factor Table you used: publication date (or download date) and where the document is stored internally. It’s useful to show this in the table header so no one later recalculates using a different version and gets different results.

If a server contains different CPU types (rare but possible after replacements), do not average. Split the server into rows by CPU group and apply the factor to each group separately.

For a verifiable calculation keep a table with columns:

• host/server, role;
• CPU model, sockets, cores per socket, total cores;
• Core Factor (with source reference);
• final Processor = cores x Core Factor (with Oracle rounding rules applied).

This removes the main cause of disputes: different interpretations of CPU model and factor.

Step 4: describe virtualization and licensing boundaries

Virtualization often breaks calculations because reports describe only the VM and forget the layer above. It’s important to know where Oracle may actually run: on a single VM, on a particular host or across the whole cluster where the VM can migrate.

First separate concepts and document boundaries: physical server (host), hypervisor (technology and version), cluster (hosts that share migration), resource pool, and the specific VMs where Oracle binaries are installed and where databases actually run.

What to record about the virtual environment

Don’t try to list every platform detail. Collect the minimum that affects boundaries:

• virtualization technology and migration modes (is live migration available and where VMs can move);
• cluster composition: list of hosts where the Oracle VM can run;
• VM resource limits: vCPU, limits/reservations, whether there is hard binding to a host;
• placement rules: DRS/auto-placement, affinity/anti-affinity;
• CPU pinning or processor affinity settings, if you use them as a technical boundary.

The key question for the calculation table: “Can this Oracle VM end up on another host without manual reinstall and without breaking policies?” If yes, the boundary usually expands to all possible hosts in the cluster, even if Oracle currently runs on one.

An example to avoid mistakes

There’s a VM DB-PROD on VMware. It currently runs on Host-03, but the cluster has 8 hosts and automatic migration is enabled for load balancing. In source data the boundary should be recorded as “cluster of 8 hosts (list), Oracle installed and used on DB-PROD, VM may migrate to any cluster host.” If hard pinning to two hosts is configured, record that and provide configuration evidence; otherwise the calculation will be contentious.

Do not rely on verbal agreements. Licensing boundaries must be confirmed by configuration and understandable to someone reviewing the table months later.

Step 5: environments, DR and accounting rules

Before calculating, define what you call an environment. Typically these are prod, test, dev, training and DR. Errors here make figures incomparable: people speak about the same thing but mean different things.

For each environment describe its purpose in simple terms: why it exists, who owns it (department and responsible person), when it runs (24/7 or office hours), who has access (admins, developers, contractors), and any connection restrictions.

Mark DR separately (the backup contour). Specify whether it’s hot or cold, how often it’s brought up and whether tests are conducted. For example: “cold DR, started only for incidents, tested quarterly for 4 hours” or “hot DR, synchronous replication, failover test monthly.” Without this one person may count DR as full production while another treats it as an offline reserve.

Avoid mixing concepts. A database can have multiple instances, replicas, a staging instance for upgrades and temporary copies for migrations. Define what counts as a separate installation/use in your calculation and name each contour clearly.

To prevent misunderstandings, agree on unified environment names and stick to them:

• prod, test, dev, training, staging, dr-hot, dr-cold;
• naming convention: system-environment-location (for example, fin-prod-ast);
• rule: names in the CMDB and in the calculation table must match.

Step 6: how to collect data for Named User Plus

For NUP you must collect auditable source data rather than guessing numbers. Count not only employees who connect directly to the database but also those who access it via applications. Also account for technical accounts if they provide database functionality.

First agree on the definition of “user” for your case. Check for direct access (SQL clients, admin tools), access via applications (ERP/CRM/web portals), service integrations (data buses, ETL, monitoring), and shared logins.

Practical sources to export and reconcile:

• IAM/AD: groups that have rights to the application or DB;
• application list and owners: who actually uses features that access Oracle;
• DB accounts: active users, roles, last login times (if available);
• service accounts and integrations: which systems connect and why;
• access documentation: requests, role matrices, procedures.

A common trap is indirect access. If 500 employees work in an application and the application connects to the DB under a single shared account, that does not automatically mean 500 become 1 NUP. Record application entry groups and map them to who can actually obtain data from Oracle.

Record the counting method and the snapshot date (for example, “active users over the last 90 days plus all service integrations”). This simplifies repeat calculations and explanations during audits.

Finally, verify NUP minimums for your chosen edition and scenario (they depend on configuration and Oracle rules). If your calculated number is below the minimum, the minimum applies.

Example: the sales department has 120 users in CRM, the CRM connects to Oracle under one account, plus 3 integrations (ETL, reporting, monitoring). In source data record 120 application users with indirect access and separately note 3 service accounts, then check the minimum and take the larger number.

Typical mistakes that break the calculation

Source-data errors often look minor but quickly lead to extra licenses or under-licensing risk.

The most common confusion is vCPU vs physical cores. Virtualization reports usually show vCPU, but Processor calculations generally require the host’s physical characteristics and CPU model. Without the CPU model you can’t reliably choose a Core Factor.

Infrastructure mistakes

A painful point is incomplete cluster description. People take the single server where the database currently runs and ignore other hosts in the pool. If the VM can migrate, the licensing boundary becomes the whole cluster or pool where migration is allowed.

Another common failure is “the VM is pinned on paper” but admins actually move it across nodes with DRS. Without confirmed restrictions and evidence the calculation will be disputed.

User and environment mistakes

For NUP a typical trap is counting users by active sessions. Usually you must consider everyone who may use the database (including access via applications and service accounts), not only those currently logged in.

People also forget temporary stands and DR. Initially they counted prod, then discovered a copy used for load tests and another DR contour that’s occasionally brought up for exercises. This changes boundaries, metrics and totals.

Quick checklist before calculating

Before counting licenses, verify that source data are complete and consistent. Most errors stem from inventory gaps or different interpretations of boundaries.

Check inventory and hardware

If even one host is missing, the calculation is almost always understated.

• A single list of all places where Oracle is installed or could be deployed: physical servers, virtualization hosts, clusters, migration nodes.
• For each system record sockets, physical cores, exact CPU model and the source of that data.
• For each CPU model determine the Core Factor and note which table and date it was taken from.

Check virtualization, environments and NUP

Agree on rules first, then plug in numbers.

• Virtualization and licensing boundaries are described: where VMs can migrate and which hosts are in the potential pool.
• All environments use the same names across sources (prod, test, dev, DR) and are confirmed by owners, including ambiguous cases (e.g., a test stand that sometimes becomes production).
• DR is described: hot or cold, how often it runs, whether replication exists and who validates the mode.
• For NUP, the counting method and sources are fixed: IAM/AD, HR, app registries, access reports.
• Oracle options and packs that are actually used (not just installed) are noted separately. For example, enabled Partitioning or Diagnostics can change the outcome.

A self-check: if you can open the table and within 30 seconds for any server answer “what CPU model, how many cores, which factor, cluster boundary, environment and data source” then the data are ready.

Example scenario: preparing the source data table

Typical picture: two physical servers in a virtualization cluster, several VMs for Oracle Database for prod and test, plus a separate DR site where VMs are started only for drills or incidents. To avoid disputes, teams first agree on a single “truth table.”

In the inventory table it’s useful to record not only hardware but also licensing boundaries. Minimum fields:

• system (prod/test/dev), site (DC1/DC2/DR) and owner (name/department);
• physical host: CPU model, sockets, cores per socket, HT enabled or not;
• virtualization: cluster/pool, pinning, migration rules, list of possible hosts for the VM;
• VM: vCPU, limits/reservations, actual placement and “possible migration targets”;
• Oracle: edition/options, where installed, where actually running, DR modes (active/passive).

Who confirms data: platform/infrastructure team typically confirms virtualization and cluster boundaries; system engineers confirm CPU and hardware; DBAs confirm actual Oracle use (instances, options, environments).

An intermediate Processor calculation (without numbers) looks like this: determine which physical cores fall inside the licensing boundary (all cluster hosts or only pinned ones), multiply the number of cores by the Core Factor from the Oracle table for the CPU model, then apply Oracle rounding rules to get Processor licenses.

Simultaneously estimate NUP: for each database record who has access (people and service accounts), compare with NUP minimums from Processor and mark risk areas. The common issue is shared application access and integrations.

To close gaps ask owners a few direct questions:

• can the VM migrate to any cluster host and is there a migration ban?;
• is DR always running or only for incidents/tests and how often?;
• which applications and external systems access the database (including batch, API, integrations)?;
• which Oracle options are actually enabled and not just documented as installed?;
• what is considered prod and what is test, and are there prod copies in other environments?

This template usually resolves most disputes about what to count.

Next steps: lock the calculation and keep it current

After you collect cores, factors, virtualization and environments, the result must be “locked.” Errors often stem not from the formula but from no one remembering the source data a month later.

Agree the final dataset and calculation version. Assign an owner for the document (typically the IT license account or platform owner) and a snapshot date for the inventory.

Prepare a confirmation package for internal audit and vendor discussions:

• exports from CMDB/inventory and a list of hosts with installation points;
• CPU and core reports (with CPU model);
• confirmation of virtualization settings and boundaries (clusters, pools, policies);
• environment descriptions (prod, test, dev, DR) and accounting rules;
• materials for contentious spots (for example, pinning settings).

Before closing the calculation, reconcile internally with three parties: IT (actual architecture), security (segmentation and restrictions), and system owners (who and how uses the systems). Discrepancies often surface: a server was migrated, a cluster expanded, but documentation still shows the old state.

To keep the calculation current, agree on update triggers: new host, migration to another cluster, CPU upgrade, change in virtualization policy, added DR site. For each trigger assign a deadline to update data and a responsible person.

If infrastructure changes frequently and licensing becomes unpredictable, discuss with your system integrator options for architectures and servers where boundaries and configurations are easier to control. In Kazakhstan, some projects choose standardized platforms based on locally offered equipment and integrative services such as GSE.kz (gse.kz) to simplify support and documentation of changes.