Options and Packs Must Match the Database: Why Your Partitioning NUP Can't Be Lower

Oracle's contract says the license count for Partitioning, RAC, Advanced Security and a dozen other options must match the count of the database underneath them, on the same metric, with the same 25 Named User Plus per processor floor. This page shows you the clause, the arithmetic, the audit script that finds the gap, and the three defenses that actually reduce the number.

The Clause: Column A Must Match Column B

The rule is not buried in a policy document Oracle can revise unilaterally. It sits in the ordering documents themselves. The Oracle License and Services Agreement text reads: "The number of licenses for the programs listed below must match the number of licenses of the associated database and if you purchase Named User Plus licenses for these programs, you must maintain, at a minimum, 25 Named Users Plus per Processor per associated database: Real Application Clusters, Partitioning, OLAP, Data Mining, Spatial, Advanced Security, Label Security, Database Vault." That language appears in publicly filed Oracle agreements, including an Oracle USA software license agreement lodged with the SEC as exhibit 10.19. The same construct appears in Oracle's License Definitions and Rules PDF as a two-column table at page 44: the programs in column A must match the number of licenses of the associated program in column B. Column A is your option. Column B is Enterprise Edition underneath it. There is no third column for "how many people actually use it."

Read the sentence structure carefully, because it does two separate things. First, it fixes quantity: option licenses equal database licenses. Second, it independently reimposes the 25 Named User Plus per Processor floor on the option itself, per associated database. So a 16-processor server carrying Partitioning needs 400 NUP of Partitioning at minimum even if the database is licensed at exactly 400 NUP for a user population of 260. The floor is not inherited by reference, it is restated so Oracle can enforce it against the option line independently. The parallel failover clause tightens the ring: the ten separate days per calendar year right extends to Database Enterprise Edition Options, and any use beyond those ten days must be licensed separately using the same license metric. You cannot run a Processor-licensed option against a NUP-licensed primary, or the reverse.

The consequence buyers keep missing is jurisdictional, not technical. This is a purchase-quantity obligation, not a usage obligation. Usage evidence, however meticulous, does not cure a count shortfall. You can prove that only four DBAs ever issued a partitioning DDL statement and the clause still says your Partitioning quantity must equal your database quantity. That distinction determines which defenses work, and we return to it below.

Usage evidence, however meticulous, does not cure a count shortfall.

Why the 'Fewer Option Users' Loophole Was Never Real

The intuitive read is seductive and it is wrong. Two hundred Named Users on the database, fifty of whom touch encrypted columns, therefore buy fifty Advanced Security licenses. Every procurement team we have sat with has proposed some version of this. The reason it fails is that the option is provisioned and made available at the database level, not at the user level. Once Advanced Security is installed and enabled on that instance, the capability is available to all 200 licensed users, and Oracle licenses availability rather than exercise. So a 200 NUP database using Advanced Security requires 200 NUP of Advanced Security. There is no partial licensing of a single database.

The Processor mirror is identical and easier to picture. An option installed on a 16-processor database is licensed for all 16 processors, whether or not every core executes option code. You cannot ring-fence four cores for Partitioning workloads and license those. Hard partitioning of licensing scope inside a single instance does not exist for options. Database Vault deserves a specific flag because customers routinely enable it during a security project and expect a trial window: Oracle's position is same metric, same quantity, no partial licensing, and no evaluation grace period. The moment it is on, it is due, and the discovery views record when.

The multiplier most estates ignore is environments. Production, test, development, disaster recovery and staging each require the option licensed to their own processors or their own users, on the same matching basis, absent a written concession in your ordering document. Practically that means a four-environment estate carrying Partitioning is buying Partitioning four times. Read your DR terms carefully: the ten separate days per calendar year failover allowance is narrow, and standby servers running for anything longer are ordinary licensable environments. If you are reconciling counts across environments, start with our guidance on the accidental-use audit trap in options and management packs, then check your NUP arithmetic against the 25 NUP-per-processor minimum with worked server examples. In our negotiation experience, environment scope is where the largest single line of unbudgeted option exposure sits, and it is also where a written concession is most achievable, because Oracle sells non-production discounts far more readily than it forgives quantity mismatches.

The Arithmetic: 2026 List Prices and the Fixed 1:50 Ratio

The reason the metric-match rule holds up under pressure is not legal drafting, it is arithmetic. Oracle prices every Database line, base and option alike, with Named User Plus at exactly one-fiftieth of the Processor price. Enterprise Edition lists at $47,500 per Processor and $950 per NUP. Partitioning lists at $11,500 per Processor and $230 per NUP. Advanced Compression is identical at $11,500 and $230. Multitenant is $17,500 and $350. Diagnostics Pack is $7,500 and $150, Tuning Pack $5,000 and $100, Database Vault $11,500 and $230. Advanced Security lists at $15,000 per Processor and RAC at $23,000 per Processor. Divide any of those Processor figures by 50 and you land on the NUP figure. That symmetry is deliberate: it means there is no discount arbitrage between metrics, no clever cross-metric split, and no scenario where licensing the option on NUP while licensing the database on Processor produces a legitimate saving. The crossover between NUP and Processor licensing sits at 50 real users per Processor for every one of these lines simultaneously, so the base and the options always flip at the same point.

