An Oracle audit letter rarely ends with the letter. Soon after it, Oracle’s License Management Services (LMS) team sends scripts and asks you to run them on your servers. What those scripts return becomes the evidence for Oracle’s findings, so it pays to know exactly what they collect before anyone presses enter. This page explains Oracle’s audit scripts, including the database script many people still call Review Lite, and how to handle them.
In short
- Oracle LMS uses two tools of its own: the Oracle Collection Tool and the Global Deployment Matrix (Oracle LMS tooling page, October 2026). Both are free.
- The Collection Tool is a set of operating system and SQL queries. ReviewLite.sql is its database script: it reports which database options and packs show usage.
- The scripts are not a public download. Oracle provides them, under its own licence terms, when it reviews or audits your estate.
- The output is human-readable. Read it before you send it.
The tools, in Oracle’s words
Oracle describes the Collection Tool as “a series of operating system and SQL queries that run in your Oracle estate and collect Oracle product usage information”. The outputs “are human-readable, so you have visibility into the information shared, and will be analyzed to illustrate what Oracle programs are installed and/or in use.” The Global Deployment Matrix is “an online form that gives you guidance on how to catalog and provide an overview of the Oracle programs in use.”
Oracle’s LMS FAQ also separates two kinds of engagement. The Assurance Service is customer-led: you ask Oracle to confirm your licensing for a defined scope. The Audit Service “can only be initiated by the Oracle LMS team through a formal process.” The same scripts can appear in both. What changes is who set the scope.
What each tool tells Oracle
| Tool | What it is | What Oracle learns |
|---|---|---|
| Oracle Collection Tool | Operating system and SQL queries run on your servers | Which Oracle programs are installed and in use, and on what hardware |
| ReviewLite.sql (database) | The database part of the collection, run in each database | Edition, options and packs with recorded usage, written to an options file |
| Global Deployment Matrix | An online form you fill in | Your own catalogue of Oracle programs and where they run |
| A verified third-party SAM tool | Tools Oracle has checked for specific products | The same usage data, collected by a tool you already run |
Oracle’s tooling page lists the vendors whose tools it has verified for Oracle Database and its options, Fusion Middleware, Java SE or E-Business Suite. They include Flexera, ServiceNow, Snow Software, USU, Certero, Eracent, HCL, Lime Software, Matrix42, OpenText and SHI. Verification covers named products only, and only the right version of each tool.
How a database script finds options you never bought
Every Oracle database keeps its own record of feature use in a view called DBA_FEATURE_USAGE_STATISTICS. Oracle’s documentation lists what it holds: how many times usage was detected, whether the feature was in use at the last check, and the first and last dates usage was seen. The database script reads this record.
A worked example: a DBA once ran a SQL tuning advisor while chasing a slow query. The view now shows a first usage date for that feature, and the options file flags it. HCL’s documentation for its own Oracle discovery notes that SQL Tuning Sets can point to Tuning Pack or Real Application Testing usage. Oracle then asks whether you hold those licences. The usage may have lasted five minutes. The record can be years old.
That is why we read the output before it goes to Oracle. Some flags are real usage that needs a licence. Some come from a default setting or a management screen, and need an explanation with evidence. Both are easier to deal with before Oracle sees them. Our page on disabling Oracle options and packs shows how to stop usage being recorded in the first place.
Mistakes we see when companies run Oracle’s scripts
- Running them everywhere. The audit notice defines the scope. Scripts run on servers outside it hand Oracle data it did not ask for.
- Sending raw output unread. The output is readable on purpose. Nobody should send it without knowing what each line says.
- Forgetting virtualisation. Host and cluster details decide how many processors Oracle counts. A database on one VMware virtual machine can be counted across a whole cluster.
- Treating the Deployment Matrix as paperwork. It is your own written statement of where Oracle runs. Mistakes in it are hard to take back.
- Checking usage for the first time during the audit. A baseline taken months earlier leaves time to fix what it finds.
Our baseline Oracle license review runs the same checks before Oracle does, and the Oracle License Tool lets your team see options and pack usage on their own. If an audit letter has already arrived, start with the first 48 hours after an Oracle audit letter and Oracle audit defense.
Our free licensing guides
This page used to offer two downloadable guides, on the Oracle ULA and on Java deployments. The same ground is now covered in our free guides, which are open to read without a form:
- Oracle ULA certification checklist
- The Java employee metric: knowing your real exposure
- Oracle license audits in 2026
- Every guide in the Oracle licensing knowledge library
Questions we are asked about Oracle’s audit scripts
Can I download the Oracle Review Lite script?
No. Oracle owns the script and provides it to customers during a review or audit, under its own licence terms. HCL’s documentation for its discovery tool, for example, requires a valid Oracle account and acceptance of Oracle’s licence to use ReviewLite.sql. To check your own option usage at any time, query DBA_FEATURE_USAGE_STATISTICS, or ask us for a baseline review.
What does the Oracle Collection Tool collect?
Oracle product usage information gathered by operating system and SQL queries: which programs are installed, which are in use, and the hardware they run on. For databases, that includes edition, options and packs with recorded usage.
Can we use our own SAM tool instead of Oracle’s scripts?
Often, yes. Oracle verifies some third-party tools for specific products, including tools from Flexera, ServiceNow, Snow Software and USU. Check that your tool and its version are verified for the products in scope before you rely on it.
Do the scripts show usage from years ago?
They can. The database records the first and last dates it detected each feature, and the script reports what is recorded. Old usage still needs an answer.
Should we run the scripts before Oracle asks?
Run the same kind of check, yes. Knowing your position before an audit starts gives you time to remove unlicensed usage, gather evidence and plan the conversation with Oracle.
An audit letter, a renewal quote or a ULA end date on your desk? We check what Oracle, Microsoft, IBM or Broadcom is claiming, work out what you owe under your contract, defend against audits, and negotiate the rest down.