What does a ULA worked example actually show?
A ULA worked example shows how the certified quantity at the end of an Unlimited License Agreement converts into perpetual entitlement, and why the deployment you run in the final stretch of the term is the number that matters. An Oracle Unlimited License Agreement, or ULA, grants the right to deploy specified programs without counting during a fixed term, usually three years, in exchange for a fee agreed up front. At the end of the term you certify how much you have deployed, and that certified quantity becomes the perpetual license you keep. The unlimited period is not the prize. The certification is the prize, because it is the only moment the contract turns deployment into a permanent number.
Consider an anonymized manufacturer, mid sized, that signed a three year ULA covering Oracle Database Enterprise Edition and a small set of options. At signing they ran the database on 80 processor cores of physical hardware. The question the worked example answers is simple: what should they walk out with, and how do they make sure they get it. This topic links up to the Oracle license compliance guide for the wider agreement picture, and it sits next to Oracle ULAs in the audit context.
How is the certification count built?
The certification count is built by measuring every included program that is deployed and running at the certification date, then converting that deployment to the contracted metric, which for the database is Processor. Cores are multiplied by the core factor from the core factor table, so the hardware and the factor decide the final number, not a guess. In the worked example, the manufacturer grew through the term and, by the final months, ran Enterprise Edition across 200 cores of standard x86 hardware. At the published core factor of 0.5 for that processor type, 200 cores convert to 100 Processor licenses. That is the figure that would be certified for the database, provided every core was genuinely in use and correctly measured.
| Item | At signing | At certification |
|---|---|---|
| Cores running Enterprise Edition | 80 | 200 |
| Core factor (x86) | 0.5 | 0.5 |
| Processor licenses certified | 40 equivalent | 100 |
The growth from 40 to 100 Processor equivalents is the entire commercial story. Because the ULA fee was fixed at signing, every core added during the term that the business genuinely needed lifts the certified entitlement at no extra license cost. Options follow the same logic and are counted against the database they run on, so a tuning or diagnostics option deployed widely also certifies widely. For the option count mechanics, read reading your Oracle Master Agreement.
The certified quantity is your perpetual entitlement. It is set by what is deployed and running at the certification date, measured against the core factor table, not by what you paid or what you ran at signing.
Where does the value sit, and where is it lost?
The value sits in accurate, complete deployment at the certification date, and it is lost in three ways: programs left undeployed that the business will need, cores miscounted or wrongly excluded, and certification scope that quietly drops a program Oracle later treats as unlicensed. The first is the most common. A team that delays a planned rollout until after the certification date certifies the smaller number and then has to license the rollout separately at list price. The discipline is to bring genuine, planned deployments inside the term, never to deploy programs the business does not need, which only inflates support cost later. For the renewal alternative and how it compares, read the panic ULA and how audits sell agreements.
The certification document itself is the second pressure point. The figure you submit should rest on a measured count you can defend, because once certified it is fixed. Where a program is ambiguous, or where the contract wording on what counts as deployed is unclear, the answer is contract dependent and is resolved before the number is signed. A certification is not a moment to improvise, and the count is reviewed before it leaves your hands.
What is the buyer move?
The buyer move is to plan the certification a full year ahead, deploy every included program the business genuinely needs before the date, count it accurately against the core factor table, and confirm the certification scope in writing before you submit. Treat the certification as the deliverable of the whole agreement, not an afterthought at the end. Decide early whether to certify out or renew, and base that on a worked count rather than the pressure of the clock, because both paths are real and the right one is the one your numbers support. To have your ULA position counted and your certification protected before the date, get a quote, read the ULA advisory service, and reach us through contact. Work up to the Oracle license compliance guide for the standing position.
FAQ
What does a ULA certification count? Every included program deployed and running at the certification date, converted to the contracted metric. That counted quantity becomes your perpetual entitlement.
How do you maximise a ULA exit? Deploy what you genuinely need before the date, count it accurately against the core factor table, and confirm scope in writing. Review the count before you certify.
Is a renewal always right? No. Certifying out is the other path. The decision is contract dependent and should be tested with a worked count before you commit.