Now apply the 25 NUP per Processor floor. A 16-core Intel server carries a 0.5 core factor, so 8 Processor licenses, so a minimum of 200 Named User Plus for the database and 200 for each option installed on it. Partitioning at 200 NUP times $230 is $46,000 at list. That is the number, regardless of whether three DBAs or three hundred analysts touch a partitioned table.

Two cautions before you model. First, the Advanced Security and RAC NUP figures above are derived from the published 1:50 ratio, not quoted from a price list line, so confirm them on the document itself. Second, we have seen the Technology Global Price List cited with two 2026 effective dates, April 16, 2026 and August 3, 2026. Pull the live PDF, note the effective date on page one, and cite that version in any calculation you put in front of Oracle. Support at 22 percent of net fee compounds every one of these numbers annually, which is why a Partitioning shortfall never stays a one-time problem.

How Audits Find the Mismatch in Under an Hour

Detection is not forensic work, it is a single view. Oracle's LMS and GLAS scripts read DBA_FEATURE_USAGE_STATISTICS, which records, per feature, the first-use date, the last-use date, the currently used flag and a cumulative usage count. That record survives the objects that created it. Drop every partitioned table on Friday and the row still shows Partitioning with a first-use date in 2019 and a detected usage count of 47 on Monday. Deleting evidence proves nothing except that someone read the script output before the auditor did. The same applies to Diagnostics and Tuning Pack usage triggered by a single Enterprise Manager page view years ago, which is the mechanism behind most accidental option usage findings.

The reconciliation itself is mechanical. The auditor lists installed and used options per instance from the feature usage output, maps each instance to a host and a core count, then lines that up against the entitlement lines in your ordering documents. The comparison is three-way: option present, option quantity, option metric, each tested against the database quantity and metric on that same server. Any row where the three do not agree becomes a finding.

In 25 years of these reconciliations, three findings recur far more than any others. First, the option is licensed on a different metric to the database underneath it, typically Processor database with NUP options bought years apart by different teams. Second, the option quantity sits below the database quantity, usually because someone sized the option to actual users rather than to the 25 NUP per Processor minimum. Third, the option is running in development, test or standby environments that carry no entitlement at all, which is the quietest and often the largest of the three.

Drop every partitioned table on Friday and the feature usage record still shows a 2019 first-use date on Monday.

Your response starts before the script runs. Baseline your own DBA_FEATURE_USAGE_STATISTICS output across every instance, including non-production, and reconcile it against your ordering documents yourself. Findings you discover are negotiable. Findings Oracle discovers are priced.

What the Gap Actually Costs When Oracle Prices It

Oracle does not price a mismatch the way you price a true-up. LMS treats the shortfall as a new purchase at list, then adds backdated support at 22 percent of the net license fee for every year the option was installed, and in my experience the backdating request typically reaches three to five years depending on when the option first appears in the DBA_FEATURE_USAGE_STATISTICS history. Work the arithmetic on a common configuration: 8 processors of Enterprise Edition licensed Named User Plus at 200 users (the 25 NUP per processor floor applied cleanly), with Partitioning purchased at 50 NUP because someone reasoned that only the data warehouse team touched partitioned tables. The clause requires Partitioning at the same quantity, 200 NUP, and the same 25-per-processor floor tests to the same 200. The shortfall is 150 NUP at $230 list, or $34,500. Add first-year support at 22 percent of that, roughly $7,590, then multiply the support by however many years Oracle chooses to backdate: three years of arrears puts the settlement near $57,000 on a purchase the customer thought cost $11,500. Nobody negotiates a discount on arrears.

Scale that logic and the ceiling gets ugly. A 200-processor estate running the full option set (EE, RAC, Partitioning, Advanced Compression, Advanced Security, Diagnostics, Tuning, Active Data Guard) lists at $122,000 per processor, $24.4M total with $5.37M in annual support. At the 55 to 75 percent discounts large enterprises actually achieve, that is $9.8M to $14.6M net and $2.16M to $3.21M of recurring support. The asymmetry is structural: you buy at negotiated discount, Oracle prices findings at list, and support on the finding compounds annually. Read the option quantity rule together with the 25 NUP-per-processor minimum and its worked server examples before you accept any LMS number, because the two rules stack and Oracle applies both.

Three Defenses That Reduce the Number, and One That Doesn't

Rank your responses by how much they actually move the settlement figure, not by how satisfying they feel in the meeting. First, remove the option and prove the removal date. Uninstalling or disabling the feature caps the exposure window; what wins the argument is documentary evidence, change tickets, configuration snapshots, and feature-usage output showing LAST_USAGE_DATE, not a narrative about who intended what. Oracle concedes on dates and never on intent. Second, downgrade the database to Standard Edition 2, which removes the option question entirely: SE2 lists at $17,500 per occupied socket with cores ignored and a 10 NUP per server minimum, and no Enterprise Edition options are permitted on it at all. Verify the socket cap in Oracle's Database Licensing Information manual before you commit, because published guidance conflicts (one commonly cited two-socket-per-server cap against a 16-socket figure elsewhere), and the difference decides whether SE2 is viable on your hardware. Third, consolidate optioned workloads onto fewer and smaller-licensed servers. This is the only defense that cuts both counts at once: shrink the processor footprint and the database NUP falls, and because the option must match the database, the option NUP falls with it automatically.

