Oracle Database Feature Usage Tracking: How DBA_FEATURE_USAGE_STATISTICS Becomes an Audit Bill

Oracle ships a view that quietly records every option and pack your database has ever touched, and LMS reads it as a bill of materials. This guide shows you how the tracking works, which rows carry real money, where Oracle's own bugs and disclaimers give you defense, and what to fix before the audit notice arrives.

Why One View Decides the Size of Your Oracle Audit Finding

In 25 years of sitting across the table from Oracle LMS and GLAS, I have never seen a single technical artifact carry more financial weight than DBA_FEATURE_USAGE_STATISTICS. The reason is arithmetic, not technology. The view records that a feature was touched; Oracle's licensing rule then requires that the corresponding option be licensed on every processor of the database where it was touched, not on the cores that touched it. So a five-second experiment by a developer becomes a per-processor claim across the whole instance. Run the numbers on 2026 list prices: Enterprise Edition at $47,500 per processor, Partitioning at $11,500, RAC at $23,000, Diagnostics Pack at $7,500, and Tuning Pack at $5,000. Stack a fully optioned EE processor (database plus RAC, Partitioning, Advanced Security, Advanced Compression, Diagnostics, Tuning, and Active Data Guard) and you reach $122,000 per processor list with $26,840 in annual support. Apply that to one 16-core Intel server at the 0.5 core factor, which counts as 8 processors, and you are looking at $976,000 list and roughly $214,720 per year in support from a single box. That is why the view matters more than any contract clause: it is the only place in your estate where a technical event silently converts itself into a bill of materials that Oracle drafted for you. And you cannot fix it by deletion. The rows are cumulative and, in practice, permanent, and tampering with them destroys the credibility you will need in the negotiation. Your leverage is therefore interpretive, not technical. You control which rows are explained, dated, bug-flagged against Oracle's own documented defects, and argued down from "deployed" to "touched once." Start with our breakdown of Oracle Database EE options pricing and the audit trap before you read a single row.

You cannot delete the record, so the only thing left to control is the interpretation.

How the Tracking Actually Works: Sampling, Columns, and Cadence

Read the view the way an auditor reads it, because the auditor's misreading is where most of the money is lost. The tracking is not real time and it is not an audit log of invocations. By default, Oracle runs a feature-checking process every seven days (the Saturday sampling job), and the view only changes after that job completes. You can force a refresh yourself with EXEC DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE), which is exactly what you should do before any self-assessment so you are not arguing over a stale snapshot. The semantics of two columns decide the argument. DETECTED_USAGES counts the number of sampling periods in which usage was detected, not the number of invocations. A row showing 104 detected usages does not mean 104 users hammering Partitioning; it can mean one background job or one scheduled report that ran weekly for two years. Auditors present that number as intensity of deployment. It is not. Equally, CURRENTLY_USED reflects only the most recent sample, so a TRUE tells you the feature fired in the last week and a FALSE tells you nothing at all about the preceding five years, which is precisely why the FIRST_USAGE_DATE and LAST_USAGE_DATE pair matters more than either flag. AUX_COUNT and the FEATURE_INFO CLOB are your best evidence sources: they often carry object counts, user names, and detail that separate a two-object test from a production architecture. Extract all fourteen columns, never a filtered subset, and keep the CLOB.

Two operational instructions follow. First, snapshot the full view on every database, with the CLOB, and store it with a timestamp before Oracle asks for anything, because a baseline you produced first is far harder to dispute than one produced under audit. Second, treat the ratio of DETECTED_USAGES to TOTAL_SAMPLES as your headline metric in every response, since it reframes each row from a binary "used" into a measured frequency. That reframing is the foundation of every position described in our guidance on challenging Oracle audit findings.

The Rule That Multiplies Everything: Options Inherit the Database Metric

