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

Oracle's feature usage view is a cumulative log, not a live inventory, so dropping the last partitioned table leaves DETECTED_USAGES and FIRST_USAGE_DATE intact and hands an auditor a $11,500 per processor conversation you did not intend to have. This page explains the column semantics, the weekly sampling behavior, the chopt and V$OPTION evidence that stops the clock, and the sequence to run before Oracle sees your data.

What the Flag Actually Costs Before You Argue Anything

Before you decide whether this is worth two weeks of DBA time, price the exposure. On the Oracle Technology Global Price List (April 16, 2026 and August 3, 2026 editions), Partitioning lists at $11,500 per processor and $230 per Named User Plus, and it is an option, meaning it only exists on top of Enterprise Edition at $47,500 per processor and $950 per NUP, with the 25 NUP per processor minimum still in force. The number that ends most arguments is not the unit price, it is the metric. An option must be licensed at the full processor count of the host database, not the cores that happened to touch a partitioned segment. One forgotten legacy partitioned table on a 16-processor box is $184,000 at list, and support at roughly 22 percent adds about $40,480 every year for as long as you keep the CSI alive. Over five years that single flag is worth more than $386,000 in list terms.

Negotiated discounts of 40 to 70 percent are routine at volume, and in our negotiation experience Oracle sales will happily open with a discount rather than a withdrawal. Treat that as a trap. Discounting a license you never needed converts a defensible compliance dispute into a permanent support stream, and support is the line that compounds. The correct outcome is removal of the claim, not a percentage off it. Read the mechanics in our companion piece on how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill before you take any call.

Why DROP TABLE Cannot Clear the Flag: The Repository, Not the View

DBA_FEATURE_USAGE_STATISTICS is not an inventory of what your database contains today. It is a view over the AWR-side repository table WRI$_DBU_FEATURE_USAGE, with the detection and install-check logic held separately in WRI$_DBU_FEATURE_METADATA. The weekly sampling job evaluates each feature's detection query, then writes a row recording what it found. Dropping a partitioned table changes the object. It does not touch the rows already written. That is the entire mechanism, and once you state it plainly to an auditor you have shifted the conversation from "you used Partitioning" to "your sampling log recorded a sample."

The behavior follows from the design. DETECTED_USAGES is defined by Oracle as the number of times the system has detected usage, so it is a monotonic counter that increments and never decrements. FIRST_USAGE_DATE is fixed at the first positive sample and by definition cannot move. LAST_USAGE_DATE is the last positive sample, so it freezes at whatever date the object was still present. None of these columns are designed to reflect a removal event, because none of them were ever meant to answer the question "is this in use now." That is a separate column, and the next section deals with it.

Dropping a partitioned table changes the object, not the accumulated sample rows.

This is also why there is no supported path to selectively delete a single feature's history. The rows sit in the same repository infrastructure as your AWR data, and any surgical delete either fails, breaks the dependent metadata linkage, or forces you to wipe workload history you may need for performance forensics and, ironically, for your own audit defense. In our experience, the customers who attempt it end up in a materially worse position than the ones who left the flag alone. An auditor who finds evidence of manual DML against internal repository tables stops evaluating your technical argument and starts evaluating your credibility. In an audit governed by the standard license agreement's records and audit clause, tampering with the record is a far more serious posture than a historical usage flag you can explain with dates, DDL logs, and a clean current sample.

The productive route is the opposite of deletion. Leave the history intact, prove it is history, and force a fresh sample that shows the feature is not in use now. Preserved evidence with a clean current reading beats a suspiciously empty table every time, and it is the only version of the story that survives escalation to Oracle LMS or a third-party audit firm.

The Column That Wins the Argument: CURRENTLY_USED Is the Only "Now"

Read Oracle's own documentation and the argument makes itself. In the Oracle Database Reference entry for DBA_FEATURE_USAGE_STATISTICS, CURRENTLY_USED is defined as an indicator of "whether usage was detected the last time the system checked (TRUE) or not (FALSE)." DETECTED_USAGES is defined as the "number of times the system has detected usage for the feature," which is a lifetime counter, and FIRST_USAGE_DATE and LAST_USAGE_DATE are simply the first and last sample timestamps at which detection occurred. Oracle repeats the same wording in the REST Data Services API reference, where currently_used carries the identical definition and aux_count is described only as feature-specific usage data in number format. That matters because Oracle wrote the schema. When an auditor points at DETECTED_USAGES of 412 and calls it proof that Partitioning is deployed today, that auditor is contradicting the vendor's published column semantics, and you should say so in writing, quoting the doc page (current revision dated May 1, 2026). Anchor your response on the one column Oracle designed to answer the present-tense question, and pair it with the object-level query showing zero partitioned segments outside SYS and SYSAUX. Our sibling analysis of how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill walks the same columns in the wider audit context.

Weekly Sampling: Why "We Dropped It Tuesday" Does Not Show Yet

