Oracle USMM scripts and Review Lite are not neutral measurement tools — they are evidence-collection engines that build Oracle's back-licence claim. Every option flag, core count, and Java install they capture becomes a line item in Oracle's compliance gap. Understanding precisely what each script reads, and what you are not obligated to share, is the difference between a routine measurement and a seven-figure claim.
Short answer: Oracle USMM scripts collect database edition, version, server core counts, and the usage history of every separately licensed option and management pack from DBA_FEATURE_USAGE_STATISTICS, plus Named User Plus counts. Review Lite inventories every Oracle install — databases, middleware, and Java SE — across your estate. Oracle turns both into a priced compliance gap.
DBA_FEATURE_USAGE_STATISTICS — a single accidental query years ago still registers as licensable usage today, because the view never resets.CONTROL_MANAGEMENT_PACK_ACCESS parameter is remediated before the script runs.USMM (Oracle Server Worldwide Measurement, run via the review_lite.sql and dedicated measurement scripts Oracle's LMS / GLAS team supplies) is Oracle's Database measurement tool — a set of SQL scripts that query Oracle's own data dictionary to report exactly which database editions, options, and management packs are installed and have been used on each server. It is the primary evidence-collection mechanism in a formal Oracle Database audit.
The critical point most buyers miss: USMM does not measure intent or production status. It measures the data dictionary. If a feature was ever touched — even by an automated job, a default configuration, or a one-off DBA query — USMM reports it as used. Oracle then maps that usage against your entitlements, applies the Core Factor table, and prices every gap at list. This is why pre-audit remediation, not post-audit argument, is where the real money is saved. For the full process context, see our Oracle License Audit Guide 2026.
Timing is everything: DBA_FEATURE_USAGE_STATISTICS is cumulative and does not reset. The moment Oracle runs USMM, it captures the historical record — not a current snapshot you can clean up afterwards. Every remediation lever (disabling Diagnostics Pack, decommissioning ghost installs, documenting non-production usage) only works before the script executes.
USMM output is structured around four data categories Oracle needs to build a Database compliance claim: hardware, edition, option usage, and user counts. The table below maps each category to what Oracle reads and how it becomes a claim line item.
| Data category | What USMM captures | How Oracle uses it |
|---|---|---|
| Server hardware | CPU model, socket count, total physical cores per host, hostname, OS | Multiplied by the Core Factor to calculate Processor licence requirement |
| Database edition & version | Enterprise Edition vs Standard Edition 2, patch level, instance names | Confirms which price-list metric and option set applies |
| Option & pack usage | DBA_FEATURE_USAGE_STATISTICS flags for Partitioning, Diagnostics Pack, Tuning Pack, Advanced Security, In-Memory, Multitenant, RAC, Data Guard, Spatial, and more | Each "used = TRUE" option becomes a separately licensed line item priced at list |
| Named User Plus | Counts of distinct database users / sessions where the NUP metric applies | Compared against NUP minimums per processor to identify shortfalls |
| Configuration parameters | CONTROL_MANAGEMENT_PACK_ACCESS and related init parameters | Determines whether Diagnostics/Tuning Pack access was enabled |
The most expensive surprises live in the option-usage row. Oracle Diagnostics Pack and Tuning Pack are enabled by default on most Enterprise Edition installs and quietly accumulate usage flags through routine AWR and ADDM activity. Partitioning, In-Memory, and Advanced Security are similarly easy to trigger without a conscious purchase decision. USMM does not distinguish "we bought this" from "this defaulted on" — that distinction is yours to evidence and challenge.
Our Oracle Compliance Review runs the same measurement methodology USMM uses — then tells you exactly what to remediate before Oracle's scripts capture it. See the healthcare case study: $6M of audit risk eliminated pre-audit.
Review Lite is Oracle's lightweight discovery script. Where USMM measures option usage deep inside a known database, Review Lite casts a wide net to find Oracle software Oracle did not previously know you were running. It inventories every Oracle Home directory, database instance, listener, middleware installation, and — increasingly — every Oracle JDK build on each scanned host. Its purpose is breadth: surfacing the shadow estate.
Review Lite is particularly effective at exposing the installations buyers forget about: legacy database instances left running after a project ended, WebLogic and SOA Suite homes from decommissioned environments, and Oracle JDK copies bundled inside third-party applications. Because it reads installation metadata rather than runtime usage, even dormant software shows up. Every entry it returns becomes a candidate for an Oracle licence requirement unless you can evidence that it is non-production, retired, or already entitled.
This is why a forensic estate clean-up before any Oracle script runs matters so much. Decommissioning ghost installs and removing them from the Oracle inventory eliminates Oracle's ability to attribute a licence requirement to software you no longer use. Our License Optimization service includes systematic decommissioning, and the broader script landscape is covered in our guide to Oracle LMS audit scripts.
USMM and Review Lite are complementary, not interchangeable. Oracle typically runs Review Lite first to discover the estate, then USMM to measure the databases it found. The distinction matters because each opens a different category of exposure and each is challenged differently.
| Dimension | USMM (measurement) | Review Lite (discovery) |
|---|---|---|
| Primary purpose | Measure option and pack usage on known databases | Discover all Oracle software across the estate |
| Depth vs breadth | Deep — reads the data dictionary per instance | Broad — inventories installs per host |
| Key data source | DBA_FEATURE_USAGE_STATISTICS, V$ views | Oracle Home metadata, inventory files, file system scan |
| Biggest exposure created | Accidentally enabled options (Diagnostics Pack, Partitioning, In-Memory) | Ghost and shadow installs, undocumented Java SE |
| Primary defence | Remediate parameters, document non-production, recalculate from raw output | Decommission and remove from inventory before the scan |
Java is where script-driven discovery has become most aggressive. Oracle's measurement increasingly captures the Oracle JDK version and install path on every endpoint it scans, then maps detection to the Java SE Universal Subscription Employee metric. The Employee metric is brutal: a single licensable Oracle JDK build detected anywhere can trigger a subscription priced across your entire employee headcount, not just the machines running Java. In our client base the Employee metric routinely costs 5–10x more than the legacy Named User Plus model for the same deployment.
The defence is inventory discipline before the scan. Knowing precisely which Oracle JDK builds are present, which are covered by the NFTC (No-Fee Terms and Conditions) licence, and which can be replaced with OpenJDK is the difference between a contained position and an organization-wide claim. Our practical walkthroughs cover how to inventory Java installations and how Oracle detects Java.
This is the question Oracle's LMS team would prefer you not ask. Your Oracle Master Agreement grants Oracle an audit right and obligates "reasonable cooperation" — but it rarely names USMM or Review Lite specifically, and it does not require you to execute Oracle's scripts unreviewed or surrender raw output without challenge. You are entitled to review every script line before it runs, scope data collection to contracted products and entities, and, in many cases, supply equivalent verified data yourself rather than running Oracle's tooling against your production environment.
Treating the script as non-negotiable is the single most common and costly mistake. Push back on scope, review what each script reads, and never let Oracle's interpretation of the output stand as the final word. For the precise wording of your audit rights, see our breakdown of the Oracle right-to-audit clause and our guide to audit data disclosure — what you must share, and what you should not.
Our Audit Defense team reviews every Oracle measurement script before execution, scopes the data collection, and independently recalculates Oracle's claim from raw output. Former Oracle LMS insiders, 100% buyer-side.
USMM collects database edition and version, the CPU and core count of each server, the usage flags in DBA_FEATURE_USAGE_STATISTICS for every separately licensed option and management pack, Named User Plus counts, and key init parameters. Oracle uses this output to calculate Processor and option licence requirements and price any shortfall at list.
Review Lite is Oracle's lightweight discovery script. It inventories Oracle software installations across an estate — every Oracle Home, database instance, middleware install, and Oracle JDK — without the deep per-database option measurement that USMM performs. Oracle runs it to find software it did not previously know existed, including dormant and shadow installations.
No. DBA_FEATURE_USAGE_STATISTICS is cumulative and does not reset. A single accidental query that triggered an option years ago still shows as used. This is why pre-audit remediation must happen before USMM runs — the script captures the full historical record, not just current usage.
Oracle maps each measured option, server core count, and Java install against your entitlements, applies the Core Factor table, and prices every gap at list. Across our engagements, Oracle's opening claim from raw script output averages 3–5x what the customer actually owes after independent recalculation (Oracle Licensing Experts, 2026).
Oracle's Java measurement collects the Oracle JDK version and install path on each detected endpoint and, increasingly, employee headcount to apply the Java SE Universal Subscription Employee metric. Detection of a single licensable Oracle JDK build can trigger an organization-wide per-employee claim, even where only a handful of machines run Java.
Yes. You are entitled to review every line of the USMM and Review Lite scripts before granting permission to execute, identify any collection that exceeds the contracted audit scope, and challenge it. This is standard practice for organizations with independent representation — not an aggressive or unusual request.
Remediate the CONTROL_MANAGEMENT_PACK_ACCESS parameter and decommission ghost installs. Diagnostics and Tuning Pack are accidentally enabled in 40%+ of Enterprise Edition estates; setting the parameter to NONE before USMM runs eliminates that exposure for the audit period — a change that typically takes under 24 hours.
By Fredrik Filipsson — former Oracle licensing and sales professional, 25+ years. Founder of Oracle Licensing Experts. 100% buyer-side advisory — never works for Oracle. LinkedIn ↗ · About our team →
Reviewed by the Oracle Licensing Experts Editorial Team — former Oracle License Management Services consultants and enterprise procurement specialists.
Oracle updates its measurement methodology. New compliance traps emerge. Join 2,000+ Oracle stakeholders who receive our weekly briefings from former Oracle LMS insiders.