Oracle Database Licensing: A Worked Example

What does the example estate look like?

The example estate is four Oracle Database Enterprise Edition deployments on different hardware shapes, which is enough to show every rule that matters without burying the method in detail. Picture a manufacturer running a public order portal on a large server, a finance system used by a fixed team, a small departmental reporting database, and a development copy. Each one needs its own decision because the cheapest licence is settled database by database, never across the estate as a whole. Throughout this walk through the figures are indicative and the rounding rules are real, so the shapes of the answers hold even though your prices will differ. The complete rule set behind every step is in the Oracle Database Licensing Guide.

How do you count Oracle processor licences?

You count Oracle processor licences by taking the physical cores on each licensable host, multiplying by the core factor from the Oracle core factor table, and rounding the result up to the next whole number. The order portal has 16 cores at a 0.5 core factor, which gives 8 Processor licences. The finance system at 8 cores and the same factor gives 4, the reporting database at 4 cores gives 2, and the development copy at 4 cores gives 2. The core factor is the lever most often misread, because it varies by chip and a wrong factor moves the whole count. Always confirm the factor for the exact processor model against the published table rather than assuming the common 0.5, since some chips carry 1.0 and others less. The method itself is mechanical once the factor is right.

How do Named User Plus minimums change the count?

Named User Plus minimums change the count by setting a floor of users per processor, so the requirement becomes the higher of the real user count and that floor. Take the finance system: 4 processors after the core factor, and if the minimum is 25 named users per processor, the floor is 100 Named User Plus licences. With only 40 real users, the system must still be licensed to 100, because the minimum governs. The reporting database at 2 processors carries a 50 user floor, well above its 12 real users, so it too is priced at the minimum. This is exactly where audits find undercounts, customers licensing to the headcount when the contractual floor sits higher. The development copy at 2 processors and a 50 user floor would also hit 50 Named User Plus, against just 5 developers, which immediately suggests Processor may be the wrong question for it.

How do you choose the cheaper metric per database?

You choose the cheaper metric per database by pricing both options and taking the lower one that keeps you compliant, database by database, because there is no estate wide right answer. The order portal has an uncountable public user base, so Named User Plus cannot be measured and Processor is the only honest metric: 8 Processor licences. The finance system compares 4 Processor against 100 Named User Plus, and the cheaper side depends on the relative list prices, so both are priced and the lower wins. The reporting database compares 2 Processor against 50 Named User Plus. The development copy, with 5 developers, looks like a clear Named User Plus case until the 50 user floor lands, at which point 2 Processor may actually be cheaper. The lesson is that the minimum can flip the answer, so you never assume.

Where do options and packs enter the example?

Options and packs enter the example wherever a feature has been enabled on top of Enterprise Edition, because each licensable option is counted on the same processor base as the database under it. If the order portal has Partitioning switched on, that is 8 more Processor licences for Partitioning, matching the database count. If the finance system has Diagnostics Pack or Tuning Pack enabled, often by a single Enterprise Manager click, those packs attach to its 4 processors. Many options install by default and a careless click can light one up, so the worked example is incomplete until you check feature usage on every database. The recount that follows usually finds at least one option enabled and unused, which is a finding you dispute rather than pay. See processor versus Named User Plus for the metric mechanics and right sizing the database estate for removing capacity before you license it.

What does the finished count tell you?

The finished count tells you the true licence requirement for the estate and, just as important, where any audit finding has departed from it, which is the figure you negotiate against. Lay the four databases side by side with their chosen metric, the option counts, and the minimum tests, and you have a defensible position built from the contract and the core factor table rather than from an auditor's opening number. Preliminary findings arrive inflated at list price, and an independent recount of this kind typically cuts the claim by 60 to 80 percent once the wrong core factors, the phantom options, and the metric errors come out. That recount is the work, and it is worth doing before you respond to anything Oracle sends.

What is the next step?

The next step is to run this same four step method across your real estate, or to bring it to us and have the recount done line by line before you reply to a finding. The example shows the shape, but your numbers, your core factors and your contract minimums decide the answer, and small errors compound across many databases. Book a strategy call to walk your estate through the core factor count, the minimum tests and the option check, and to size what a defensible position looks like against any finding already on the table.