The detection job is not continuous. Oracle's internal process on each database checks which features have been used since the last check and it runs roughly once per week, typically on a Saturday. You can poll the view every sixty seconds and nothing will change until that weekly sample fires. So the sequence matters more than the remediation itself: drop the partitioned objects on Tuesday, and for up to seven days the view will still read CURRENTLY_USED = TRUE, with a LAST_USAGE_DATE that sits after the date on which your remediation memo claims the feature was gone. Hand that extract to Oracle mid-week and you have supplied the vendor with a timestamped record of continued use, signed by you. In twenty-five years of these conversations, that is the single most common self-inflicted wound in a Partitioning dispute, and it converts a defensible historical-usage argument into a negotiation about how many processors to buy at $11,500 each.

Force the sample yourself before anything leaves the building. Per MOS Doc IDs 1629485.1 and 2535290.1, you can refresh the statistics with exec dbms_feature_usage_internal.exec_db_usage_sampling(sysdate), or trigger the internal action with alter session set "_SWRF_TEST_ACTION"=53. Run the refresh after the objects are gone, then capture the row with a fresh CURRENTLY_USED = FALSE and a LAST_USAGE_DATE that predates your remediation date, and preserve the sample timestamp. Do the same on every instance in scope, including clones, standbys, and test copies, because one unrefreshed development database will be treated as representative of the estate. Never send Oracle a stale extract, never send one taken before the post-remediation sample, and never let the vendor collect the data themselves on their own schedule.

Usage You Should Refuse to Pay For: OEM, SYSAUX, and Detection Gaps

Before you concede a single processor, separate the segments Oracle shipped from the segments your developers wrote. Oracle Enterprise Manager partitions its own repository tables, which trips the Partitioning signature on the OMS repository database with no application involvement whatsoever. House of Brick's March 2026 analysis put it plainly: OEM triggers Partitioning usage because the repository partitions its own tables, and "that is not the responsibility of the customer to pay for." The same reasoning applies to SYS and SYSAUX owned objects and to AWR segments, which are partitioned by Oracle's own design and cannot be avoided by any customer configuration choice. If your only detected usage sits in Oracle-supplied schemas, you have no chargeable deployment of the option, and you should say so in writing rather than negotiating a discount off a number you do not owe.

Now cut the other way, honestly, because the same imperfection is your strongest structural argument. MOS Doc ID 2644606.1 documents partitioned tables owned by application schemas that produce no Partitioning entry in DBA_FEATURE_USAGE_STATISTICS at all. A counter that misses real usage in one direction and reports vendor-owned usage in the other is a sampling heuristic, not a contractual measurement. Put that sentence in the audit correspondence, dated and attributed to Oracle's own support note, and the burden shifts back to the auditor to prove chargeable deployment by object ownership. Then do the work yourself: inventory every partitioned segment with DBA_PART_TABLES and DBA_TAB_PARTITIONS joined to owner, exclude SYS, SYSTEM, SYSMAN, DBSNMP and the AWR schemas, and let ownership drive your response. Our companion analysis of how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill covers the wider script.

A counter that misses real usage in one direction and reports vendor-owned usage in the other is a sampling heuristic, not a contractual measurement.

Stopping the Clock at the Binary Level: chopt, V$OPTION, and the Caveats

Dropping objects stops new usage samples. It does not stop a developer recreating a partitioned table next quarter and restarting the whole argument. The only remediation that makes recurrence impossible is chopt disable partitioning, which relinks the option out of the kernel. After that, any partitioned DDL fails immediately with ORA-00439: feature not enabled: Partitioning, which is a hard technical control rather than a policy your team has to remember. Oracle's own Mike Dietrich re-verified that chopt still supports the partitioning target through 19c and Oracle AI Database 26ai in a post updated February 7, 2026, so you are not relying on an unsupported eleven-year-old procedure.

Price the operational cost accurately before you propose it to the infrastructure team. You need a short outage on each database home, a kernel relink on Unix and Linux, or a DLL rename on Windows. In Real Application Clusters with non-shared homes, chopt must run on every node, and a partial run leaves you with an inconsistent cluster. The real caveat is patching: disabled options may not receive patches applied to that home, so if you re-enable partitioning later you can end up with a partly patched binary. Plan for that by treating chopt as a one-way decision on that home, or by re-running the patch after re-enabling. In our experience negotiating these settlements, buyers who cannot get a maintenance window for chopt still get most of the benefit from strict schema controls, but they carry the recurrence risk forever.

The evidence artifact is cheap and you should collect it the same day. Run SELECT parameter, value FROM V$OPTION WHERE parameter = 'Partitioning' and capture the FALSE result with a system timestamp, the instance name, the host, and the operator who ran it. Retain that alongside the chopt log and the relink output in the same evidence folder you build for any Oracle audit response, the same discipline that underpins a clean support termination or reinstatement position. V$OPTION reporting FALSE is a statement about the running binary, which is exactly the assertion an auditor cannot wave away with a cumulative counter.

Building the Evidence File Oracle Cannot Wave Away

