Oracle licenses: do you really know what you're using... and what you're paying for?

Jean-Michel Alluguette – OP&S
Dec 17, 2025
5 min read

Many companies have been paying for Oracle licenses for years.

They generally know what they have purchased (Enterprise Edition, Standard, some options…), but one question often remains unanswered:

Which Oracle options are actually used today, on what basis, and since when?

And that's where the risk lies.

Because there is a very common scenario:

An Oracle option is activated (by test, by mistake, by tool configuration, by script), then it remains activated.

On a daily basis, nobody notices it.

But on the day of a publisher audit, the bill can become very high.

In this article, we will look at:

Why is this subject so tricky?
the most frequent causes of license discrepancies,
a simple method to regain control,
and how OP&S can help to objectify the situation before it becomes a problem.

Why this topic is so sensitive (and often underestimated)

Oracle is not just a database.

It's an ecosystem of features, options, and packages that can be:

consciously activated (architectural choices),
activated indirectly (tool, parameter, job),
activated during a POC
or activated “for convenience”, then forgotten.

And in many organizations, no one has a consolidated vision:

based
by environment (PROD / pre-prod / DEV),
per period (since when it was activated),
And most importantly: is it actually being used?

The result: we discover it too late.

The 3 classic causes of Oracle license discrepancies

1) Activation “out of curiosity” (or by default)

A DBA, an architect, an application integration team… tests a feature:

“just to see”
“to speed up treatment”
“to make a report”
“for a migration”

Then the environment changes, we go into production, the team rotates… and the option remains.

The catch: it's not necessarily visible to the application.

Everything “works”.

But when it comes to licenses, that's a different story.

2) The POC was never cleaned

This is extremely common:

An option is activated during a POC (or in a project context).
Everyone is focused on the go-live.
and nobody does a "licenses & options" review before switching over.

A few months later:

The option is still there.
and the company has incorporated a “silent” licensing risk.

3) The lack of consolidated visibility (the real problem)

In most companies, information is scattered:

A DBA has a view of their database.
Another team has a view of a different perimeter.
FinOps focuses primarily on infrastructure.
and the purchasing department only sees the contracts.

But a licensing audit requires a cross-functional perspective:

complete park
options enabled,
actual use
historical,
non-production environments (often overlooked),
databases associated with ERP systems (JDE, EBS) or internal applications.

“Used” vs. “Activated”: Costly confusion

The critical point: activating an option does not mean that it is “used” in a business sense.

But for an organization, what matters is knowing:

Which options are enabled?
Which options appear to actually be used?
Is the usage recurring or occasional?
Since when?
On what environments?

In practice, this is the only way to decide:

This is what needs to be rectified.
what needs to be disabled,
what needs to be documented,
and what must be contractually assumed.

Request a free PoC (1 month)

The simple method to regain control (without spending weeks on it)

I recommend a 4-step approach.

Step 1 — Inventory the Oracle infrastructure (completely)

This seems trivial, but it's often the first flaw:

all Oracle databases, all versions,
On-Premise and Cloud,
PRODUCTION and non-PRODUCTION
ERP bases (JD Edwards, E-Business Suite) included,
“Temporary” environments (projects, integrations, sandbox).

Without this inventory, you're missing out on the risks.

Step 2 — List the options/packs activated by database

Objective: to have a simple matrix:

Database

Edition

Options enabled

Activated packs

Environment

This is the step that often reveals surprises, especially in non-production environments.

Step 3 — Correlate with actual usage (and history)

This is where you go from a raw list to a usable view:

Option activated temporarily → risk to be assessed
Option activated “always” → high risk if not covered
Option activated for months/years → structural problem
Option enabled on DEV only → to monitor, but impact differs

Without a history, you can hardly prove anything.

Step 4 — Produce a “licensing” action plan

At this stage, you need to be able to decide quickly:

What do we keep (because it's useful/acceptable)?
What do we disable (because it's unnecessary)?
What do we document (as a precaution)?
What are we escalating in purchases (renegotiation / regularization)?

How OP&S provides concrete assistance

OP&S was designed to avoid this classic scenario:

“We only discover a licensing problem when it’s too late.”

With OP&S you can:

monitor the options enabled across the entire Oracle infrastructure (multi-database, multi-environment)
correlate with usage observed over time
identify at-risk environments (PROD and non-PROD)
generate readable reports for DBA, CISO, internal audit and procurement
be alerted when an option suddenly “appears” (recently activated)

And most importantly: you have a factual basis for internal discussion (and with an editor if necessary).

Example of an automated license audit under OP&S with historical data — Example of automated license audit under OP&S with history

Checklist: 10 points to check now (in 30 minutes)

Do you have a complete list of all your Oracle databases (including non-PROD ones)?
Do you know which databases are in Enterprise Edition vs. Standard?
Do you know the list of options activated by database?
Do you have a history of these activations (since when)?
Do DEV/TEST environments use options not covered?
Were any options activated during a "forgotten" POC?
Do application teams have access to advanced Oracle features without governance?
Do you have a license review procedure after migration/rebuild/upgrade?
Are you able to produce a consolidated report in less than a day?
Do you have a clear plan: disable / document / regulate?

If you check “no” for several points, you have a real topic.

Mistakes to avoid (very common)

Mistake #1: Waiting for the “audit” to act

The day an audit is announced, you no longer have time to work properly:

We panic.
We deactivate it urgently.
We lose traceability,
and we damage the internal relationship between teams.

Mistake #2: only watching the production

Non-production environments are often the riskiest:

more experimentation,
less governance
options activated “just for testing”.

Mistake #3: Confusing “legal” and “real”

Even if you have purchased X licenses, the real question is:

Does your actual usage correspond to your contract?
And can you demonstrate this factually?

Concrete examples encountered with our clients

The "compress=yes" option during Datapump export => ADVANCED COMPRESSION enabled
An IT service provider who runs an AWR report without checking the licenses acquired by their client => Diagnostic Pack activated
SQL Profiles positioned on inefficient SQL_ID queries to fix an execution plan => Tuning Pack enabled
TDE (Transparent Data Encryption) tested to encrypt data files => Advanced Security enabled
Golden Gate deployed in a test environment. Licenses sufficient only for production => Golden Gate activated

Conclusion

Most Oracle licensing problems do not stem from “fraud”:

They stem from a lack of visibility, forgotten POCs, and options activated without governance.

With a simple approach (inventory → activated options → actual usage → action plan), you can:

reduce the risk,
to avoid unpleasant surprises,
and often identify potential cost savings.

A game-changing preventative audit

We offer a free one-month audit with a comprehensive report included.

Useful for:

– audit your compliance,

– prepare for negotiations with the publisher,

– sleep more peacefully