Why options are separate products
Oracle Database Enterprise Edition is licensed as a base product, and its options and management packs are licensed on top of it as distinct products, each with its own metric and price. Partitioning, Advanced Compression, Advanced Security, Real Application Clusters, Active Data Guard, In Memory, Multitenant, and the Diagnostics and Tuning Packs are not features that come free with the engine; they are chargeable products that happen to install alongside it. This distinction is the root of most ULA option problems, because the unlimited right attaches to the specific products named on the schedule, not to everything that can be switched on inside the database. The base mechanics are set out in the Oracle ULA pillar guide, and the options themselves are catalogued in the database options and packs guide.
Because options install with the database and are often enabled by default or by a routine configuration choice, usage can begin without any conscious licensing decision. A DBA partitions a large table, a monitoring tool reads from the AWR repository and triggers Diagnostics Pack usage, or a standby is opened read only and invokes Active Data Guard. None of these actions feels like buying software, yet each consumes a licensed product that may or may not be inside the ULA.
Reading the ULA product schedule
The decisive document is the ULA product schedule, the list of products the unlimited right covers. Every option and pack the organisation intends to use must appear on that schedule. If Partitioning is listed, it can be deployed without limit and counted at certification; if it is not, every database using it is partially unlicensed. Reading the schedule precisely, product by product, is therefore one of the first tasks of the term, and ideally one of the last tasks before signing.
The unlimited right is only as wide as the schedule. An option that is not named is not covered, no matter how naturally it seems to belong with the database.
Where a heavily used option is missing from the schedule, the organisation faces a choice: stop using it, license it separately, or negotiate it into the agreement. The cheapest moment to add an option to scope is before signing, when it is one line in a broader negotiation; the most expensive is in an audit, when it is a compliance finding. Mapping actual and planned option usage against the schedule early lets the organisation surface gaps while they are still cheap to close, a discipline that overlaps with the scope vigilance described in the ULA true-up guide.
Which options are most often in and out of scope?
Certain options recur as scope problems because they are both valuable and easy to enable inadvertently.
| Option or pack | How usage starts | Scope risk |
|---|---|---|
| Partitioning | Partitioned table or index created | High, widely used |
| Diagnostics Pack | AWR, ADDM, or performance views accessed | High, often triggered by tools |
| Tuning Pack | SQL Tuning Advisor used | High, depends on Diagnostics |
| Advanced Security | TDE or redaction enabled | Medium, compliance driven |
| Active Data Guard | Standby opened read only | Medium, DR adjacent |
| Real Application Clusters | Clustered database configured | Medium, deliberate |
The Diagnostics and Tuning Packs deserve particular attention because their usage is so easily triggered by monitoring tools and by routine DBA queries against performance views. Many organisations discover in an audit that these packs are in use across databases where no one consciously licensed them, a pattern detailed in the database options audit guide. If these packs are on the ULA schedule, that usage is simply free entitlement; if they are not, it is exposure.
How options count at certification
At certification, in scope options count the same way the database does, on the processor or named user metric defined by the agreement, applying the appropriate core factor where processor based. An option deployed on a given set of processors converts to a perpetual entitlement for that quantity, just like the engine. This means options are part of the deployment maximization opportunity: an in scope option enabled widely during the term produces a correspondingly large perpetual entitlement at no incremental cost.
Options that are not on the schedule cannot be counted, and crucially they cannot be retroactively legitimised by the certification. If an out of scope option has been used during the term, certification does not absorb it; the usage remains a separate licensing question that survives the ULA. This is why scope discipline during the term protects both the count and the post certification compliance position, a relationship explored in the certification guide.
Where option scope creates audit exposure
Audit exposure concentrates at two moments. The first is during the term, when out of scope option usage accumulates silently and would surface if Oracle audited mid term. The second is after certification, when the unlimited right is gone and any option in use beyond the certified in scope quantities, or any out of scope option still running, becomes a live finding. Oracle audit practice routinely examines option and pack usage because it is high value and frequently unlicensed, so the organisation that ignored scope during the term inherits the problem at exactly the moment its protection has lapsed.
The defensive posture is to treat option usage as a controlled configuration item throughout the term, monitored and reconciled against the schedule, so that no out of scope usage accumulates. Where exposure already exists, it is far better addressed proactively than discovered in an audit, which is the core argument of the Oracle audit defence practice.
Governing option usage during the term
Governing options means controlling both enablement and detection. On the enablement side, the organisation should restrict which options can be switched on, aligning the permitted set to the ULA schedule so teams cannot inadvertently use an option that is not covered. On the detection side, it should run periodic checks of actual option and pack usage across the estate, using the same feature usage and option usage views that an Oracle auditor would, to confirm that real usage matches the schedule.
This governance produces a clean certification and a defensible post ULA position. It also informs the renewal decision, because an organisation that knows exactly which options it depends on can decide whether to keep them inside a successor agreement or license them perpetually. That decision is part of the wider endgame handled in the ULA negotiation work, where option scope is one of the levers that shapes both the certified count and the cost of life after the ULA.
The buyer side view
The buyer side view is that the database engine is the easy part and the options are where ULAs are won or lost. The unlimited right is only as wide as the schedule, so the organisation must map every option it uses or plans to use against that schedule, negotiate missing high value options into scope before signing, and govern enablement and detection throughout the term so no out of scope usage accumulates. Done well, in scope options become a large slice of free perpetual entitlement; done badly, out of scope options become the audit finding that outlives the agreement.
Audit your own option and pack usage now against the ULA schedule, read the database options and packs guide for what each product does, and treat options as the licensed products they are rather than features of the database.
Oracle ULA database options: frequently asked questions
Are database options included in an Oracle ULA?
Only the options and packs explicitly listed on the ULA product schedule are covered. Partitioning, Advanced Security, RAC, Active Data Guard, and the Diagnostics and Tuning Packs are separate products, so any not on the schedule is unlicensed. See the ULA pillar guide.
What happens if we use an option not in the ULA scope?
Usage of an out of scope option is unlicensed and is not absorbed by certification. It remains a separate licensing question that survives the ULA and is a common audit finding. See the database options audit guide.
Do in scope options count at certification?
Yes. In scope options count on the same metric as the database, applying the core factor where processor based, so an option enabled widely during the term converts to a large perpetual entitlement at no incremental cost.
Which options are most often used without a licence?
The Diagnostics and Tuning Packs, because monitoring tools and routine DBA queries against performance views trigger them automatically, and Partitioning, because creating a partitioned table is a normal design choice rather than a conscious licensing decision.