A Database ULA is not one unlimited agreement. It is Enterprise Edition plus a named list of options and management packs, each with its own count, its own enablement trap and its own line at certification.
A Database ULA is not one unlimited agreement. It is Enterprise Edition plus a named list of options and management packs, each of which is a separate program with its own count, its own enablement trap and its own line at certification.
Most guidance on Oracle ULAs is written as though the agreement covers one product. A Database ULA does not.
It covers a stack, and each layer of that stack counts separately, gets enabled separately, and is declared separately at the end. Treat it as one number and you will get the number wrong.
Exactly the programs named in the agreement, at the edition named, and nothing adjacent. The list is usually Enterprise Edition plus a subset of options and management packs.
An option that is not in the schedule is ordinary licensed software, whether or not the database under it is covered. This is the most common gap we find on a Database ULA.
Check every program name against the Oracle technology price list. The names in the agreement have to match the names in that document exactly.
How each layer behaves inside a Database ULA
| Layer | How it is licensed | How it gets used by accident | Certification risk |
|---|---|---|---|
| Enterprise Edition | Per processor or Named User Plus | Rarely. It is deliberate | Low. The base count is visible |
| Options | Per processor, matching the database | A feature switched on for one project | High. Enabled in more places than anyone tracked |
| Management packs | Per processor, matching the target | A single performance report or screen | Highest. Usage without any project behind it |
| Engineered systems | Compute plus separate storage software | Assuming the rack is one product | High. Storage software is often out of scope |
Because they carry a matching rule that the base edition does not. An option must be licensed on every processor on which the underlying database is licensed, so partial coverage is not available.
You cannot license Partitioning on four of the eight processors in a cluster and use it on those four only. If the database is licensed across the cluster, the option follows it across the cluster.
That rule is what makes an option decision expensive outside a ULA and valuable inside one. During the term you can enable freely, and the matching rule costs you nothing.
Diagnostics Pack and Tuning Pack are the two we find most often outside the agreement. Both can be exercised by a database administrator in a few seconds without any project, purchase order or architecture review.
At certification you declare a quantity per program, not one figure for the agreement. A typical Database ULA produces eight to fifteen separate numbers.
Each one can be under declared on its own. The pattern we see is a well evidenced Enterprise Edition count sitting next to option counts that were estimated in an afternoon.
White Paper · Oracle
Oracle Database ULA Negotiation
Negotiate the Database ULA from the buyer side. Read it free.
In processors, not servers and not instances. Cores multiplied by the core factor for that chip, rounded up per machine, then totalled across the estate.
The multiplier comes from Oracle's processor core factor table, which assigns a factor by processor family. Most current x86 server chips carry a factor of 0.5.
Get the chip model right before anything else. A wrong factor applied across a large estate moves the certified number by more than most deployment decisions do.
Oracle's partitioning policy recognizes only certain technologies as capacity limiting. Where it does not, the count follows the physical hardware the software could run on rather than the virtual machine it does run on.
The rounding happens on each server before anything is added together. Counting all the cores in the estate, applying the factor once and rounding at the end produces a materially smaller number than the rule allows.
On a large estate of small servers that error runs in your favor at certification and against you in an audit. Build the count the way Oracle builds it, then argue about the inputs rather than the method.
Standby environments are the most disputed part of a Database ULA certification. The rules differ sharply depending on what the standby actually does.
Deployment in an authorized cloud is counted under Oracle's cloud licensing policy, which uses virtual processors rather than cores and does not apply the core factor table.
Whether those instances can be included in the certified quantity depends on the clause in your agreement, not on the policy. Confirm it in writing before you deploy into cloud for the count.
From inside the databases themselves. Every Oracle database records which separately licensed features have been exercised, and that record is the evidence both sides will end up arguing over.
Detected use is not always real use. A feature can register because a default job touched it, because a vendor application enabled it, or because a single report was generated years ago and never repeated.
Separate genuine use from incidental use, then act on each differently. Genuine use has to be covered, while incidental use should be switched off and documented as stopped.
Run the query estate wide at the start of the term to establish a baseline, then every six months afterwards. The value is in the trend, because a feature that appears on ten databases this year appeared on one at some point.
Store each run with its date and keep it for the life of the agreement plus the audit window. A dated series of your own measurements is a far stronger position than a single count assembled under time pressure.
The metric. A Database ULA is measured against infrastructure, so it moves with hardware, virtualization and resilience decisions that no licensing team controls.
Where the counting problem actually lives
| Dimension | Database ULA | Applications ULA | Java agreement |
|---|---|---|---|
| What is counted | Processors, by core factor | Users, employees or records | Employees, at company level |
| Who moves the number | Infrastructure and platform teams | HR and business growth | HR alone |
| Separate sub programs | Yes. Eight to fifteen typical | Some, by module | No |
| Accidental usage risk | High, via options and packs | Moderate, via module access | Low, the metric is headcount |
| Biggest certification argument | Standby, virtualization, options | User definitions and inactive accounts | Who counts as an employee |
On an applications agreement you can forecast the certified number from a headcount plan. On a database agreement you cannot, because a virtualization change or a resilience project can move it without anyone deploying a new database.
That is why a Database ULA needs a measurement routine during the term, not just at the end. Compare the approach with the general ULA decision framework before you assume the two behave alike.
The common advice is to negotiate the widest possible product list, on the reasoning that anything you might one day need is free once it is inside the agreement. We disagree, and the reason is specific to databases rather than general. Every option you add is a program that can be enabled quietly, must be tracked separately for three years, has to be evidenced separately at certification, and then carries its own support line forever on whatever quantity you declare. A wide list does not create optionality, it creates eight to fifteen tracking obligations your team does not have the tooling to meet. Name the options you have a funded plan to use, and buy the rest later at a worse discount but with a clean count.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Nobody loses a Database ULA on Enterprise Edition. They lose it on a pack that a database administrator enabled in four seconds three years ago.
Five things, and all five are about the count rather than the fee. A discount you win on the fee is spent once, while a counting clause pays every year afterwards.
Build an option and pack usage baseline in the first quarter, then refresh it every six months. The feature usage data lives inside each database and is the only evidence that survives a hostile reading.
Bring the count to a defensible state twelve months before expiry. The mechanics of the declaration itself are set out in the certification guide.
Only the programs named in the schedule, which is normally Enterprise Edition plus a chosen subset of options and management packs. Anything not named is ordinary licensed software even when the database it runs on is fully covered.
Yes. An option must be licensed on every processor on which the underlying database is licensed, so you cannot cover Partitioning or Advanced Compression on part of a cluster and use it only there.
Because they can be exercised in seconds without any project behind them. Generating a workload repository report, querying session history views or opening certain Enterprise Manager pages all constitute use, which is why pack findings appear in most estates we measure.
In processors, calculated as cores multiplied by the core factor for that chip family and rounded up per machine. Most current x86 server processors carry a factor of 0.5, so the chip model has to be confirmed before any counting begins.
It depends on what they do. A standby opened for reporting is an active database requiring Active Data Guard, while a pure failover node attracts a limited unlicensed allowance each year that resilience testing consumes.
Yes, where any part of the estate is licensed on that metric. Enterprise Edition carries a minimum of 25 Named User Plus per processor, and that minimum applies to the quantity you certify rather than disappearing with the agreement.
Only if your agreement says so. Authorized cloud deployment is counted on virtual processors without the core factor, and whether those instances enter the certified quantity is a contract question rather than a policy one.
No. Every extra option is a program that can be enabled quietly, has to be tracked for the whole term, must be evidenced separately at certification and then carries its own permanent support line on whatever you declare.
How to negotiate and certify a Database ULA, the counting traps, and the exit that protects value.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Every ULA ends at a number you declare. The buyers who win are the ones who decide that number long before Oracle asks for it.
