Counting and Evidence · Explainer

Counting Oracle deployments for certification

Oracle deployments are counted mostly by processor, applying a core factor to the cores in scope, with Named User Plus where that metric governs. Production, test, and disaster recovery instances deployed within the term all belong in the count, and leaving any out means losing entitlement permanently.

The count is the heart of a certification. It is the number that becomes your perpetual entitlement, so understanding how it is built is not a technical detail, it is the difference between capturing what you deployed and quietly forfeiting part of it. This guide explains the mechanics of counting for certification, the environments that belong in the number, and the rules that decide them.

How are Oracle deployments counted at ULA certification?

Most Oracle database and option deployments are counted by processor. You take the physical cores in scope, apply Oracle's published core factor for the processor type, and the result is the processor licence count for that environment. Where the Named User Plus metric governs a deployment instead, you count the relevant users plus any devices, subject to the minimums the metric sets. Your agreement tells you which metric applies to which product, so reading the contract comes before counting anything.

The core factor matters because it changes the number materially. Different processor families carry different factors, so the same physical core count can produce different licence counts depending on the hardware. Getting the factor right for each server, and rounding per the agreement, is basic counting hygiene that nonetheless decides whether the total is accurate.

A worked processor count

Take an indicative server with 32 physical cores running a processor type with a core factor of 0.5. The processor licence count is 32 multiplied by 0.5, which is 16. A second server with 16 cores at a factor of 1.0 counts as 16. Together they certify as 32 processor licences. Change the factor and the number changes with it, which is why each server must be assessed on its actual hardware. The figures are indicative and the metric and factors depend on your contract and the current Oracle policy.

Do test and disaster recovery instances count?

Yes, and this is where most under counting happens. Production servers are obvious, so they get counted. Test and development instances deployed within the term are countable too, and they are frequently left out simply because nobody looked. Disaster recovery is the same story. A standby node that was deployed during the term is generally part of your deployed position, yet it is routinely ignored because it is seen as infrastructure rather than entitlement.

Every one of these instances that you fail to count is entitlement you forfeit at the moment you certify. Because there is no fee for certification and support stays at the ULA level regardless of the count, declaring these environments costs you nothing extra in support. They are value you simply keep, provided you can evidence them.

The environments that belong in the count

A complete count reaches across production, test and development, disaster recovery and standby, eligible cloud deployments, and virtualized clusters. Cloud is contract specific, because many agreements require an instance in AWS or Azure to run for 365 continuous days before it counts, and some exclude public cloud entirely. Virtualized clusters carry their own rule, because under Oracle's partitioning stance soft partitioning does not limit scope, which can sweep an entire cluster into the count. Handled deliberately, that rule can increase a defensible count rather than only creating risk.

Why a complete count is usually higher than expected

When all the eligible environments are added with evidence behind them, certified counts often land well above a first pass, commonly in the range of 1.5 to 2.5 times the initial estimate. That figure is indicative and depends on what is genuinely deployed and on the contract. The reason is consistent: first passes count the obvious and miss the rest, while a complete pass captures the test, disaster recovery, cloud, and virtualized deployments that were always part of the position but were never measured.

Where to go next

Once you can count the core estate, the next questions are the trickier metrics and the evidence behind every line. Read counting options and management packs for the products that ride on top of the database, and evidence that supports every number for the file that makes the count defensible. For the full exit, see our Oracle ULA certification guide.

Questions buyers ask about counting

Most database and option deployments are counted by processor, applying Oracle's core factor to the physical cores in scope. Named User Plus applies where that metric governs. Production, test, and disaster recovery instances deployed within the term all belong in the count.

Yes. Test, development, and disaster recovery instances deployed within the ULA term are countable and frequently overlooked. Leaving them out of the declaration means losing entitlement you were entitled to certify and keep permanently.

Strictly confidential

Count every processor you are entitled to keep.

We measure the full estate, apply the right metric and core factors, and capture the environments most counts miss.

Book a ULA assessment