Here is the rule that turns a single row in a view into a seven-figure claim: an Oracle option or management pack must be licensed on the same metric and at the same quantity as the database it runs on. There is no partial licensing, no per-core carve-out, no "only the two cores that ran the query." If Partitioning was invoked once on a 16-processor Enterprise Edition database, Oracle's position is a 16-processor Partitioning claim, and that position is consistent with Oracle's own contract language and with every LMS engagement I have worked through in 25 years. The same inheritance applies to Named User Plus. If the database is licensed NUP, the option is licensed NUP, and the 25 NUP per processor minimum flows straight onto the option as well. Buyers routinely assume the NUP path shrinks option exposure. It does not shrink it proportionally, because the floor travels with the metric, not with the user count you actually have.

Work the arithmetic on a representative two-socket Intel server, 8 cores per socket, 16 cores total, core factor 0.5, so 8 licensable processors. Enterprise Edition at $47,500 lists at $380,000. Add Partitioning at $11,500 and you have added $92,000 of list exposure for one DETECTED_USAGES row, plus 22 percent support on top, roughly $20,240 per year, forever. Stack the common set (Diagnostics at $7,500, Tuning at $5,000, Advanced Compression at $11,500) and the option layer alone reaches $280,000 list against a $380,000 database. That is why fully stacked option packs add 40 to 110 percent on top of base database cost. On a NUP-licensed version of the same server, 8 processors forces a minimum of 200 NUP, and Partitioning at $230 per NUP lists at $46,000 whether 12 people or 190 people touch the data. See Oracle Database EE options pricing and the audit trap for how these stacks compound across an estate.

The strategic consequence is where buyers consistently misallocate effort. You cannot negotiate the inheritance rule; it is entitlement, defined by the price list and the OLSA, and Oracle's LMS team has no discretion over it. You can negotiate quantity, and quantity is an architecture decision you control. Consolidating that Partitioning workload onto a 4-processor host, or isolating it on a licensed cluster instead of letting it spread across a 32-core VMware pool, is the move that cuts real money. In our experience advising buyers, footprint reduction reliably removes 15 to 30 percent of cost, while discount-chasing on an audit-driven quote rarely moves the net number at all, because Oracle prices the settlement to the shortfall it has already calculated and then hands back "discount" that lands where it wanted to be.

Entitlement is fixed by contract; quantity is fixed by your architecture, and only one of those two is negotiable.

Practical instruction: before you argue about whether a feature was used, count the processors that would be in scope if Oracle wins the usage argument. That number, not the row itself, is your exposure. If it is large because the database sits on an oversized host or a shared virtual cluster, fix the placement first and negotiate second.

Which Rows Actually Cost Money: Mapping Feature Names to Priced Options and Packs

You do not need a week to triage a feature usage report. You need an hour and a price map, because exposure is concentrated in maybe a dozen feature signatures out of the several hundred rows the view returns. Sort your output by the list price of the option each row maps to, multiply by licensable processors, and you will find that two or three rows carry 80 percent of the claim. Everything else is noise you should not spend negotiation capital on. The table below gives 2026 list prices per processor with NUP equivalents at roughly one fiftieth of processor price, which is the ratio Oracle applies across the option line.

Now the rows that look alarming and are free. Locator is included with Enterprise Edition; only full Spatial functionality is licensable, and Oracle's own bug notes concede that a query against the view "is not a true test for use of SDO." Basic table compression is an EE feature; only OLTP and advanced index or LOB compression trigger Advanced Compression, yet the report will often surface a compression row with no qualifier. RMAN's default BZIP2 backup compression is free, and Oracle documented that as a false positive under Bug 16088534. SecureFiles and Advanced Compression rows generated by default schema users are covered by Bugs 11902001 and 11902142. If a row's AUX_COUNT is zero or its DETECTED_USAGES traces to SYS, MDSYS, or DBSNMP, treat it as a challengeable row, not a liability, and build the evidence file now rather than during the audit call. Our guidance on challenging Oracle audit findings covers how to package that evidence so it survives escalation.

