DBA_FEATURE_USAGE_STATISTICS has been quietly tracking your license exposure the whole time. Most teams find out what it says during an audit instead of before one.
Ask most DBA teams what their Oracle license exposure looks like and you'll get a shrug, a guess, or a story about the last audit. That's strange, because the answer is usually already sitting in their own database, in a dictionary view almost nobody queries on purpose: DBA_FEATURE_USAGE_STATISTICS.
Oracle Database tracks, on its own, whether separately-licensed options and management packs have ever been used — Partitioning, Advanced Compression, the Diagnostics and Tuning Packs, and dozens of others. It isn't a third-party monitoring tool watching for this. It's built into the engine, has been for a long time, and it's the same data source Oracle's own License Management Services reviews draw from during a formal audit. The uncomfortable part: usage doesn't need to be a deliberate, ongoing decision to count. A feature a DBA switched on once, years ago, to test something, can still show up as detected today.
What we read, and how
pgrecon's offline extraction script pulls this view — read-only, alongside the edition banner and CPU count — as part of the same SELECT-only run that produces everything else. If the account running the script doesn't have the catalog role needed to see it, the file that would have held it simply comes back empty. The run doesn't fail, and nothing gets guessed in its place; it's the same never-crash, never-silently-skip rule that governs the rest of the tool.
The fixed-price assessment builds a license-exposure section from what comes back: a map from each detected feature to the separately-licensed option it evidences, whether the usage is current or only historical, and a processor-based count of what that usage would represent if licensed. It also flags something more specific and more useful than a generic warning — a high-severity line specifically when a database running Standard Edition shows usage of a feature that Standard Edition cannot license at any price. That's not a maybe. If the usage is real and the edition is Standard, that's a compliance conversation regardless of intent.
What it deliberately doesn't do
It never states a currency figure. Not a range, not an estimate, nowhere in the tool's output. That isn't caution for its own sake — a generic number would just be wrong, because actual exposure depends on your specific contract terms, your edition, your core counts, and pricing that varies enormously between organizations. A figure that looks precise but isn't grounded in your actual agreement is worse than no figure at all; it's a false sense of certainty. Pricing is a conversation for the engagement, next to the actual contract. What the assessment gives you instead is the fact pattern — what's been used, on what edition, currently or historically — so that conversation starts from evidence instead of a guess.
The point isn't to alarm anyone
It's that this isn't hidden information requiring forensic discovery. It's a standard Oracle catalog view, readable with a SELECT statement any DBA can run and review before anyone else sees the output. The only real choice is whether you read it on your own schedule, or on an auditor's.
pgrecon's extraction script and its license-exposure logic are documented at muzzammil242.github.io/pgrecon. If you want the full board-ready version of this - grade, findings, and license exposure computed from your own database's usage statistics - that's the fixed-price assessment: book one at DevCrafter AI.
Top comments (0)