In a mixed ULA, every database option and management pack is a separate product with its own scope and its own count. Counting them correctly captures real value at certification. Options running outside scope create exposure. The mix has to be read product by product.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Only the options and packs named in the agreement are covered. A mixed ULA typically bundles the Oracle Database with a specific set of options, such as partitioning, advanced security, or a diagnostics and tuning pack, but the unlimited right extends only to the products the contract lists. An option deployed somewhere in your estate that is not named is a separate exposure, even while the ULA is in force. This is the central fact about options in a mixed agreement: the database being in scope does not put every option in scope. The scope list, read product by product, decides what the unlimited right actually covers, and that list is where both the value and the risk live.
Treat each database option and pack as its own product. The named ones are value to maximise at certification; the unnamed ones running in your estate are exposure to find and resolve before exit. The database count and an option count are not the same number, because an option only counts where it is actually enabled and in use.
Each named option is counted on the processors where it is deployed and in use, using the same processor counting and core factor mechanics that apply to the database itself. The important nuance is that an option count can differ from the database count. The database may run on a hundred processors while a given option is enabled on forty of them, so the certified quantity for that option reflects the forty, not the hundred. Getting this right in both directions matters. Undercounting a named option leaves value on the table, since a higher certified count is free value at the ULA support level. Overcounting, or counting an option as in scope when it is not named, inflates a position you cannot actually claim.
Because options are licensed on the processors where they are active, the deployment map for each option is its own piece of evidence. A management pack used across the whole database estate counts widely; a specialised option used on a few critical systems counts narrowly. Treating the option count as automatically equal to the database count is a common error in both directions, and the correction is simply to map each option to the servers where it genuinely runs.
The evidence file for a mixed ULA is not one count but a set of them, one per named product. Server lists, option usage output, and methodology documentation should distinguish the database from each option and pack. This product by product evidence is what supports the certified numbers and what defends them in the audit interest that rises after exit. A single blended figure is weaker than a clean breakdown that shows exactly where each product was deployed.
Options can be enabled inadvertently, and some can switch on by default, on servers where they are neither licensed nor in ULA scope. A diagnostics or tuning pack used through a console, partitioning enabled on a database that did not need it, or an advanced feature toggled on during a project can all create usage that has no entitlement behind it. At certification, or in a later audit, that usage outside scope becomes a remediation demand. The defence is straightforward in principle and disciplined in practice: know exactly which options are enabled on which servers, and switch off any that are not needed and not covered well before exit. An option you turned off and documented is not a liability; an option quietly running where it should not be is.
| Product position | At certification | Action before exit |
|---|---|---|
| Named option, deployed and used | Counts on its processors, free value | Evidence the count, deploy with purpose |
| Named option, lightly used | Counts narrowly | Consider deliberate, useful expansion |
| Unnamed option, running in scope estate | Exposure, not covered | Switch off if not needed, or address it |
| Option enabled by default | Hidden exposure | Audit defaults, disable and document |
Take a mixed ULA, figures indicative only, that names the database and partitioning but not a tuning pack. The database runs on one hundred and twenty processors, partitioning on sixty. Mapped correctly, the buyer certifies a strong partitioning position on the sixty where it runs. Separately, the team finds the tuning pack active on several servers through the console, outside scope. Disabling and documenting it before exit removed a remediation exposure that would otherwise have surfaced at certification.
For the named options, the term is an opportunity. A higher certified count is free value because support stays flat at the ULA level regardless of the number certified, so genuine, useful expansion of a named option before exit converts into a larger perpetual entitlement at no extra support cost. The discipline is that the deployment must be real and useful, capacity you will actually run, not a paper exercise. The same care that protects you from unlicensed options, knowing exactly what runs where, also lets you expand the named ones deliberately and evidence the result cleanly. Read product by product, a mixed ULA rewards the buyer who treats every option as a decision rather than an afterthought.
Options are one piece of a mixed exit that also includes Java and middleware. Read Java ULA renewal pressure in 2026 for how Java is handled alongside the database, and budgeting Java costs after the ULA for the post exit numbers. Our ULA exit strategy guide is the pillar that frames the whole exit across every named product.
Only the options and packs named in the agreement are covered. A mixed ULA often includes the database and a specific set of options such as partitioning or advanced security, but an option deployed in your estate that is not named is a separate exposure. The scope list, product by product, decides what the unlimited right actually covers.
Each named option is counted on the processors where it is deployed and in use, using the same processor counting and core factor mechanics as the database itself. An option enabled on a server counts there, so the certified quantity for an option can differ from the database count depending on where it actually runs.
Options can be enabled inadvertently, sometimes by default, on servers where they are not licensed and not in ULA scope. At certification or in a later audit, usage of an option outside scope becomes a remediation demand. The defence is to know exactly which options are enabled where, and to switch off any that are not needed and not covered before exit.