Two practical instructions. First, price your report before you read it: attach the dollar figure to each row so the conversation with your DBAs is about the $92,000 Partitioning row, not the 40 harmless rows next to it. Second, treat Diagnostics and Tuning Pack rows as urgent despite their lower unit price, because they appear on nearly every database in an estate, and $7,500 plus $5,000 across 60 processors is $750,000 of list exposure assembled entirely out of routine performance troubleshooting.

Why Removing the Feature Does Not Remove the Finding

The single most expensive misunderstanding I see on the buyer side is the belief that DBA_FEATURE_USAGE_STATISTICS reports current state. It does not. It is a permanent historical ledger. Drop every partitioned table in the database, and the Partitioning row survives with its FIRST_USAGE_DATE, its LAST_USAGE_DATE, and its DETECTED_USAGES count intact. Oracle's own published behavior confirms this: once a feature appears in the view it is recorded permanently, and features accessed years ago, triggered accidentally, used once in a test, or enabled experimentally all continue to present as used. Partitioning specifically is recorded even after the partitioned objects are gone. LMS scripts read that ledger, not your current schema, and the licensing rule underneath it is unforgiving: an option touched once on a 16 processor database must be licensed on all 16 processors. At $11,500 per processor list for Partitioning, that single surviving row is a $184,000 opening claim on a server where no partitioned object exists today.

Cleanup alone is also not a defense because Oracle does not rely on one view. The audit scripts interrogate the object catalogs independently. DBA_PART_TABLES is examined in every audit and shows every partitioned table currently defined. DBA_TAB_COMPRESSION, DBA_INDEXES, DBA_ENCRYPTED_COLUMNS, and the Data Guard and RAC configuration views are pulled in the same collection pass. So the catalogs prove present state and the usage view proves historical state. Removing objects clears the first and leaves the second untouched, which is the worst of both worlds: you lose the ability to argue the feature was never really deployed, because you no longer have the evidence of what was actually there, while the row that generates the claim stays exactly where it was.

Dropping the objects removes your evidence, not Oracle's claim.

Do the opposite of quiet cleanup. Before you remove anything, capture the removal evidence: a timestamped export of the relevant catalog views, the change ticket number, the approver, the DDL executed, and a screenshot or spool of the feature usage row as it stood on that date. The remediation date is the only mechanism that caps the claim period, and it only caps it if you can prove the date to an auditor who was not in the room. In my experience negotiating these findings, a documented remediation with a change ticket converts a perpetual claim into a bounded one, and a bounded claim is the thing you settle. See our guidance on challenging Oracle audit findings for how that bounding argument is constructed in writing.

Cloning, Refreshes, and How One Finding Becomes Twelve

Feature usage statistics are stored inside the database, so they travel with it. Cloning carries the statistics from the source to the cloned environment, and the same is true of RMAN duplicates, restored backups, storage snapshots, and any refresh that copies datafiles rather than exporting and importing logical data. That means a single Partitioning row created once in production propagates into dev, test, UAT, training, DR, and the standby. Each of those copies is a separately installed and running database, and Oracle's collection scripts treat each one as a discrete licensable instance. The finding does not divide across the estate. It multiplies.

The arithmetic is brutal and it is the reason this section exists. Take a 4 processor production database with one Partitioning row. At $11,500 per processor list, that is $46,000. Clone it to three non production environments of the same size and you now have four instances carrying the same inherited row, or $184,000 at list before support. Add 22 percent annual support and the run rate on an accident nobody remembers making is roughly $40,480 a year. Substitute Diagnostics Pack at $7,500 or Advanced Compression at $11,500 and the shape of the problem is identical. The options pricing and audit trap breakdown shows how quickly these stack once more than one row is inherited.

