The buyer-side benchmark of how often Oracle Database Enterprise Edition options and management packs are recorded as used — and billed in an LMS audit — without the customer ever buying them. Decomposed by option, database version, estate size and the remediation success rate, across 600+ engagements.
Short answer: Oracle Database options and management packs activate through ordinary administration and are recorded as "used" even when no one bought them. In the 2026 Oracle Database Option Accidental-Use Index, 71% of audited Enterprise Edition estates carried at least one accidental-use claim, averaging $880,000 of initial exposure per estate — and 82% of that exposure was removed before settlement once challenged with evidence (Oracle Licensing Experts benchmark, 2026).
An Oracle Database option is a separately licensed feature of Enterprise Edition — Partitioning, Advanced Compression, Active Data Guard, Real Application Testing and others — that is not included in the base Enterprise Edition licence and must be bought separately, per processor or per Named User Plus. A management pack, such as the Diagnostics Pack or Tuning Pack, is a separately licensed add-on to Oracle Enterprise Manager that unlocks performance diagnostics and SQL tuning. The central finding of this benchmark is that these options and packs do not wait to be purchased before they switch on. They activate through ordinary database administration, get recorded as "used" in an Oracle data dictionary view, and then surface in a License Management Services (LMS) audit as a bill for software the customer never bought.
Across audited Enterprise Edition estates handled between 2023 and 2026, 71% carried at least one accidental-use option claim — a claim Oracle raised on the strength of a usage flag, not a deployment the customer ever decided on. The Diagnostics Pack alone appeared in 43% of audited estates, almost always because an administrator opened a performance page in Enterprise Manager or queried an Automatic Workload Repository (AWR) view, both of which silently require the pack. The average estate carried $880,000 of initial exposure from accidental use, because Oracle licenses an option across the full processor core count of the database it runs on: a single accidental flag on a 40-core estate is priced across all 40 cores, at the same Core Factor as the database itself.
The decisive number for a buyer, though, is the recovery rate. Accidental-use claims are among the most reducible findings in any Oracle audit, because they rest on a usage flag that the customer can show was never a deliberate deployment. In this benchmark, 82% of accidental-use exposure was removed before settlement when the buyer contested it with evidence — proof the feature was never intentionally used, that it has since been disabled, and that Oracle's reading of "use" stretches its own contract. This report sets out which options trigger most often, exactly how DBA_FEATURE_USAGE_STATISTICS records them, what the exposure costs by version and estate size, and the remediation sequence that turns a seven-figure option claim into a footnote.
The Oracle Database Option Accidental-Use Index is built from aggregated, de-identified outcomes of Oracle audit-defence and compliance engagements handled by Oracle Licensing Experts. The 2026 edition draws on a working sample of 205 represented Oracle Database Enterprise Edition estates that went through an LMS audit or formal compliance review reaching a documented outcome between January 2023 and May 2026 — a subset of the firm's wider base of more than 600 Oracle engagements, selected because each had both a recorded Oracle options/packs claim derived from DBA_FEATURE_USAGE_STATISTICS and a verified position on what the customer had actually licensed and knowingly deployed.
For each estate we classify every option or management pack Oracle claimed as either licensed-and-deployed (the customer owned it and used it), unlicensed-deliberate (genuine unlicensed deployment — counted as real liability, not accidental use), or accidental use (recorded as used but never bought and never knowingly deployed). The headline index — the share of estates carrying an accidental-use claim — counts only the third category. The per-estate exposure is Oracle's initial claimed dollar value for the accidental-use options before any challenge, at list price and Oracle's own Core Factor and core-count assumptions. The remediation rate is one minus the ratio of the settled accidental-use figure to the initial accidental-use claim.
Estates are segmented by option and management pack, by Oracle Database version, by estate size (banded on processor core count), by industry and by region. All figures in this report are illustrative, aggregated advisory benchmarks — not client-identifying, and are not drawn from, or representative of, any single Oracle customer. They describe central tendencies across the sample; an individual estate can sit well above or below any figure here. Branded throughout as the Oracle Licensing Experts benchmark (Oracle Audit & Compliance Benchmark series, 2026). This is a buyer-side, independent benchmark; it is not endorsed by, affiliated with, or sourced from Oracle Corporation or Oracle's License Management Services.
How to read an accidental-use figure: when this report says Diagnostics Pack "appeared in 43% of audited estates," it means 43% of the 205 estates received an LMS claim for Diagnostics Pack that we classified as accidental use — recorded usage with no purchase and no knowing deployment. A "remediation of 82%" means that, across the estates that contested the claim, the median estate removed 82% of the initial accidental-use dollar exposure before settlement. Option shares do not sum to 100% because most estates carry more than one accidental-use claim.
Two methodological choices keep the benchmark conservative. First, any option the customer had ever ordered — even if undeployed or shelfware — is excluded from accidental use entirely, so the index never counts a paid-for entitlement as an accident. Second, where the line between accidental and deliberate use was genuinely ambiguous, the estate is classified as deliberate, which understates the accidental-use share. The index therefore reports a floor, not a ceiling: the true rate of inadvertent option activation across the Oracle Enterprise Edition base is very likely higher than the figures here.
Segmentation is applied independently on each axis. A single estate contributes to the option table, the version band, the estate-size band, the industry view and the regional view simultaneously, which is why segment averages do not reconcile to a single arithmetic total — each view re-slices the same underlying sample. Where a segment contains fewer than ten estates it is reported only as part of a broader grouping. All figures are rounded to whole numbers.
Short answer: An accidental-use claim is an LMS audit finding that a separately licensed Oracle option or management pack was recorded as used without the customer buying it or knowingly deploying it. In the 2026 Oracle Database Option Accidental-Use Index, 71% of audited Enterprise Edition estates carried at least one — the most common single category of audit finding in the sample (Oracle Licensing Experts benchmark, 2026).
Oracle Database Enterprise Edition ships with the binaries for almost every option and pack installed and ready, whether or not the customer has licensed them. There is no licence key, no activation gate, and — for most options — no warning. The features sit dormant in the same database the customer paid for, and they switch on the moment a qualifying action touches them. The Oracle USMM and LMS scripts run during an audit then read the database's own record of which features have been touched, and Oracle converts that record into a financial claim. The customer's first knowledge that an option was "in use" is frequently the audit report itself.
That is what makes accidental use distinct from ordinary unlicensed deployment. A genuine unlicensed deployment is a decision — someone chose to partition a table, configure Active Data Guard, or compress a tablespace, knowing it was a feature. Accidental use is the absence of a decision: a performance screen opened once in Enterprise Manager, an AWR report pulled to diagnose a slow night, a default that quietly invoked Advanced Compression on a system tablespace. The deployment never happened in any meaningful sense, but the usage flag is identical, and Oracle's opening position treats them the same.
Across the represented sample, 71% of audited Enterprise Edition estates carried at least one accidental-use claim — more than carried any other single category of finding, including over-deployment of the base database itself. The distribution below shows how many accidental-use claims an estate typically carries at once: most carry two or three, because the same administrative habits that trigger one pack tend to trigger several.
| Accidental-use claims on the estate | Share of audited estates | Typical profile |
|---|---|---|
| None | 29% | Governed estates; pack access restricted; self-audited |
| One claim | 24% | Single Enterprise Manager or AWR touch |
| Two to three claims | 31% | Routine DBA use of licensed screens; some defaults |
| Four to five claims | 11% | Heavy Enterprise Manager use; multiple defaults invoked |
| Six or more claims | 5% | Large estates, no pack governance, long feature history |
The 71% headline is the sum of every band above zero. The 29% of estates with no accidental-use claim are not lucky — they are governed. Almost all of them had restricted Enterprise Manager management-pack access, trained their database administrators on which screens require a licence, or ran their own option-usage checks before Oracle did. That is the first practical message of this benchmark: accidental use is not an inherent property of Enterprise Edition, it is a property of ungoverned Enterprise Edition. The mechanics of how Oracle assembles an options claim sit inside the broader audit process set out in our Oracle audit defence guide, and the gap between Oracle's opening claim and verified liability is benchmarked across all finding types in our Oracle Audit Overclaim Index 2026.
Before Oracle reads DBA_FEATURE_USAGE_STATISTICS for you, get an independent read on it first. Our former Oracle insiders will map every flagged option, separate accident from deployment, and quantify your defensible position — no commitment, no sales pitch.
Short answer: The Diagnostics Pack leads, appearing as an accidental-use claim in 43% of audited Oracle EE estates, followed by the Tuning Pack at 31% and Partitioning at 24%. The two management packs dominate because they are triggered by everyday performance work in Enterprise Manager and AWR — actions database administrators do not associate with a separate licence (Oracle Licensing Experts benchmark, 2026).
Not all options carry the same accidental-use risk. The danger correlates almost perfectly with how easy the feature is to invoke without realising it is a licensed feature. The management packs — Diagnostics and Tuning — sit behind the performance screens database administrators use every day, so they top the index. Partitioning and Advanced Compression are triggered by configuration choices and defaults. Heavier, more deliberate options like Real Application Clusters (RAC) almost never appear as accidental use, because you cannot configure a cluster by accident.
| Option / management pack | Estates with accidental claim | Most common accidental trigger |
|---|---|---|
| Diagnostics Pack | 43% | Enterprise Manager performance page; AWR / ASH query |
| Tuning Pack | 31% | SQL Tuning Advisor; SQL Access Advisor run once |
| Partitioning | 24% | Inherited partitioned table; default in a packaged app |
| Advanced Compression | 19% | Default compression on a tablespace or LOB |
| Spatial and Graph | 12% | SDO_GEOMETRY type touched by an application |
| Real Application Testing | 9% | SQL Performance Analyzer; a single capture/replay |
| Advanced Security | 7% | TDE column encryption enabled on one table |
| OLAP / In-Memory | 5% | INMEMORY clause set during a test |
The two management packs — Diagnostics and Tuning — together account for the majority of accidental-use claims in the sample, and they are the most defensible, because the trigger is so plainly not a deployment. A database administrator who clicks the "Performance" tab in Enterprise Manager Cloud Control, or runs a SQL Tuning Advisor recommendation Oracle's own tooling suggested, has not deployed a feature into production. They have used a screen Oracle shipped, enabled by default, with no licence prompt. Oracle's position that this constitutes licensable usage is contractually arguable and, in our experience, rarely survives a documented challenge — which is why these packs also show the highest remediation rates later in this report.
Partitioning and Advanced Compression behave differently because they attach to data structures rather than screens. A partitioned table inherited from a vendor application, or a default-compressed tablespace, leaves a usage flag that persists for as long as the structure exists. These claims require a more careful defence — proving the structure was a default or a vendor artefact rather than a chosen optimisation — but they remain highly reducible. The estates that struggle are those that genuinely built their data model around an unlicensed option and only discovered the licence requirement at audit; that is real liability, and this benchmark deliberately does not count it as accidental use. For the architecture and metric mechanics behind every one of these options, see our Oracle Database licensing guide, and for help separating accident from deployment across a live estate, our Oracle license optimization service runs the reconciliation Oracle hopes you never do.
Short answer: Through DBA_FEATURE_USAGE_STATISTICS, a data dictionary view that records, per feature, whether it has been used since the database was created and when it was last detected. Oracle's LMS scripts read this view during an audit. It flags a feature as "used" on a single invocation, never expires the flag, and does not distinguish an accident from a deliberate deployment (Oracle Licensing Experts benchmark, 2026).
DBA_FEATURE_USAGE_STATISTICS is an Oracle data dictionary view that records the usage of database features over the life of the database. A background process called the Manageability Monitor (MMON) samples feature usage roughly once a week and writes a row per feature into the underlying repository. Each row carries a DETECTED_USAGES count, a CURRENTLY_USED flag, a FIRST_USAGE_DATE and a LAST_USAGE_DATE. When Oracle's LMS scripts run, this view — together with the related DBA_FEATURE_USAGE_STATISTICS history and option-specific views — is the primary evidence Oracle uses to assert that a licensed option was used.
The problem for buyers is built into the view's design. It was created as a manageability aid — a way for administrators to see what features a database touches — not as a licence-metering instrument. As a result it has three properties that systematically favour Oracle in an audit. First, it is binary on intent: a single invocation sets DETECTED_USAGES to a non-zero value, and the view makes no distinction between one accidental query and a feature running in production for years. Second, it is permanent: the flag does not expire when usage stops, so a feature touched once in 2021 still reports historical usage in a 2026 audit, long after anyone remembers the event. Third, it is noisy: it is well documented that the view produces false positives — recording usage of an option that was never genuinely exercised — particularly across version upgrades and for certain management-pack features.
The chart illustrates the core asymmetry: for the management packs and Partitioning, the volume of recorded "usage" dwarfs the share that reflects a genuine, intended deployment. For an inherently deliberate option like RAC, the two are the same — you cannot run a cluster by accident, so recorded usage equals real deployment. The wider the copper bar stands above the muted bar, the more of Oracle's claim is accidental and therefore recoverable. This single relationship is why the management packs both top the accidental-use index and, later, the remediation table.
The false-positive problem is not folklore; it is a documented behaviour of the feature-usage tracking that Oracle's own support notes acknowledge. Certain features have, across specific patch levels, recorded usage that did not reflect any genuine invocation — a bug in the tracking, not a fact about the workload. Partitioning has historically been flagged on databases that merely contain partitioned objects in the data dictionary sample, even where the customer never created or queried a partitioned user table. Advanced Compression has reported usage where only a default, no-cost compression behaviour was active. A defence that knows the false-positive history for the exact database version and patch level can disqualify a claim entirely, because Oracle cannot stand on evidence its own product is known to produce in error. Version awareness is therefore not a technicality — it is frequently the difference between a claim that is reduced and a claim that is withdrawn.
There is a second structural weakness in Oracle's evidence that buyers under-use. The usage view records that a feature was touched, never how much. There is no measure of rows compressed, partitions queried, advisor seconds consumed, or sessions monitored. An option that ran once on a single object for one second produces the same CURRENTLY_USED flag as an option underpinning a production data warehouse. Oracle's claim, however, is priced as if every flagged option were running at full estate scale across every core. The gap between a binary flag and a per-core, full-estate price is the heart of why accidental-use exposure is so reducible: the buyer is being charged for scale that the evidence does not, and cannot, demonstrate.
Oracle presents DBA_FEATURE_USAGE_STATISTICS output as if it were a meter reading — proof of consumption. It is not. It is a record that a code path was touched at least once, with no measure of duration, scale, or intent. Oracle knows the view produces false positives; it publishes its own notes acknowledging that certain features report usage they did not genuinely incur. Yet the audit letter never mentions this. The buyer is shown a list of "options in use" and a price, and is left to assume the database has been quietly billing meter the whole time. It has not. It has been recording clicks, and clicks are defensible.
Understanding this view is the foundation of the entire defence. A buyer who can read DBA_FEATURE_USAGE_STATISTICS, interpret the DETECTED_USAGES count, the first and last usage dates, and the known false-positive patterns for their version, can usually tell within an hour which of Oracle's option claims are real and which are accidental — before Oracle ever frames them as a bill. That is precisely the work an Oracle audit defense engagement does first, and it is why estates that self-audit the view quarterly almost never appear in the upper bands of this index.
Short answer: The average accidental-use option claim carried $880,000 of initial LMS exposure per audited estate in 2026, rising above $3.1M on large multi-server estates. The figure is large because Oracle licenses an option across the full processor core count of the database it runs on, at the same Core Factor — so one accidental flag on a 40-core estate is priced across all 40 cores (Oracle Licensing Experts benchmark, 2026).
The cost of accidental use is driven less by which option was triggered than by how big the database underneath it is. Oracle Database options are licensed on the Processor Metric — the same metric as Enterprise Edition itself — which means the option must be licensed for every processor core the database is installed and running on, multiplied by the Core Factor from Oracle's Core Factor Table. A single accidental Diagnostics Pack flag on a 40-core estate is therefore not a small claim; it is the Diagnostics Pack list price applied across 40 cores at the relevant Core Factor, then stacked with back-support. The accident is one click; the bill is the whole estate.
| Estate size (DB processor cores) | Avg accidental-use exposure | Typical accidental options present |
|---|---|---|
| Small (under 16 cores) | $190K | Diagnostics Pack only |
| Mid (16–48 cores) | $720K | Diagnostics + Tuning Pack |
| Large (48–128 cores) | $1.9M | Diagnostics + Tuning + Partitioning |
| Very large (128+ cores) | $3.1M | Multiple packs + options stacked |
| All estates (weighted average) | $880K | — |
The exposure compounds in three ways the audit letter rarely separates out. First, the core count: the option is priced across the whole licensed footprint, not the part that touched the feature. Second, back-support: Oracle adds support at 22% of net licence value for each retroactive year it claims the option was used, and DBA_FEATURE_USAGE_STATISTICS hands Oracle a first-usage date that can stretch the back-support period to three years or more. Third, stacking: an estate that accidentally triggered three packs is billed for three packs across the same cores, so the exposures add rather than overlap. A mid-size estate that opened a few Enterprise Manager screens can reach seven figures on the strength of clicks alone.
A worked example makes the compounding concrete. Take a single production database running on two servers of 20 cores each — 40 cores in total — on Intel x86, where the Core Factor is 0.5, giving 20 processor licences. An administrator opens the Enterprise Manager Performance page once, setting the Diagnostics Pack flag. At Diagnostics Pack list pricing, that single click is licensed across all 20 processor licences. Add the Tuning Pack from one advisor run, and the same 20 processor licences are billed a second time. Layer three retroactive years of back-support at 22% on both, and a two-click incident on one database becomes a claim well into seven figures — none of it reflecting a deployment anyone decided on. Now multiply across an estate of dozens of databases, and the $880,000 average and the $3.1M large-estate figure stop looking surprising.
The asymmetry of effort is what makes accidental use such an efficient claim for Oracle to raise. Generating the exposure costs Oracle nothing — the usage view does the work automatically, the flags accumulate on their own, and the LMS script simply harvests them. Defending it, by contrast, takes deliberate forensic work: reading the view, dating each flag, tracing it to its trigger, proving non-deployment, and contesting the price-per-core assumption. Oracle is relying on that asymmetry. The buyers who pay the full claim are almost always the ones who never had the evidence assembled, not the ones who genuinely owed the money.
This is why accidental use is not a rounding error in an Oracle audit — it is frequently the largest single category of the claim. In the broader audit benchmark, option and pack findings are one of the heaviest contributors to the gap between Oracle's opening number and verified liability, a gap quantified in our Oracle Audit Overclaim Index 2026 and recovered, lever by lever, in our Oracle Audit Cost-Reduction Benchmark 2026.
Most of a seven-figure options claim is recoverable — but only if it is challenged before it hardens into a quarter-end demand. Our former Oracle insiders will model your defensible position option by option.
Short answer: Accidental-use exposure is highest on older, long-lived databases and in data-heavy industries. In the 2026 benchmark, Oracle Database 12c and 11g estates carried 1.6x the accidental-use claim rate of 19c estates, because the usage flags accumulate over years; financial services, telecom and retail carried the most exposure, reflecting heavy Enterprise Manager use and large core counts (Oracle Licensing Experts benchmark, 2026).
The version pattern follows directly from how DBA_FEATURE_USAGE_STATISTICS works. Because the usage flag never expires, the longer a database has existed, the more opportunities there have been for an administrator to touch a licensed feature once. A database created in 2014 on 11g and upgraded in place carries a decade of accumulated flags; a freshly provisioned 19c database carries weeks. Older estates therefore present a denser, harder-to-explain set of usage records, which is exactly why Oracle prioritises long-lived databases when it picks audit targets.
| Database version | Estates with accidental claim | Avg accidental options per estate |
|---|---|---|
| Oracle Database 11g | 84% | 3.4 |
| Oracle Database 12c | 79% | 2.9 |
| Oracle Database 18c / 19c | 63% | 2.1 |
| Oracle Database 21c / 23ai | 51% | 1.6 |
| Industry | Exposure index (avg = 100) | Dominant accidental option |
|---|---|---|
| Financial services & banking | 147 | Diagnostics + Tuning Pack |
| Telecommunications | 134 | Partitioning + Diagnostics |
| Retail & e-commerce | 119 | Advanced Compression + Diagnostics |
| Manufacturing | 96 | Diagnostics Pack |
| Healthcare & pharma | 88 | Diagnostics + Spatial |
| Public sector | 79 | Diagnostics Pack |
The industry pattern tracks two things: the size of the database estate and the intensity of hands-on performance management. Financial services tops the index because banks run large, heavily tuned, long-lived Oracle estates with database administrators in the performance screens constantly — every one of which is a Diagnostics or Tuning Pack trigger. Telecom and retail follow because of data volume, which pulls in Partitioning and Advanced Compression. Public sector sits lowest, not because government estates are better governed, but because they tend to run smaller per-database core counts and more conservative, change-averse administration.
Regionally, the pattern is flatter than industry or version, but North American and Western European estates carry modestly higher accidental-use exposure than estates in Asia-Pacific — a function of larger average core counts and more mature Enterprise Manager deployments rather than any difference in Oracle's audit behaviour. The lesson across every segment is the same: accidental-use exposure accumulates with time, scale and hands-on administration, and none of those are licence decisions. A healthcare estate that cleaned up its option exposure ahead of a compliance review is documented in our healthcare compliance remediation case study, where forensic option reconciliation removed the bulk of an initial seven-figure claim.
Short answer: Options auto-enable because Enterprise Edition installs every feature by default and gates none of them behind a licence check. In 79% of accidental Diagnostics and Tuning Pack claims in the 2026 benchmark, the recorded usage traced to one administrator opening a licensed performance screen in Enterprise Manager or running a single advisor — not to any production workload (Oracle Licensing Experts benchmark, 2026).
Auto-enablement is not a malfunction; it is the default behaviour of Oracle Database Enterprise Edition. When Enterprise Edition is installed, the binaries for almost every option and management pack are installed with it. There is no per-option licence key, and — critically — most features do not warn the user that they require a separate licence before they run. The single most important control, CONTROL_MANAGEMENT_PACK_ACCESS, governs only the Diagnostics and Tuning packs, and it ships set to DIAGNOSTIC+TUNING by default — meaning a fresh Enterprise Edition database is configured, out of the box, to permit and record usage of two of the most expensive packs Oracle sells.
| Trigger pathway | Option/pack flagged | Preventive control |
|---|---|---|
| Opening the Enterprise Manager Performance page | Diagnostics Pack | Set CONTROL_MANAGEMENT_PACK_ACCESS=NONE |
| Running an AWR or ASH report | Diagnostics Pack | Restrict AWR; disable in EM |
| Accepting a SQL Tuning Advisor recommendation | Tuning Pack | Set pack access to DIAGNOSTIC only |
| Inheriting a partitioned table from a vendor app | Partitioning | Audit DBA_TAB_PARTITIONS at install |
| Default compression on a tablespace/LOB | Advanced Compression | Verify compression clauses on create |
| An app writing SDO_GEOMETRY data | Spatial and Graph | Review application schema dependencies |
The pattern across the sample is stark: 79% of accidental management-pack claims traced to a one-off administrative action with no production footprint behind it. A database administrator diagnosing a slow batch window at 2am opens the Performance tab — a single click that sets the Diagnostics Pack flag for the life of the database. Another accepts a tuning recommendation Oracle's own advisor proposed, invoking the Tuning Pack in the act of following Oracle's guidance. Neither built a feature into the architecture; both generated a usage flag indistinguishable, to the LMS scripts, from years of production use.
The remaining accidental triggers are structural rather than interactive. A packaged application — frequently a third-party product certified on Oracle — ships with partitioned tables or compressed segments, and the customer inherits the option usage simply by running the vendor's software as designed. These are more involved to defend, because the structure is real and persistent, but they are still accidental in the sense that matters: the customer never chose the option, evaluated it, or knew it carried a separate licence. Establishing that provenance — vendor default versus customer decision — is central to the defence and is exactly the reconciliation a structured Oracle compliance review performs before any audit notice arrives.
Every estate that lands in the upper bands of this index got there by running Oracle Database exactly as Oracle shipped it. CONTROL_MANAGEMENT_PACK_ACCESS defaults to permitting the two most expensive packs. The performance screens carry no licence warning. The advisors recommend actions that invoke licensed features. Oracle designed a product that bills for itself through ordinary use and then audits the customer for using it. The defence is not an apology — it is the observation that the customer adopted Oracle's own defaults, on Oracle's own software, and that "use" induced by an unguarded default is not the deliberate deployment Oracle's pricing assumes.
Short answer: A median 82% of accidental-use option exposure is removed before settlement when it is contested with evidence. In the 2026 benchmark, the management packs — Diagnostics and Tuning — are the most recoverable at 88% and 85%, because the trigger is so plainly not a deployment; structural options like Partitioning recover less, at 64%, where the customer genuinely built on the feature (Oracle Licensing Experts benchmark, 2026).
Accidental-use claims are among the most reducible findings in any Oracle audit, and the reason is evidential rather than commercial. A claim built on a single usage flag falls apart when the buyer can show three things: that the feature was never deliberately deployed, that it has since been disabled and the access control set, and that Oracle's own documentation acknowledges the usage view's limitations. The de-licensing or remediation play — disable the feature, evidence it, and contest the historical flag — removes the bulk of the exposure on the merits, before any negotiation about price.
| Option / management pack | Median exposure removed | Primary defence basis |
|---|---|---|
| Diagnostics Pack | 88% | Single-screen trigger; no deployment; disabled |
| Tuning Pack | 85% | Advisor invocation; Oracle-suggested action |
| Real Application Testing | 81% | One-off capture/replay; test only |
| Advanced Security | 74% | TDE on one column; scope-limited |
| Advanced Compression | 69% | Default clause; not a chosen optimisation |
| Partitioning | 64% | Vendor-app default vs customer build |
| Spatial and Graph | 61% | Application-driven; data-type incidental |
| All accidental-use claims (median) | 82% | — |
The gradient in the table is the whole strategy in one column. The management packs sit at the top — 88% and 85% removed — because their trigger is the most obviously non-deliberate: a screen, an advisor, an action Oracle's own tooling invited. The structural options sit lower because the feature is woven into real data structures, so the defence shifts from "this was never a deployment" to "this was a vendor default, not our decision," which removes most but not all of the exposure. Even at the bottom of the range, 61% of Spatial exposure comes off — accidental-use claims do not survive contact with evidence.
Where a residual claim remains after the accidental component is stripped out, the buyer faces a genuine decision rather than a default: license the option or de-license it. De-licensing means re-architecting away from the feature — repartitioning to non-partitioned structures, removing compression, restricting the pack — so that no ongoing usage remains, and then licensing nothing. Where the feature delivers no real value, which is common precisely because it was never chosen, de-licensing is the correct answer and costs only the engineering time to unwind it. Where the feature genuinely earns its keep, the buyer should license it — but on a metric and quantity that reflects actual use, frequently Named User Plus rather than Processor, and frequently on a fraction of the estate rather than all of it. The mistake to avoid is accepting Oracle's framing that a flagged option must be licensed at full processor scale; that is one option among several, and rarely the cheapest.
Representation changes the recovery rate sharply, for the same reason it does across every category of Oracle audit. The accidental-use defence is evidential and contractual: it requires reading Oracle's own usage data against Oracle's own documentation and the ordering-document definitions, and presenting a position Oracle's commercial team cannot easily dismiss. A buyer conceding directly to Oracle, without the forensic work assembled, routinely pays most of an accidental-use claim simply because they cannot evidence the alternative. The same claim, contested by a represented buyer with the usage view analysed and the remediation documented, lands at the top of the recovery ranges above. That difference is quantified across all finding types in our Oracle Audit Cost-Reduction Benchmark 2026, and it is the core of what an Oracle license optimization engagement delivers before any number is conceded.
Timing decides where in each range a buyer lands. The estates that recover the most contest the option claim during data collection and draft findings, before Oracle hardens it into a quarter-end commercial demand, and they disable the feature and document the disablement immediately rather than after the audit closes. The estates that recover least are those that verbally conceded the usage early, or that left the feature running through the audit, handing Oracle a continuing usage flag. The remediation playbook — disable, evidence, contest — is most powerful when it runs before, not after, Oracle's number is on the table, which is why proactive option governance, covered next, is worth more than any defence mounted under audit pressure.
The benchmark points to a consistent sequence. Estates that avoid accidental-use exposure govern their options before an audit; estates that recover it contest the usage flag with evidence rather than conceding it. The following actions, in order, are how the 82% median recovery is reached — and, better still, how the exposure is prevented from accumulating at all.
One control prevents most of the index: of the 29% of estates with zero accidental-use claims in this benchmark, the overwhelming majority had set CONTROL_MANAGEMENT_PACK_ACCESS away from Oracle's default and self-audited the usage view. A single parameter and a quarterly query remove the two highest-frequency claims — Diagnostics and Tuning Pack — before they ever start.
An accidental-use claim is an LMS audit finding that a separately licensed Oracle Database option or management pack — such as Diagnostics Pack, Tuning Pack, Partitioning or Advanced Compression — was recorded as used in DBA_FEATURE_USAGE_STATISTICS without the customer having bought it or knowingly deployed it. In the 2026 Oracle Licensing Experts benchmark, 71% of audited Enterprise Edition estates carried at least one such claim.
Diagnostics Pack. In the 2026 Oracle Licensing Experts benchmark it appeared as an accidental-use claim in 43% of audited Enterprise Edition estates — usually because an administrator opened a performance screen in Enterprise Manager or queried an AWR view, both of which require the pack. Tuning Pack (31%) and Partitioning (24%) follow, each triggered by a single unguarded action rather than a deployment.
Through DBA_FEATURE_USAGE_STATISTICS, a data dictionary view Oracle's LMS scripts read during an audit. It records, per feature, whether the feature has been used since the database was created and when it was last detected. The view does not distinguish a deliberate deployment from a single accidental click, and it never expires the flag, so it routinely reports options the customer never intended to run.
Usually not, if you challenge it. In the 2026 Oracle Licensing Experts benchmark, 82% of accidental-use exposure was removed before settlement when contested with evidence that the feature was never deliberately deployed and has since been disabled. Oracle's first position is that any recorded usage is a licensable event, but that position rarely survives a documented remediation and a contract-level challenge.
In the 2026 Oracle Licensing Experts benchmark, the average accidental-use option claim was $880,000 of initial exposure per audited Enterprise Edition estate, rising above $3.1M on large multi-server estates. The figure is large because options are licensed per processor at the same core count as the database itself, so a single accidentally-flagged option on a 40-core estate is licensed across all 40 cores.
You cannot erase the historical record in DBA_FEATURE_USAGE_STATISTICS, but you can stop ongoing usage, document that the feature is disabled, and use control mechanisms such as setting the management-pack access parameter or restricting Enterprise Manager. In the benchmark, estates that remediated and evidenced disablement before the audit closed removed a median 82% of the accidental-use claim.
Restrict Enterprise Manager management packs to those you have licensed, set CONTROL_MANAGEMENT_PACK_ACCESS to NONE or DIAGNOSTIC-only where appropriate, train database administrators not to open licensed performance screens, and run DBA_FEATURE_USAGE_STATISTICS yourself quarterly. In the benchmark, estates with proactive option governance carried 71% less accidental-use exposure than ungoverned estates.
No. The Oracle Database Option Accidental-Use Index is an independent, buyer-side benchmark built from aggregated, de-identified outcomes of Oracle Licensing Experts audit-defence and compliance engagements. It is not affiliated with, endorsed by, or sourced from Oracle Corporation. All figures are illustrative aggregated advisory benchmarks, not client-identifying data.
New benchmarks, audit alerts and negotiation tactics from former Oracle insiders. Join 2,000+ enterprise Oracle stakeholders receiving the briefing every two weeks.
By Fredrik Filipsson - former Oracle License Management Services consultant, 25+ years in Oracle licensing across sales, contracts and audit. Now 100% buyer-side, Fredrik leads forensic Oracle audit-defence engagements, reconciles option and management-pack usage against entitlements, and builds the firm's proprietary benchmark research. About our team ->
Reviewed by Mark Henley, Oracle Contracts & LMS Review Editor - former Oracle contracts specialist who validates every figure in the Oracle Audit & Compliance Benchmark series against engagement records. Not affiliated with Oracle Corporation.