Options and Management Packs

The Oracle options worked example.

This Oracle options worked example shows a preliminary finding of option usage across 20 processors cut by about 70 percent once each flagged option is tested for genuine production use. The figures are indicative, but the method is the one that reliably reduces real findings.

What is the setup for this worked example?

The setup is an anonymised manufacturing sector estate running Oracle Enterprise Edition across 20 processors, where an audit has produced a preliminary finding of unlicensed option usage. The figures below are indicative and illustrative rather than a specific client, and they are labelled as such throughout. The point of the example is the method, not the numbers: how a frightening preliminary total is reduced to the genuine requirement by testing each flagged option against real usage and the contract. The same approach applies whatever the size of the estate.

The estate had grown over years of ordinary administration. Database administrators had used performance tools, a few tables had been partitioned during a past project, and a compression feature had been switched on once during a migration. None of this was a deliberate licensing decision, but all of it left flags in the feature usage register, and the audit read every flag as a licensable deployment across all 20 processors.

What did the preliminary finding claim?

The preliminary finding claimed four options as fully deployed across all 20 processors at list price, producing a large headline number that assumed every flag meant production reliance. This is the expected shape of a preliminary report: findings arrive inflated at list price, and the options register makes that inflation easy because a single touch and a deep dependency look identical in the data. The table shows the four claimed options and the indicative starting position.

Indicative preliminary finding. Figures illustrative, not a specific client.
Option claimedBasis in the registerClaimed scope
Diagnostics PackPerformance views queriedAll 20 processors
Tuning PackTuning advisor runAll 20 processors
PartitioningPartitioned tables presentAll 20 processors
Advanced CompressionCompression used onceAll 20 processors

What did the line by line review find?

The line by line review found that only one of the four options was genuinely relied on in production, while the other three reflected one time or incidental actions that the evidence could explain. Diagnostics Pack usage traced to a handful of performance investigations on a single server, not continuous monitoring across the estate. Tuning Pack showed one advisor run on the same server, tied to the Diagnostics Pack it depends on. Advanced Compression showed a single detection during a known migration window, with the feature long since disabled. Partitioning, by contrast, was load bearing: several production tables depended on it and could not run without it. For the evidence approach behind this, read used once versus used in production and Diagnostics Pack and Tuning Pack exposure.

The principle to hold

Each flag is a question, not a verdict. Test it against usage history, change records, and the contract. Concede genuine production reliance, and dispute the rest with dated evidence.

What was the result?

The result was that the options requirement fell to Partitioning on the servers that actually used it, with the other three options removed from the claim, reducing the finding by about 70 percent. The reduction was not a negotiation trick. It was the disciplined application of the contract to documented usage: genuine production reliance was acknowledged and licensed, while one time and incidental flags were disputed with timestamps, change records, and proof of disable. This sits squarely in the range independent review usually delivers, where line by line review of preliminary findings typically cuts claims 60 to 80 percent.

Get a Quote

If an options finding has landed, the same method can be applied to your estate, option by option. We reduce your Oracle exposure or we reimburse our service fee, on a Fixed Fee or Gainshare basis with no risk to you. See our database licensing advisory or get a quote.

What is the buyer move?

The buyer move is to treat every option in a finding as a separate, evidenced question, concede only genuine production reliance, and dispute the rest with dated usage evidence read against the contract. Build the usage history for each flag, separate the load bearing features from the incidental ones, and document the disables. Then work the finding down line by line, exactly as this example does. For the surrounding method, read Oracle options and packs, the audit goldmine, work up to the Oracle database licensing guide, and when a finding is live, get a quote.

FAQ

How much can an options finding be reduced? In this example it falls about 70 percent once each flag is tested for genuine production use. Line by line review typically cuts preliminary claims 60 to 80 percent.

What evidence reduces an options finding? Usage timestamps and counts, change records, an account of each action, and proof of disable. That evidence is read against the contract, not the policy paper.

Are the figures real? They are indicative and illustrative, not a specific client. Your own numbers depend on your estate and contract and should be modelled directly.

Next step

Apply the method to your own finding.

Get a quote for a buyer side review that works your options finding down line by line.

The License Position

Read Oracle's next move before they make it.

A short weekly note, buyer side. One development, why it matters, and one move you can make this week.

Buyer side only. Unsubscribe anytime.