An Oracle ULA certification is only as strong as the evidence behind it. The data room is the inventory, the tool output, the calculations, and the contract mapping that support every processor you declare. Build it before you certify and it defends your number through Oracle's review and the audit window that follows.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
You need a complete inventory of every server and instance running the covered products, the discovery data or tool output that produced it, the processor and core factor calculations that turn that inventory into a count, the treatment of non production and disaster recovery instances, the documentation behind any cloud and virtualized deployments, and a mapping that ties each deployment to the customer, territory, and cloud clauses in your agreement. Assembled together, this is the certification data room. The certified number is the headline. The data room is what makes the headline hold.
The evidence file matters as much as the number. A count you can prove is an asset. A count you cannot prove is an exposure waiting for the next audit. Build the file first, then declare the number it supports.
Start with a definitive list of every Oracle product in scope and every place it runs. This covers the database editions, the options and management packs, and any middleware named in the agreement. For each, record the host, the environment type, the processor configuration, and the deployment date relative to the term. An inventory that is complete is the foundation of a maximised count, because every legitimate deployment you fail to record is entitlement you fail to certify.
Behind the inventory sits the raw discovery. This may be output from your own asset management tooling, from database queries, or, where your contract requires it, from Oracle LMS scripts. The point is traceability: a reviewer or an auditor should be able to follow any line in the inventory back to the data that produced it. Keep the source data, the date it was captured, and a note of the method used to gather it. Discovery that cannot be reproduced is discovery that can be doubted.
Processor counting is where raw server data becomes a license number, and it is governed by core factors that vary by chip. The data room holds the calculation in full: the core counts, the core factor applied to each processor type, and the resulting processor licenses. Showing the working matters because the core factor is a common point of dispute and a common source of error. A transparent calculation is far harder to challenge than a bare total, and it lets you defend the number line by line if you are asked to.
Test, development, and disaster recovery instances deployed within the term are part of the deployment picture, and how they are treated affects both the count and the risk. The data room documents which non production and disaster recovery instances exist, how each is licensed or counted, and the basis for that treatment under your agreement. These environments are routinely overlooked, which means they are routinely a source of both missed entitlement and unmanaged exposure. Documenting them removes both surprises.
Where your count includes public cloud, the data room must prove that each deployment meets the contract conditions. That means evidence of the provider, the instance configuration, and, where the agreement requires it, that the deployment ran for 365 continuous days within the term. Cloud counting is contract specific: many ULAs name AWS and Azure with conditions, some exclude public cloud, and many are silent on GCP, where silence is not inclusion. The documentation has to match what the clause actually allows, not what you hoped it allowed.
Virtualized estates carry their own evidence burden because Oracle treats soft partitioning as not limiting the scope of a deployment. That stance means an entire VMware cluster can, in principle, be drawn into the count. The data room records the cluster topology, the isolation in place, and the documentation that supports whatever counting position you take. Handled carefully, the same partitioning rule that creates risk can be used to your advantage in a maximization context, but only with the evidence to back the position.
The final part ties everything to the agreement. For each deployment, the mapping confirms that the entity is inside the customer definition, the location is inside the territory clause, and the deployment meets any cloud or measurement condition. This is where scope problems surface while there is still time to fix them, before the certification rather than after. A deployment in the wrong entity or an out of scope territory is one of the most common and most fixable issues, and the mapping is how you catch it.
| Component | What it contains | Why it protects you |
|---|---|---|
| Inventory | Products, hosts, environments, dates | Captures the full maximised count |
| Discovery data | Tool output and source records | Makes every line traceable |
| Processor calc | Cores, core factors, totals | Defends the number line by line |
| Non prod and DR | Test, dev, and recovery treatment | Removes overlooked exposure |
| Cloud docs | Provider, config, continuous use proof | Holds cloud volume in the count |
| Virtualization | Topology, isolation, position | Manages the partitioning sweep |
| Contract mapping | Entity, territory, condition checks | Resolves scope before submission |
This structure is indicative. The exact contents your agreement demands depend on your products, your environments, and your clauses, which is why the contract mapping runs alongside every other component rather than after it.
The certification letter is irreversible. Once the count is declared and converted, the unlimited rights end and the number becomes your perpetual entitlement. If the evidence is assembled only after the fact, two risks follow. First, deployments that should have been counted are discovered too late to include them, and that entitlement is lost. Second, when Oracle reviews the certification, or when an audit arrives in the first two years after it, you are building your defense under pressure rather than producing a file you prepared in calm. The data room is cheaper, more complete, and more defensible when it is built ahead of the letter. We describe how Oracle tests it in how Oracle reviews a certification, and how to bring the exit to a clean close in the certification closing checklist.
Consider an indicative manufacturing group certifying out of a database ULA. Its first internal count, drawn from a partial inventory, lands at roughly 1,200 processors. Building the data room properly surfaces a disaster recovery site, a virtualized cluster, and a set of non production instances that were never in the original list, and confirms each sits inside the customer definition and territory. The defensible count rises toward 1,900 processors, an indicative uplift of more than half, at no additional support cost because support stays flat at the ULA level. The difference was not negotiation. It was evidence, found and documented before the number was declared.
The data room is the certification. Assemble the inventory, the discovery behind it, the processor calculation, the non production and disaster recovery treatment, the cloud and virtualization evidence, and the contract mapping before you declare a number, and the number you declare will be both larger and safer. The full sequence sits in our pillar, the Oracle ULA certification guide. The discipline is simple to state and decisive in practice: prove first, then certify.
You need a complete server and instance inventory of the covered products, the tool output or discovery data behind it, processor and core factor calculations, treatment of non production and disaster recovery instances, cloud and virtualization documentation, and a mapping of every deployment to the contract scope. Together this is the evidence file that supports the certified number.
Because the number is only as strong as what stands behind it. A clean evidence file lets you defend the count during Oracle's review and through the audit window that follows certification. Without it, deployments can be questioned and the perpetual entitlement you certified can be put back in dispute.
Book a confidential assessment and we will assemble the data room that maximises your count and defends it after.