The database engine is only part of the count. Every option and management pack named in your ULA certifies on its own, and the estate that uses them is usually wider than the first pass assumes.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Where they are named in your ULA, Oracle database options such as Partitioning, Real Application Clusters, and Advanced Security, and management packs such as the Diagnostics and Tuning packs, each certify as their own perpetual entitlement, counted on the processors where they run. A count that records the database engine alone leaves whole product lines behind. Maximizing across options and packs means measuring where each one is genuinely deployed, evidencing it, and certifying every named product the estate actually uses.
It is easy to think of a ULA as covering Oracle Database, full stop. In fact the agreement names a specific set of products, and the database options and management packs are separate licensable products in their own right. Partitioning is one product. Real Application Clusters is another. Advanced Security, Advanced Compression, the In Memory option, Active Data Guard, the Diagnostics Pack, and the Tuning Pack are each their own line. When your ULA names them, each one carries its own unlimited right during the term and certifies as its own perpetual entitlement at the end.
This matters because options and packs are licensed on the processors of the database they run on, and they are enabled quietly. There is no install event that announces an option the way standing up a new server does. A feature is switched on, a pack is used through the database console, and the usage accrues without anyone treating it as a deployment. At certification, a count built from a server inventory alone will record the engine and miss the options entirely, which is the same as walking away from permanent licences you are entitled to claim.
Yes, where the ULA names them. The certified count is assembled product by product, and each named option or pack is counted on the processors where it is deployed during the term. A database running on forty eight processors with Partitioning and Advanced Compression in use generates a count for the database engine, a count for Partitioning, and a count for Advanced Compression, each at the relevant processor figure. Treating the engine as the whole story understates the certified position by the value of every option in use.
The same logic applies to clustered and standby estate. Real Application Clusters runs across multiple nodes, and the processors on every node in the cluster carry the option. Active Data Guard sits on standby databases that a production focused count can miss. Each of these is legitimate entitlement when the deployment is real and the evidence exists, and each is routinely left out of a first pass measurement.
Count the products, not the servers. A server inventory tells you where databases run. Only a feature level measurement, reconciled to the products your ULA names, tells you what you are entitled to certify. The options are where the quiet value hides.
Across maximization engagements, the same products are missed again and again, not because they are obscure but because they are invisible to an inventory that looks only at hosts.
The table below shows how a count grows once options and packs are measured alongside the engine for an anonymized example. The figures are indicative and exist to show the logic, not to represent any real engagement. Each option figure reflects only the processors where that product is genuinely deployed and evidenced.
| Named product | Certified processors | Where it is deployed |
|---|---|---|
| Database engine | 1,600 | All production and non production hosts |
| Partitioning | 900 | Data heavy production databases |
| Real Application Clusters | 640 | All nodes in clustered systems |
| Advanced Compression | 700 | Databases using compression features |
| Diagnostics and Tuning packs | 1,200 | Databases managed through the console |
Indicative only. The figure for each product depends entirely on where it is genuinely deployed and on the wording of the specific agreement. The point is that a count built across named products is materially larger and more complete than one built from the engine alone.
The reason to measure options carefully cuts both ways. Inside the term, every named option in genuine use is free permanent value waiting to be certified. After certification, an option enabled on a processor you did not certify is a licence shortfall, and options are exactly where post certification audits find exposure, because they are switched on without anyone noticing. The discipline that maximizes the count before exit is the same discipline that protects you afterward: know precisely which options run where, and make sure the certified entitlement covers them. An option you certify is an option you own. An option you enable later without entitlement is a finding.
This is also why options should never be added artificially just to lift a number. An option certified but not genuinely deployed cannot be evidenced, and an option enabled in the final weeks purely to inflate the count looks exactly like what it is. Maximization here means capturing the real, in use, evidenced footprint of every named product, not manufacturing usage that will not survive scrutiny.
A defensible options and packs count rests on feature usage measurement rather than a host list. The work moves from what is named in the agreement, to what is genuinely in use across the estate, to the evidence that supports each product.
Options and packs are where a maximization plan turns into real permanent value, and where a careless count quietly loses it. Measure feature usage across the whole estate, not just the hosts, and certify every named product the business genuinely uses. To bring forward the deployment those options run on, see planning deployment growth before exit, lock the position at the right moment with the freeze window before certification, and ground the approach in our ULA deployment maximization guide.
Book a ULA assessment and we will measure feature usage across your estate, identify every named option and pack in genuine use, and certify them with evidence behind each figure.