The Oracle Database Licensing Calculation Framework
Oracle Database licensing involves two distinct metrics — Processor licences and Named User Plus (NUP) licences — and an organisation must use the metric that produces the higher licence count, or choose the metric that is commercially more favourable based on its specific user and infrastructure profile. The calculation is further complicated by the Core Factor Table, which adjusts processor licence requirements based on chip architecture, and by the Options and Packs layer, which adds significant cost for features used beyond the base database.
The 20 checks below address every calculation dimension in the order a licence calculation should be performed: establish the infrastructure baseline, apply Core Factor Table, select the correct metric, validate Options and Packs, add cloud and support costs, and validate the overall position. Each check identifies where calculation errors most frequently occur in enterprise environments.
Work through each check in sequence — the checks build on each other, and an error in an early step propagates through the entire calculation. High Risk items are those most frequently calculated incorrectly and most likely to create material audit exposure. Medium Risk items affect cost modelling accuracy. Low Risk items are validation and governance checks.
01Has the physical processor count been established for every server running Oracle Database — including idle processors in multi-socket servers that are populated but not actively used?High Risk
Expert NoteOracle's Processor metric requires licensing of every physical processor on a server where Oracle software is installed and/or running — not just active processors. A server with two populated sockets, where Oracle is running single-threaded on Socket 1 while Socket 2 is idle, requires two processor licences. This is the "installed and/or running" rule. Unpopulated socket slots — where no physical processor chip is installed — do not require licensing. The baseline must document physical socket count, not logical CPU count or vCPU count, for every Oracle Database server. For virtualised environments, the baseline extends to all physical processors in the virtualisation cluster under Oracle's soft partitioning rules.
02For virtualised environments on VMware, KVM, Hyper-V, or Nutanix, has the full vSphere cluster boundary been assessed — and has the total physical processor count across all cluster hosts been calculated as the baseline?High Risk
Expert NoteVirtualisation without hard partitioning requires licensing all physical processors in the cluster. A 10-host VMware cluster where each host has 2 physical processors contains 20 processor licences' worth of Oracle requirement — even if Oracle VMs use only 4 vCPUs on 2 hosts at any given time. The DRS (Distributed Resource Scheduler) enables vMotion across cluster hosts, meaning Oracle VMs can theoretically run on any host in the cluster. Oracle's position is that this requires licensing all cluster hosts regardless of actual Oracle VM placement. Document the complete cluster topology — number of hosts, physical processors per host, and whether vMotion is enabled — as the starting point for any processor licence calculation.
03Has the Oracle Processor Core Factor Table been consulted for the specific processor manufacturer, model, and core count of each server — and has the current (2024/2025) version of the table been used?High Risk
Expert NoteThe Oracle Processor Core Factor Table assigns a factor between 0.25 and 1.0 to each processor architecture, which is multiplied by the physical core count to produce the processor licence requirement. Using an outdated version of the table is a common calculation error — Oracle updates the table when new processor families are released, and the factor for a specific AMD EPYC or Intel Ice Lake processor may differ from older versions. The formula is: Processor Licences Required = Physical Cores × Core Factor. For Intel multi-core processors (most common x86 deployments), the factor is 0.5. For IBM POWER processors, the factor ranges from 0.5 to 1.0 depending on generation. Always use the Oracle Technology Global Price List supplementary document — the current Core Factor Table — not the version embedded in older licence management tools.
04For AMD EPYC processors (Rome, Milan, Genoa), has the correct Core Factor of 0.5 been applied — and has the high core count of EPYC processors (up to 192 cores per socket) been factored into the licence calculation?High Risk
Expert NoteAMD EPYC processors use a Core Factor of 0.5, identical to Intel multi-core. However, the practical impact is different due to EPYC's substantially higher core counts. A server with two AMD EPYC 9654 processors (96 cores each) requires: 192 physical cores × 0.5 Core Factor = 96 processor licences. At Oracle EE list price of £47,500 per processor licence, this represents approximately £4.56M in licence costs for a single two-socket server — before Options and Packs. This makes EPYC deployments of Oracle Database Enterprise Edition among the most expensive licensing scenarios in the Oracle portfolio. Organisations migrating Oracle workloads to EPYC-based infrastructure without a licensing review routinely discover they require 2–4× more processor licences than their previous Intel-based deployment.
Has your Oracle Database licensing calculation been independently validated?
Redress Compliance calculates Oracle Database licence requirements across on-premises, virtualised, and cloud environments — independently of Oracle's account team.05Has the NUP metric been evaluated as an alternative to Processor licensing — particularly for low-user-count environments where the NUP minimum (25 NUPs per Processor Licence for EE) may be lower than the actual user count?Medium Risk
Expert NoteOracle's NUP metric requires a minimum of 25 Named Users Plus per processor licence for Enterprise Edition (10 NUPs per processor licence for Standard Edition 2). In environments with fewer than 25 users per processor licence, NUP is effectively priced the same as Processor at minimum — but the calculation differs. For NUP, the count includes every individual authorised to access the Oracle Database, directly or indirectly (through application middleware). In high-user-count environments, Processor is almost always cheaper than NUP. In low-user-count environments with many processors, NUP may be cheaper — but indirect user counting must be performed correctly, as application server users are counted based on all users authorised to use the application, not concurrent users.
06For NUP calculations, have indirect users — users accessing the database through application tiers (EBS, PeopleSoft, custom applications) — been counted as all users authorised to use the application, not just concurrent or active users?High Risk
Expert NoteIndirect user counting is the most common NUP calculation error. Oracle's NUP definition requires counting every individual who has been authorised to access the database — directly or through an application. For an Oracle E-Business Suite deployment with 2,000 provisioned user accounts, the NUP count is 2,000 — not the 300 daily active users, not the 50 concurrent session peak. Organisations that calculate NUP based on active users rather than provisioned/authorised users consistently undercount by 4–10×. When user accounts include batch processing accounts, integration middleware accounts, and reporting tool accounts, every one of these counts as an NUP. Count every account in the application's user directory that has Oracle access privileges.
07For Standard Edition 2 deployments, has the 2-socket per server limit and the 16-thread cap been validated — and has the Oracle Clusterware (OSRAC) restriction on SE2 cluster configuration been confirmed?High Risk
Expert NoteOracle Database Standard Edition 2 has hard limits that are frequently violated in infrastructure refresh projects: SE2 is licensed per socket (not per processor licence metric), is limited to servers with a maximum of 2 populated sockets, and is subject to a 16-CPU thread (hyperthreaded) cap for versions 19c and later (replacing the earlier 16-physical-core cap). Exceeding these limits requires Enterprise Edition licensing retroactively from the point of violation. SE2 Real Application Clusters (via Oracle Database SE HA, the SE2 clustering option) is limited to two-node clusters. Any SE2 deployment on a server with more than 2 sockets — even if only 2 are populated — should be reviewed against Oracle's policy for that specific server model.
08Has an EE vs SE2 decision been formally evaluated based on actual performance requirements, concurrency needs, and the cost differential — including the impact of Options that are only available on EE?Medium Risk
Expert NoteThe EE vs SE2 decision is among the highest-value Oracle licensing decisions an enterprise makes. Oracle Database EE lists at £47,500 per processor licence; SE2 lists at £15,000 per socket licence. For a 2-socket server with Intel processors (0.5 Core Factor, 20 cores per socket), EE requires 20 processor licences (£950,000 list); SE2 requires 2 socket licences (£30,000 list) — a 97% difference. However, EE includes the ability to license Options like Partitioning, Advanced Compression, and RAC (unavailable on SE2), and performs without the SE2 thread cap constraints. The decision requires modelling workload requirements against both options, including the Options layer, before committing to a licence strategy. Many enterprises run SE2 for non-critical databases and EE only for performance-critical or feature-dependent workloads.
09Has DBA_FEATURE_USAGE_STATISTICS been queried on every Enterprise Edition Oracle Database instance to identify which Options and Packs have been used — and has the LAST_SAMPLE_DATE column been used to confirm recent usage?High Risk
Expert NoteDBA_FEATURE_USAGE_STATISTICS is the authoritative source for Oracle Options and Packs usage history. The view records every Oracle feature that has been invoked since database creation, including features enabled automatically by default configuration parameters. The most consequential default is CONTROL_MANAGEMENT_PACK_ACCESS: when set to 'DIAGNOSTIC+TUNING' (the installation default), the database automatically collects AWR snapshots and enables Diagnostics Pack and Tuning Pack features — creating a permanent LAST_SAMPLE_DATE record that Oracle's GLAS team uses as proof of usage. Query this view: SELECT NAME, CURRENTLY_USED, LAST_SAMPLE_DATE FROM DBA_FEATURE_USAGE_STATISTICS WHERE CURRENTLY_USED = 'TRUE' OR DETECTED_USAGES > 0. This is exactly what Oracle's audit team will run — know the answer before they do.
10Has the Diagnostics Pack and Tuning Pack cost been calculated separately — at Oracle list price of £14,750 per processor licence each — for every EE instance where DBA_FEATURE_USAGE_STATISTICS shows usage?High Risk
Expert NoteOracle Diagnostics Pack and Tuning Pack are each priced at approximately £14,750 per processor licence (list price, current as of 2025), in addition to EE base licence cost. For an estate with 50 EE processor licences, Diagnostics Pack adds £737,500 and Tuning Pack adds £737,500 to licence cost — a total of £1.475M in additional licence cost for features that were enabled by default database configuration. This is the financial consequence of leaving CONTROL_MANAGEMENT_PACK_ACCESS at its default value. To remediate without purchasing the Packs: set CONTROL_MANAGEMENT_PACK_ACCESS = 'NONE' and confirm AWR data collection stops (DBA_HIST_SNAPSHOT new rows cease). This remediation must be performed before an Oracle audit notice is received to be effective.
11Have Database Options — Partitioning, Advanced Compression, Real Application Clusters, Active Data Guard, Oracle Multitenant — been individually costed at their respective list prices for each EE instance where DBA_FEATURE_USAGE_STATISTICS confirms usage?High Risk
Expert NoteOracle Database Options carry significant additional cost above the base EE licence. Key Options at list price per processor licence (2025): Partitioning: £11,500; Advanced Compression: £11,500; Real Application Clusters: £23,000; Active Data Guard: £23,000; Oracle Multitenant: £47,500 (same as EE base). A single EE instance using RAC + Partitioning + Active Data Guard adds £57,500 per processor licence to the base EE cost of £47,500 — totalling £105,000 per processor licence. On a 10-processor-licence server, this is a £1.05M commitment above the base database cost. Options usage discovered in DBA_FEATURE_USAGE_STATISTICS cannot be remediated retroactively — it must be licensed from the FIRST_USAGE_DATE.
12Has Oracle Multitenant (container database with multiple pluggable databases) been assessed for licensing — specifically whether the deployment uses more than one PDB, which requires the Multitenant Option on Oracle Database 19c and earlier?Medium Risk
Expert NoteOracle Multitenant licensing changed with Oracle Database 21c (and subsequently 19c with Release Update 19.21+): up to 3 pluggable databases (PDBs) per container database (CDB) are now included in the base EE licence without a separate Multitenant Option licence. More than 3 PDBs require the Multitenant Option. This change is not retroactive to older 19c instances — enterprises running 19c with multiple PDBs before the 19.21 update must evaluate their Multitenant licence exposure based on the version active at the time of PDB creation. Any CDB with more than 3 PDBs must be confirmed either against Multitenant Option entitlement or upgraded to 19.21+ with PDB count reduced to 3 or fewer.
13For Oracle Database on OCI as a cloud service (DBCS, Base Database Service), has the OCPU hourly rate been modelled for both BYOL and Full Use (non-BYOL) pricing — and has the breakeven OCPU-hour usage been calculated?Medium Risk
Expert NoteOCI Database Cloud Service is available in BYOL (customer applies existing perpetual licences) and Full Use (Oracle charges a per-OCPU-hour cloud licence fee). The BYOL OCPU rate is approximately 40–60% cheaper than Full Use. The breakeven calculation determines how many OCPU-hours of cloud database usage make it cost-effective to maintain on-premises perpetual licences (and their 22% annual support cost) versus purchasing Full Use cloud licences. For small cloud deployments, Full Use may be cheaper than maintaining a perpetual licence portfolio. For large, sustained cloud deployments, BYOL with existing licences is almost always cheaper. Model both options over a 3-year and 5-year horizon before committing to licence strategy.
14For AWS RDS Oracle or Azure SQL (Oracle-compatible), has the licence cost been separated from the infrastructure cost — and has the hourly licence charge been annualised and compared against perpetual licence + support cost?Medium Risk
Expert NoteAWS RDS Oracle and Azure Database for Oracle embed Oracle licence costs in the per-hour instance price, making it difficult to isolate the licence component in cost comparisons. For an RDS db.r6i.4xlarge instance (16 vCPUs, Oracle EE included), the Oracle licence element is approximately $4–6 per vCPU-hour — roughly $525,000–$788,000 annually for that single instance. Over 3 years, this exceeds the perpetual BYOL acquisition cost for 8 processor licences. For sustained, predictable database workloads, perpetual BYOL almost always produces lower 3-year TCO than cloud-included licensing. For variable, short-duration, or development workloads, cloud-included licensing eliminates up-front cost and provides flexibility that perpetual cannot match.
15For Oracle Autonomous Database on OCI, has the included Options benefit been quantified — Autonomous Database includes Partitioning, Advanced Compression, Diagnostics Pack, and other features without separate Option licences?Low Risk
Expert NoteOracle Autonomous Database (Autonomous Transaction Processing, Autonomous Data Warehouse) includes multiple features that require separately licensed Options in standard Oracle Database deployments. Under the Autonomous Database cloud service, these features are bundled in the OCPU-hour price: Diagnostics Pack, Tuning Pack, Advanced Compression, Partitioning, and Oracle Machine Learning are included. This bundling can make Autonomous Database significantly more cost-effective than BYOL EE with individual Options, particularly for estates with extensive Options usage. The comparison must be made on a per-workload basis, as Autonomous Database has different performance characteristics and DBA control compared to standard Oracle Database.
16Has Oracle annual support cost been calculated at 22% of the net licence acquisition price — and has the distinction between net (after discount) and list price been applied correctly?Medium Risk
Expert NoteOracle support is invoiced at 22% of net licence acquisition price — the price actually paid for the licence, not the Oracle list price. This distinction matters significantly when calculating support costs on large licence estates acquired at substantial discounts. An enterprise that acquired 100 EE processor licences at a 60% discount (paying £1,900,000 net on £4,750,000 list) pays annual support of £418,000 (22% of net). Support cost compounds annually at Oracle's maximum 5% support increase rate, and Oracle does not allow support cost to be reduced except by licence termination. Model the full 5-year support cost trajectory — not just the first-year cost — when evaluating Oracle licensing scenarios.
17For terminated Oracle licences — where support has been stopped — has the reinstatement cost been calculated: all back-support payments plus a 50% reinstatement fee on the original net licence price?High Risk
Expert NoteOracle's support reinstatement penalty is among the most punitive provisions in the Oracle licensing framework. If an organisation terminates Oracle support and later needs to reinstate it (typically when discovered as non-compliant in an audit, or when requiring version upgrades), Oracle charges: all unpaid support for the period since termination (back-support) plus an additional 50% of the original net licence acquisition price as a reinstatement fee. This makes support termination as a cost-reduction strategy extremely high-risk for any Oracle licence that may need to be reinstated. Model reinstatement cost as a risk scenario before recommending support termination as a cost optimisation measure.
18Has a complete Oracle Database total cost of ownership model been built covering: licence acquisition, annual support, Options and Packs, cloud costs, and migration costs — across a 5-year horizon?Medium Risk
Expert NoteOracle licensing decisions without a 5-year TCO model consistently produce regret outcomes: enterprises choose the lowest first-year cost option without modelling the trajectory. A licence acquisition with 40% discount today generates compounding 22% support cost that, at Oracle's 5% annual increase, grows by 28% over 5 years. Cloud licensing that appears cheaper in Year 1 may become significantly more expensive by Year 3 when the licence cost is annualised against the perpetual alternative. The 5-year model must include: current year licence and support cost, projected support increases, cloud cost trajectory, any migration costs, and the residual value of perpetual licences. This model is the foundation of any Oracle renewal negotiation strategy.
19Has the Oracle Database licence position been reconciled against Oracle's My Oracle Support (MOS) licence records — and have any discrepancies between contractual entitlement and MOS licence records been identified and resolved?Medium Risk
Expert NoteOracle's My Oracle Support is Oracle's system of record for licence entitlement — it is also the source Oracle's GLAS team uses when preparing audit findings. Discrepancies between the contractual order documentation and MOS licence records are more common than enterprises realise: licences may be recorded under incorrect CSI numbers, in incorrect quantities, or with incorrect metric designations. These discrepancies can work in either direction — MOS may show fewer licences than contracted (understating entitlement) or different Options than purchased. An annual MOS licence record reconciliation against original order documentation identifies these discrepancies before they become audit issues.
20Has an independent Oracle Database licensing calculation been reviewed by an adviser who was not involved in the original licence purchase — to provide an objective second opinion on the calculation methodology?Low Risk
Expert NoteOracle Database licensing calculations involve sufficient complexity that independent review is standard practice for any material Oracle estate. An independent reviewer brings three capabilities: a current view of Oracle's calculation methodology as applied in recent GLAS engagements (which may differ from published documentation), an objective assessment of NUP vs Processor metric selection, and identification of calculation errors that are invisible to those within the project. The investment in independent review is modest relative to the licence cost at stake — for an estate with £1M+ annual Oracle spend, a calculation error of 10–20% represents £100,000–£200,000 in annual exposure. Commission an independent calculation review before every major Oracle renewal or significant infrastructure change.
Building an Accurate Oracle Licence Position
An accurate Oracle Database licence position requires working through all 20 calculation dimensions — not just the ones that are convenient or familiar. The errors that create the largest Oracle audit findings are not exotic edge cases; they are systematic calculation gaps: Core Factor Table misapplication, NUP indirect user undercounting, and DBA_FEATURE_USAGE_STATISTICS-documented Options usage that was never licensed. The good news is that all of these gaps are identifiable and, in most cases, remediable before Oracle's GLAS team engages.
The organisations that maintain the lowest Oracle Database licence cost are those that calculate their position accurately, remediate non-compliance before Oracle identifies it, and use their documented licence position as leverage in renewal negotiations. Oracle negotiates from strength when customers don't know their own position — a calculation-validated licence position is the most important commercial tool an enterprise brings to any Oracle negotiation.
Download the Oracle Database Licensing Guide →