Three concrete moves. First, build a clone lineage inventory: for every non production database, record the source DBID, the clone method, and the clone date, because DBID plus a matching FIRST_USAGE_DATE that predates the clone is documentary proof the usage was inherited, not independently created. Second, argue derived usage rather than independent deployment, and pair it with the licensing position that non production copies of a licensed production environment are covered by the production entitlement where your agreement permits. Third, and most often skipped, check whether the target ever needed the option at all: if the test environment has no partitioned objects and no partitioning DDL in its change history, the inherited row is noise you should be refusing to pay for, not remediating.

Oracle's Own Disclaimer and the 14 Documented Bugs

The strongest defense you have against a feature-usage finding was written by Oracle. Open options_packs_usage_statistics.sql, the script Oracle distributes through My Oracle Support under Doc ID 1317265.1, and read the header comments before you read the output. Oracle states that the usage statistics are for informational purposes only and do not represent any license entitlement or requirement. That single sentence, sitting in Oracle's own code, is the reason a row in DBA_FEATURE_USAGE_STATISTICS is a question and not an invoice. LMS will present the script output as though it were a bill of materials. It is not. It is a sampling artifact produced by detection logic that Oracle itself has documented as defective in at least 14 separate places (MOS Doc ID 1309070.1), plus unpublished bugs that never made the list. In 25 years of arguing these findings, I have never had an auditor concede the disclaimer voluntarily, and I have never had one successfully argue that their own vendor's disclaimer does not apply. Put it in your first written response, cite the Doc ID, and force Oracle to establish actual use through corroborating evidence rather than the view alone. Once the burden of proof shifts, most inflated option findings shrink considerably, and the remainder become a negotiation about scope rather than a demand for full-estate licensing.

Oracle's own script says the statistics do not represent any license entitlement or requirement, and that sentence is the reason a row is a question, not an invoice.

Name the bugs individually. Auditors handle generic objections easily and specific bug numbers poorly, because a bug number forces the LMS analyst to escalate to Oracle development rather than dismiss the point at the desk. The pattern across these defects is consistent: the detection trigger fires on internal, default, or metadata-only activity that no reasonable person would call deployment of a priced option. RMAN's default compression algorithm is the clearest example, and the compression=metadata_only case in 12.1.0.1 is the most damaging, because LMS itself detected more than 700 Advanced Compression usages that were pure artifact. If your finding sits in the compression or SecureFiles family, assume false positive until proven otherwise.

Two practical points. First, patch level matters to the argument, so record the exact database version and patch bundle for every instance in scope; a 12.1.0.1 database with an Advanced Compression finding is a materially different conversation than a fully patched 19c instance. Second, Oracle will argue the bugs were fixed and therefore irrelevant. That misses the point: the row persists after the fix, so a bug that existed in 2018 can still be generating the 2026 finding. Insist that Oracle either reconcile each disputed row against object-level evidence or withdraw it. This is the same evidentiary discipline described in our guide to challenging Oracle audit findings, and it applies with particular force to the compression and encryption families covered in Oracle Database EE options pricing and the audit trap.

Reading the Dates: Proving a Feature Was Touched Once, Not Deployed

The disclaimer gets you standing. The date and counter columns get you the reduction. Five fields carry almost all of the argument: FIRST_USAGE_DATE, LAST_USAGE_DATE, DETECTED_USAGES, TOTAL_SAMPLES, and AUX_COUNT. Read them as a ratio, not as a flag. Because the sampler runs weekly by default, DETECTED_USAGES counts the number of sampling windows in which the trigger fired, and TOTAL_SAMPLES counts the windows the database was observed at all. One detected usage against 200 total samples is not a deployed option; it is a single event in roughly four years of continuous observation, and stated plainly in those terms it is difficult for an auditor to defend as evidence of production reliance. Identical FIRST_USAGE_DATE and LAST_USAGE_DATE narrows it further: the feature was touched inside one weekly window and never again. AUX_COUNT of zero is the object-level corroboration, because it says the auxiliary object count associated with the feature is nil, which is exactly what you expect when a test object was created, sampled, and dropped.