Assemble the file before Oracle asks for anything, and assemble it in the order that builds a chain of custody rather than a pile of screenshots. The anchor artifact is Oracle's own options_packs_usage_statistics.sql from MOS Doc ID 1317265.1, run by your DBAs on every Enterprise Edition instance and retained internally with the run date, host name, and instance name in the header. Oracle's script carries far more weight in an audit conversation than a hand-written SELECT against the view, because the auditor cannot argue you cherry-picked columns. Layer on a partitioned segment inventory grouped by OWNER that shows zero application-owned partitioned segments, leaving only SYS, SYSAUX, AWR, and any OEM repository objects, which are Oracle's own housekeeping and not a customer license obligation. Then force the sample with dbms_feature_usage_internal.exec_db_usage_sampling(sysdate) and capture CURRENTLY_USED=FALSE with a timestamp, capture V$OPTION showing Partitioning as FALSE after the chopt relink, and attach the change tickets and DDL timestamps that prove when the objects went away. The narrative you submit should read as a closed timeline, not an admission: feature touched between these dates, objects removed on this date under this ticket, option disabled in the binaries on this date, no current usage detected on this date, therefore no license requirement going forward and a historical event to be closed without purchase. For the mechanics behind the columns, cross-reference our note on how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill.

What to Do First, in Order

Run this as a six-step sequence, not a parallel scramble, because the evidence value depends on the order. First, run options_packs_usage_statistics.sql on every EE instance this week and keep the output strictly internal; you are building your own baseline, not filing a disclosure. Second, inventory partitioned segments by owner so that SYS, SYSAUX, AWR, and OEM repository noise is separated from genuine application use before anyone quantifies exposure. Third, drop or convert the application-owned partitioned objects and document each change with a ticket number and a DDL timestamp. Fourth, force a manual re-sample and capture CURRENTLY_USED=FALSE, remembering that the native detection job runs roughly weekly, so waiting for Saturday costs you evidence you could have dated today. Fifth, schedule chopt disable partitioning with the relink downtime and the every-node RAC requirement planned, because a partial relink leaves you exposed on the node that was missed. Sixth, and only then, decide whether any residual, genuinely current usage should be settled as Named User Plus at $230 per user (one fiftieth of the $11,500 processor price) or removed outright, since a single legacy partitioned table on a 16-processor host is $184,000 at list before the 22 percent support stream.

Two negotiation rules govern the endgame, and in 25 years across this vendor's audit desk both have held. Never accept a discount on an option you can prove is historical: a 60 percent reduction on a license you do not owe is still a permanent support annuity Oracle books forever. And never hand Oracle a raw view extract without your own narrative attached, because an unexplained DETECTED_USAGES count becomes their opening number. If the residual exposure is large enough to reach a contract event, treat it the way you would any other termination decision and read our guidance on dropping Oracle support and reinstatement before you sign anything that renews the base.

Related advisory: the full topic guide.

Frequently asked questions

Can I delete rows from DBA_FEATURE_USAGE_STATISTICS to clear Partitioning?

Technically the underlying data lives in WRI$_DBU_FEATURE_USAGE, but do not touch it. There is no supported method to selectively purge one feature's history, and in an audit context altering the record is far more damaging than the flag itself. The defensible route is to leave the history intact and prove current usage is FALSE with fresh, timestamped evidence.

Does DETECTED_USAGES greater than zero mean I owe for Partitioning?

No. Oracle's own documentation defines DETECTED_USAGES as the number of times usage has ever been detected and CURRENTLY_USED as whether usage was detected at the last check. A non-zero cumulative count with CURRENTLY_USED=FALSE is evidence of a historical event, not a current deployment, and that distinction is the core of the buyer-side argument.

How long after dropping partitioned tables will the view update?

Up to about a week. The internal check typically runs once per week, usually on a Saturday, and polling the view more frequently changes nothing until that sample runs. Force a refresh with dbms_feature_usage_internal.exec_db_usage_sampling(sysdate) or the _SWRF_TEST_ACTION=53 session setting (MOS Doc IDs 1629485.1 and 2535290.1) before you hand any extract to Oracle.

Is running chopt disable partitioning safe on a production database?

It is safe but not free. You need a short outage, a kernel relink on Unix or DLL rename on Windows, and execution on every node in a RAC cluster with non-shared homes. Be aware that disabled options may not receive subsequently applied patches, which leaves a partly patched home if you ever re-enable, so record the decision and revisit it at each major patch cycle.

Why does Oracle Enterprise Manager show Partitioning usage on a database I never partitioned?

Because the OEM repository partitions its own tables, and SYS, SYSAUX and AWR-owned segments carry the same signature. That is Oracle's software using Oracle's feature in Oracle's own schemas, not customer deployment, and it is not a chargeable license event. Inventory partitioned segments by owner so you can name exactly which schemas are involved.

If some current Partitioning usage is real, what is the cheapest way to license it?

Compare metrics before conceding a processor count. Partitioning lists at $11,500 per processor and $230 per NUP, and every Database line prices NUP at exactly one fiftieth of the processor price, so NUP wins below 50 real users per processor. Remember the option must be licensed at the full processor count of the host database, so relocating the workload to a smaller licensed host is often cheaper than buying the option.