Oracle Effective License Position: What It Is and How to Build One

An Effective License Position, or ELP, is the one document an Oracle conversation cannot do without. It sets what you are entitled to run against what you actually run, product by product and metric by metric, and states the difference. Oracle's own auditors produce one at the end of a review. The point of building yours first is that the number in the room is then yours to defend, not theirs to explain.

This guide covers what an ELP for Oracle Database and its options contains, where each input comes from, the four places most positions go wrong, and what a defensible one looks like when it lands on a CFO's desk.

What an ELP is, and what it is not

An ELP is a reconciliation. On one side sit your entitlements: every Oracle ordering document, its product, metric, quantity, term and the contractual definitions that apply to it. On the other side sits your deployment: every installation, the edition and options in use, the hardware it runs on and how that hardware is counted under Oracle's rules. The position is the delta, expressed in the licence metric, with the money attached.

It is not a licence inventory, which lists what you bought. It is not a discovery report, which lists what you installed. And it is not a compliance percentage. A position that says "92% compliant" tells nobody which 8% to fix. A position that says "14 Enterprise Edition processor licences short on the finance cluster, Diagnostics Pack enabled on 9 databases with no entitlement" is a decision document.

The three inputs and where they come from

Entitlements

Start from the ordering documents, not from a spreadsheet someone maintained. Each one carries the metric (Processor or Named User Plus), the quantity, the level of support, and a reference to the master agreement whose definitions govern it. Older agreements can carry metrics that no longer exist, such as Universal Power Units, and conversion ratios you will need. Unlimited License Agreements need their certification date and the products they cover. Migrations, upgrades and support terminations all change what an old line item is worth today.

Deployment

For each database instance you need the edition, the version, the options and management packs that are in use, and the host. Oracle's LMS collection scripts (now the Global Licensing and Advisory Services scripts) remain the reference data source because they are what an auditor will run. They report option usage from the data dictionary, which is where most surprises live: a feature enabled by a DBA to solve a problem in 2021 is still counted in 2026.

Infrastructure

The hardware is where a position is won or lost. Processor licensing counts physical cores multiplied by the core factor for that processor family, and it counts them for every processor where the software is installed and/or running. On a virtualised estate that phrase reaches past the VM to the host, and under Oracle's partitioning policy usually to the whole cluster. You need the cluster membership, the socket and core counts, the CPU model of every host, and the history of where the VM has lived. Read how hypervisor choice changes the count before you trust a VM-level number.

Building the position, step by step

1. Normalise the entitlements. One row per product, metric and agreement, with the definitions that apply. Convert legacy metrics. Mark what is under support and what is not; unsupported licences still count, but they cannot be upgraded.
2. Establish the counting boundary per installation. Physical server, hard-partitioned segment, or cluster. Apply the core factor table to the physical cores inside that boundary. Apply the Standard Edition socket rules where the edition allows them.
3. Attribute usage to entitlements. Match each installation's edition and options to the entitlement that covers it, most favourable first. Options are licensed to the same metric and quantity as the database they run in; a pack in use on a 16-processor database needs 16 processor licences of that pack.
4. Compute the delta per product. Surplus and shortfall are both findings. Surplus is money on the table at renewal; shortfall is the exposure.
5. Price it. List price for the shortfall, and the support uplift that comes with it, because the cost of a shortfall is not the licence but the years of support that follow.

The four places positions go wrong

• Counting the VM instead of the host. A four-vCPU VM on a 64-core cluster is, under Oracle's policy, a 64-core installation unless the partitioning is one Oracle accepts as hard. Read the edition rules as well: SE2 caps sockets, and a cluster over the cap makes SE2 unavailable entirely.
• Ignoring options that were used once. Partitioning, Advanced Compression, Diagnostics and Tuning Packs. The dictionary records use, not intent. A position that lists only options in current use will be corrected by the auditor.
• Trusting the metric on the spreadsheet. Named User Plus has minimums per processor (25 per processor for Enterprise Edition) and the minimum is often the binding number, not the headcount.
• Treating disaster recovery as free. Failover on a cluster is permitted for ten separate days per year on one unlicensed node; standby databases and any form of active data guard are licensed in full.

What a defensible ELP looks like

One page per product with the entitlement, the deployment, the delta and the money, and behind each page the evidence: the ordering documents, the script output, the cluster inventory with dates. Every number traces to a file. The document states its own boundaries and assumptions, including the counting rule applied to each cluster, so that a disagreement with Oracle is about a rule, which can be argued, not about a number, which cannot.

A position is also dated. Estates move, and a six-month-old ELP is a history document. Teams that keep one current do it by making the inputs flow rather than by rebuilding the analysis: the Oracle Database Manager reads the LMS script output and the infrastructure data you already collect and keeps the position, the options usage and the counting boundaries up to date, and NEO's Oracle report turns that position into the document the board and the negotiator read.

Before the next Oracle conversation

• Ordering documents collected and normalised, legacy metrics converted.
• LMS scripts run on every instance, including development and standby.
• Cluster inventory with CPU models, cores and the counting rule you will apply.
• Options and packs attributed to entitlements, unlicensed use listed with dates.
• Shortfall and surplus priced at list, support included.
• Assumptions written down, evidence filed, date on the cover.

An ELP you built is a negotiating position. One you received is an invoice with a cover letter. The work is the same; the only difference is who does it first.