Three additional patterns are worth hunting for explicitly. Usage confined to a version-upgrade window points at Oracle's own upgrade scripts rather than your applications, so align the dates against your DBUA or autoupgrade logs. A feature reported on a version where it does not exist, for example a 12c-only capability appearing on an 11g instance, is a defect on its face and should be struck rather than argued. Usage attributable only to default or internal schemas belongs in the bug family covered above. Cross-check FEATURE_INFO, which frequently names the triggering object or user and can resolve the question in one line.

None of this survives an LMS rebuttal unless it is corroborated. Pair every date pattern with independent evidence from your own systems: the change ticket or project record covering that week, DBA_HIST and AWR history showing no sustained activity, object catalog queries such as DBA_PART_TABLES or index and encryption catalogs showing zero surviving objects, and backup or clone records where the row was inherited rather than generated locally. Build a one-page reconciliation per disputed row: feature name, version, counters, date window, corroborating artifact, and your conclusion. In my experience, findings presented this way get withdrawn or scoped down at the analyst level, while unsupported assertions of "we never used it" get escalated into a full-estate demand.

Prevention: Killing Diagnostic and Tuning Pack Findings Before They Start

Every management pack finding I have defended in the last decade started with a default parameter nobody changed. Oracle ships Enterprise Edition with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, which means AWR snapshots, ADDM runs, and SQL Tuning Advisor are live from the moment the database opens. At $7,500 per processor for Diagnostics Pack and $5,000 for Tuning Pack (2026 list, per Atonement Licensing), a two-socket, 16-core Intel server carries roughly $100,000 of list exposure for two packs nobody consciously chose. Set the parameter to NONE if you hold no pack entitlement, and to DIAGNOSTIC only if you hold Diagnostics but not Tuning. Never leave it at DIAGNOSTIC+TUNING on an unlicensed database, and never assume a DBA "will remember." Pair the parameter with a hard stop on AWR: set the snapshot interval to zero via DBMS_WORKLOAD_REPOSITORY, purge the retained snapshots, and remove any cron or scheduler job that calls AWR reports. Then restrict Enterprise Manager: the pack access setting inside EM is separate from the database parameter, and an EM administrator with pack access enabled will generate rows regardless of what the instance parameter says. The trap most teams miss is Oracle's own documented position on how packs are accessed: the Database Management chapter of the Licensing Information manual states that any and all methods of accessing pack functionality, including the console, desktop widgets, command-line APIs, and direct access to the underlying data, require the license. A read-only SELECT against DBA_HIST_ACTIVE_SESS_HISTORY by your monitoring tool is, on Oracle's reading, pack usage. Audit your third-party monitoring agents accordingly, because several mainstream APM products query DBA_HIST tables by default.

Apply all six controls, then force a sample with DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE) and confirm CURRENTLY_USED flips to FALSE. Understand the limit: these controls are forward-looking only. They stop new DETECTED_USAGES from accruing, but they do not erase FIRST_USAGE_DATE or the historical row already written. Lock the settings down today, and treat the existing rows as a separate remediation and negotiation problem.

What the View Misses, and Why That Cuts Both Ways

Do not read a clean DBA_FEATURE_USAGE_STATISTICS output as an all-clear. House of Brick documented in March 2026 that there are feature triggers which invoke a licensable option or pack but write no DBAFUS row at all, and Oracle's field practice compensates for exactly that gap. LMS scripts do not stop at the feature view; they mine the object catalog directly. DBA_PART_TABLES and DBA_PART_INDEXES expose every partitioned object and are examined in every audit, per Atonement Licensing. DBA_TAB_COLUMNS and the encryption dictionary views expose TDE column and tablespace encryption for Advanced Security. DBA_INDEXES, DBA_TABLES, and the compression columns expose Advanced Compression. V$OPTION and DBA_REGISTRY show what is installed. A database with a spotless feature view and forty partitioned tables will produce a Partitioning finding, and the argument that "the view shows nothing" will not survive the first LMS call.