The defense that does not work is arguing partial user populations. Every practitioner tries it once: only 40 of our 300 users query partitioned tables, only the finance team touches encrypted columns, so license 40 and 60. The clause is quantity-based, not usage-based. The test is what the database is licensed for, not who exercises the feature, and in 25 years across this vendor I have never seen Oracle concede a partial-population argument in a settlement. Save the negotiating capital for the removal date and the discount on the remediation purchase, where Oracle does move. If your dispute involves who counts as a user in the first place rather than how many the option needs, that is a different fight, and the Named User Plus counting rules and audit traps are where to take it.

• Prove the removal date with change records and feature-usage timestamps, not with statements about intent or business need.
• Test SE2 viability against your actual socket count and confirm the cap in the Database Licensing Information manual, not in advisory blogs.
• Model consolidation as a paired saving: every processor removed reduces the database count and the matched option count together.
• Drop the partial-population argument early; it costs credibility and Oracle does not settle on it.

What to Do First: A Seven-Day Options Reconciliation

Do this internally, before anyone from Oracle asks. Day one and two: run DBA_FEATURE_USAGE_STATISTICS and DBA_HIGH_WATER_MARK_STATISTICS on every instance you own, including test, dev, QA, training, sandbox and DR standbys. Auditors do not exclude non-production, and neither should your baseline. Day three and four: build a two-column sheet per instance, option quantity and metric on the left, database quantity and metric on the right, sourced from the actual ordering documents rather than the CSI summary. Any row where Partitioning shows 100 NUP against a 200 NUP database, or Advanced Security on Processor against a database on NUP, is a defect that the clause treats as unlicensed use of the option across the whole database. Day five: decide per defect. Disable and document unused options with a dated change record, a ticket number, and the query output proving usage stopped. Correct the metric where the two differ, remembering the 25 NUP per processor floor applies to the option as well as the database, so a 16-core server needs 200 NUP of Partitioning, not 200 of Database and 60 of Partitioning. Day six and seven: quantify the residual shortfall at list, then decide whether to buy it, drop the option, or move that workload. Buy on your calendar, not Oracle's. During an audit, list price applies and discount discretion evaporates.

An options gap you find yourself is a purchasing decision; the same gap found by an auditor is a settlement.

Posture matters as much as arithmetic. Never volunteer an options gap in an audit response: answer the scripts and questions asked, in scope, in writing, and nothing further. If you must acquire the shortfall, route it into an existing renewal, a support reduction discussion, or a ULA negotiation where you hold something Oracle wants. In our negotiation experience, options bought as a standalone remediation order land far worse than the same quantity folded into a larger transaction. Use the accidental-use exposure on options and packs as your framing for that conversation.

Related advisory: the full topic guide.

Frequently asked questions

Can I license Partitioning for fewer Named Users Plus than the database it runs on?

No. Oracle's License and Services Agreement states that the number of licenses for Partitioning must match the number of licenses of the associated database, and if you buy Named User Plus you must maintain a minimum of 25 NUP per processor per associated database. A count below the database count is a shortfall on its face, regardless of how many people actually query partitioned tables.

Does the 25 NUP per processor minimum apply to options as well as the database?

Yes. The minimum is stated in the same clause that requires the quantity match, and Oracle's price list Licensing Rules section makes the customer responsible for maintaining the minimums for every program in the user minimum table. On a 16-core Intel server (8 processor licenses at a 0.5 core factor), Partitioning requires at least 200 NUP, which is $46,000 at the 2026 list price of $230 per NUP.

Can I license the database on Processor and the option on Named User Plus?

No. The metric must match the database metric on the same instance, and where a server hosts multiple instances each instance must be licensed on the same metric. Mixed-metric entitlement lines are one of the fastest findings an auditor produces, because the mismatch is visible in the ordering documents without touching a single script.

If I drop the partitioned tables before the audit script runs, does the usage disappear?

No. DBA_FEATURE_USAGE_STATISTICS records first-use date, last-use date and usage count, and the record survives deletion of the objects that triggered it. Removing the option is still worth doing, but you need dated change records proving when the removal happened, because the historical entry will be in the script output either way.

Do test, development and DR servers need the option licensed too?

Yes, absent a specific written concession in your agreement. Any environment where the option is installed and/or used must be licensed at the same quantity and metric as the database on that server. A staging box running Data Masking needs the pack licensed for all of its processors, and non-production environments are where most option shortfalls actually live.

Is Standard Edition 2 a way to avoid the option-matching problem?

It removes the problem because SE2 does not permit Enterprise Edition options at all. SE2 lists at $17,500 per occupied socket with cores ignored and a 10 NUP per server minimum, so the trade is losing Partitioning, RAC, Advanced Security and the management packs entirely. Verify the socket cap in Oracle's current Database Licensing Information manual, because published third-party figures conflict.