The gap runs the other way too, and that is your leverage. Because sampling is weekly by default, the view records the number of weeks in which usage was detected, not continuous consumption. Oracle cannot prove from DETECTED_USAGES that a feature was in production service across the whole claimed period; it can only prove it was touched during certain sample windows. When LMS asserts three years of unlicensed Tuning Pack, the burden of showing continuity sits with them, and the sampling cadence undercuts it. That distinction is the difference between a full-term backclaim and a narrow settlement, and it is the same evidentiary logic that underpins challenging the arithmetic behind an audit claim.

Run your own catalog checks alongside the view, not instead of it. Query DBA_PART_TABLES, the encryption columns, compression attributes, DBA_HIST retention, and V$OPTION on every instance, reconcile the two data sets, and record the delta before Oracle sees it. Where the catalog shows exposure the view does not, remediate quietly. Where the view shows usage the catalog cannot corroborate, you have a defensible position worth preparing now.

Turning a Finding into a Settlement: Negotiation Positions That Hold

A feature usage finding arrives as a spreadsheet with a total at the bottom, and that total is engineered to be argued as a single number. Do not argue it as a single number. Break it into four sequential positions and take them in order, because each one you win shrinks the base on which the next is calculated. First, contest scope: which database instances are genuinely in the claim, which processors are genuinely licensable under the core factor table, and which rows came from clones, refreshes, or decommissioned hosts that no longer exist. Second, contest the metric multiplier, because the rule that an option inherits the database metric and quantity (a Partitioning row on a 16 processor database is a 16 processor Partitioning claim) is only fatal if you concede the 16 processors. Third, contest the backdated support component, which at 22 percent of net license fee per year, compounded across the alleged usage window, is frequently the larger half of the number and is the least defensible part of Oracle's arithmetic when your FIRST_USAGE_DATE evidence contradicts their assumed start. Only then discuss discount. Buyers who lead with "what discount can you give me" have already conceded scope, metric, and backdated support, and they are negotiating a percentage off a number they should have halved first.

Backdated support at 22 percent compounding is often the larger half of the claim, and it is the least defensible part of Oracle's arithmetic.

Expect Oracle to offer the standard exit: convert the exposure into a forward looking purchase, typically cloud credits, a Universal License Agreement, or a subscription commitment, with the audit finding "waived" as part of the deal. In our negotiation experience this path is almost always worse value than a narrow, evidence backed license purchase at a negotiated discount, for three reasons. The waived finding is never quantified in writing, so you pay a premium against a number you never validated. The forward commitment locks spend for three to five years against consumption you cannot yet forecast. And a ULA certifies at the end on the same feature usage data that created the problem, which means you are rolling the exposure forward rather than closing it. If you genuinely need the capability, buy the specific option on the specific processors at a negotiated discount, get the license grant in writing, and keep the rest of your estate uncommitted. Realistic outcomes, from our casework: findings routinely reduce 40 to 80 percent when the evidence work (timestamps, clone lineage, bug references, version records) is complete before the response deadline rather than assembled reactively during it. The reduction comes from scope and metric corrections, not from Oracle's goodwill. The detailed mechanics of contesting a claim on its own terms are covered in our guide to challenging Oracle audit findings, and the principle holds here: the claim is not the bill, it is Oracle's opening position on the bill.

What To Do First: A 30-Day Feature Usage Control Plan

Run this on a calendar, not as a backlog item, because the value of every step below collapses the moment an audit notice arrives and the clock becomes Oracle's rather than yours.

• Week one, measure everything yourself. Download options_packs_usage_statistics.sql (MOS Doc ID 1317265.1) and run it against every database in the estate, production, dev, test, standby, and anything running on a hypervisor you forgot about. Archive the raw output with timestamps and a hash, store it outside the DBA team's normal share, and treat it as evidence. You need to know what Oracle will see before Oracle sees it.
• Week two, triage against the price map. Separate rows that map to priced options and packs (Partitioning at $11,500 per processor, Diagnostics Pack at $7,500, Tuning Pack at $5,000, RAC at $23,000, Advanced Compression at $11,500, Advanced Security at $15,000, on 2026 list) from rows that are free Enterprise Edition features and generate no liability. Most estates find that a large majority of flagged rows carry no cost at all. Our breakdown of Oracle Database EE options pricing and the audit trap gives the mapping you need for this triage.
• Week three, close the taps. Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE where the packs are not licensed, restrict Enterprise Manager pack access, and remove the privileges that let developers casually invoke a licensable feature. Record the change with a ticket number, an approver, and a date, because the change record is what proves the exposure window closed.
• Week four, build the evidence pack and decide. For every priced row still standing, assemble change tickets, clone lineage showing which findings were inherited rather than originated, applicable bug references (Bug 11902001, Bug 11902142, Bug 16088534 and the 14 documented issues in MOS Doc ID 1309070.1), and version records. Then make an explicit decision per finding: buy, remediate, or contest. Write the decision down.

One instruction matters more than the other four: do all of this before any contact with Oracle, including a friendly call with your account manager about "clarifying" a usage question. Voluntary disclosure after a notice, or an unprompted question that reveals you are looking, hands Oracle the scope definition and removes your ability to control which databases, which processors, and which dates are in play. Measure privately, remediate quietly, document thoroughly, and respond from a prepared position.

Related reading: Partitioning Shows as Used Even After You Drop the Partitioned Tables: Why and What to Do.

Frequently asked questions

Does DBA_FEATURE_USAGE_STATISTICS prove I owe Oracle a license?

No. Oracle's own script, options_packs_usage_statistics.sql (MOS Doc ID 1317265.1), carries a disclaimer stating the usage statistics are informational only and do not represent any license entitlement or requirement. The view records technical events, not contractual obligations, and Oracle has published at least 14 bugs in its own detection logic. It is evidence Oracle will use, but it is rebuttable evidence, not proof.

Can I delete or reset rows in DBA_FEATURE_USAGE_STATISTICS?

Modifying the underlying tracking data is not a supported operation and, in an audit context, is the worst possible move because it converts a licensing dispute into a bad-faith argument. The record persists even after you drop the objects that triggered it. The correct approach is to stop new usage accruing, document the remediation date, and build a factual case around the dates and counts already recorded.

If I only used Partitioning on one database, why does Oracle bill me for every processor?

Oracle options inherit the metric and quantity of the underlying database license. If the database is licensed on 16 processors, the option must be licensed on all 16, regardless of how many cores actually executed the feature. At $11,500 per processor list for Partitioning, that is a $184,000 list claim from a single detected usage, which is why architecture and footprint reduction matter more than discount negotiation.

Does setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE remove past Diagnostic Pack findings?

No. The parameter is forward-looking only: it stops new pack usage being recorded from the moment it takes effect. Historical DETECTED_USAGES and FIRST_USAGE_DATE values remain in the view and remain visible to LMS. Set it anyway, record the change ticket and timestamp, and use that date to cap the claim period you are willing to discuss.

How often does Oracle's feature usage tracking actually sample the database?

By default the sampling job runs weekly, typically on Saturday, so DETECTED_USAGES counts the number of weekly samples in which usage was detected rather than the number of times the feature was invoked. You can force an immediate refresh with EXEC DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE). This cadence is why a single background job can produce a large DETECTED_USAGES count that looks like heavy production use.

Should I run the LMS script myself before an audit?

Yes, and archive the dated output. Running options_packs_usage_statistics.sql on your own schedule gives you the same picture the auditor will see, several months earlier, and lets you triage priced options from free features, apply controls, and assemble bug and version evidence before any deadline pressure. Do this internally and under privilege where possible, and do not share raw output with Oracle without reviewing scope first.