Oracle Practice
How to check Oracle license information the three reliable options.
Oracle will not hand you a single license dashboard. Your position lives in three places, and each one misleads in a different direction.
Oracle will not hand you a single license dashboard. Your position lives in three places, and each one misleads in a different direction.
There is no single Oracle license dashboard: the position is triangulated from LMS measurement scripts, Enterprise Manager usage data, and the entitlement records behind your CSI numbers in the support portal.
The three reliable methods are Oracle's own LMS measurement scripts run internally, Enterprise Manager feature usage views, and the entitlement and CSI records in My Oracle Support, and a defensible position needs all three. Each answers a different question.
The scripts Oracle uses in audits are available to customers. Running them internally, on your schedule, gives you the auditor's view without the auditor.
The core collection queries Oracle's own feature usage views and writes one flat output file per database instance. The same measurement the LMS Assurance Service runs is what you run, so nothing surprises you later.
The feature usage views in Enterprise Manager reveal option and pack consumption fast. The caution is reflexive: Diagnostics and Tuning packs in EM are themselves licensable, so the measurement tool can create the liability it measures.
Enabling a management pack in Enterprise Manager can register usage the same day. Set the pack access controls in EM before anyone explores, so a casual click never manufactures a Diagnostics or Tuning Pack finding.
CSI records show supported quantities, metrics, and end dates per contract. They are the cleanest entitlement signal most teams can reach without digging through twenty years of ordering documents.
Export the hardware and software tabs and the contract list from the portal. A CSI can carry lines you no longer deploy, and it can omit fully paid perpetual licenses whose support you dropped, so treat it as a lead, not a verdict.
LMS scripts overstate risk by reading every enabled flag, EM understates scope where agents are missing, and CSI records reflect support payments rather than ownership. Triangulation is the method; any single view misleads.
The three views compared
| Method | Answers | Misleads by |
|---|---|---|
| LMS scripts | What is installed and enabled, per host | Flagging enabled but unused features as usage |
| Enterprise Manager | What is actually used across managed targets | Missing unmanaged hosts; packs create liability |
| CSI support records | What you pay support on, per contract | Confusing support renewal with entitlement |
Read the three views as a Venn diagram. Deployment measured but not entitled is exposure. Entitlement paid but not deployed is shelfware. Only the overlap is a clean, funded position, and most estates find that overlap smaller than assumed.
Processor licensing depends on core counts, core factors per the Oracle price list documents, and virtualization topology. All three methods need a hardware inventory joined on before processor math is possible.
A processor license count is core count multiplied by the Oracle core factor for that chip. Miss a two socket cluster in the inventory and the whole triangulation is wrong by dozens of licenses. Hardware is the join key, not an afterthought.
Reconcile entitlements against measured deployment per product and metric, resolve every mismatch to either a remediation or a documented explanation, and date stamp the result. That document is the baseline every audit response and renewal starts from.
The output is a single spreadsheet: one row per product and metric, entitled quantity beside measured deployment, each row marked covered, gap, or shelfware. That reconciliation file, not any vendor report, is what a defensible position looks like.
The standard advice is to ask your Oracle account team for a license review, since they have the records and the tooling. We disagree. In the Oracle baselines Fredrik Filipsson built in 2024 to 2025, account team led reviews fed directly into audit adjacent activity in a meaningful share of cases, because the same measurement data prices Oracle's next proposal. The buyer side move is to run the identical scripts internally, reconcile privately, and remediate before any number reaches Oracle. Checking your position through the vendor is handing over the negotiation file.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Oracle knows your deployment better than you do only if you let that stay true. The scripts are available; the only question is who runs them first.
You read it by separating features that ship with your edition from separately licensable options and packs, then checking measured usage against workload you can explain. A flag is a question, not yet a finding.
Oracle's DBA_FEATURE_USAGE_STATISTICS view records every option and pack the database has touched, with columns for detected usages and first and last usage dates.
The options_packs_usage_statistics.sql report from My Oracle Support Doc ID 1317265.1 aggregates that view into one file per instance. It refreshes roughly weekly, so a very recent change may not surface until the next sampling window.
A nonzero detected usage count against Diagnostics Pack, Tuning Pack, or Partitioning is a compliance signal. It is not proof of intent. One advisor click or a single snapshot can register a pack nobody meant to run.
The table below maps the packs and options that surface most often to the action that usually triggered them. Read every flag against the workload before you concede a single gap.
Common feature flags and what usually triggers them
| Flag in output | Separately licensable | Common trigger |
|---|---|---|
| Diagnostics Pack | Yes | An AWR snapshot or the EM performance page |
| Tuning Pack | Yes, needs Diagnostics too | A SQL Tuning Advisor run |
| Partitioning | Yes | A single partitioned table |
| Advanced Compression | Yes | A compressed tablespace or backup |
Missing proof of entitlement documents leave you unable to prove ownership, so during a review measured deployment defaults to unlicensed. The fix is entitlement archaeology across ordering documents, CSI history, and acquisition contracts.
Oracle licenses do not move automatically in a merger. The assignment clause in the original agreement governs whether an acquired entity's licenses transfer, and Oracle often requires written consent or a formal transfer request.
After several acquisitions, ordering documents sit in different systems under different legal entities. Nobody can state cleanly what the combined company owns, which is exactly the gap an audit is built to exploit.
Start from the CSI numbers, since each one links to the contract and ordering document that created it. Pull the full support renewal history, then request contract copies from Oracle for any CSI whose paperwork is lost.
Build one row per owned product and metric, sourced from ordering documents rather than the CSI, then keep it current as contracts change. The register is the entitlement side of every future reconciliation.
The CSI tells you what you pay support on today. The register tells you what you own, including perpetual licenses whose support you dropped years ago. Those are different questions, and the gap between them is money.
Keep it narrow enough to maintain and rich enough to reconcile against measured deployment. The schema below is the minimum that survives an audit conversation.
Minimum Oracle entitlement register schema
| Column | Why it matters |
|---|---|
| Product and edition | Decides which options ship free versus separately licensable |
| Metric | Processor or Named User Plus changes the entire count |
| Quantity owned | Taken from the ordering document, not the support line |
| Contract and CSI | The evidence link back to proof of entitlement |
| Support status | Active, lapsed, or terminated per line |
Refresh the register whenever you buy, retire, or inherit licenses, and reconcile it against fresh measurement at least annually. A register that drifts from reality is worse than none, because it manufactures false confidence.
For the wider Oracle picture, start with the Oracle knowledge hub or the Oracle advisory practice. For an always on review lane across all your vendors, see Vendor Shield.
No. Oracle provides no unified license dashboard. The position is triangulated from LMS measurement scripts, Enterprise Manager usage views, and the CSI entitlement records in My Oracle Support, reconciled against contracts.
Yes, and you should. They are read only measurement tools, and running them internally gives you the auditor's view before Oracle has it. The risk is not running them; it is Oracle running them first.
Not exactly. CSI records show what you pay support on, which can include shelfware and can omit perpetual licenses with lapsed support. Ownership is established by contracts and ordering documents.
Yes. The Diagnostics and Tuning packs that make EM useful are separately licensable, and enabling them without entitlement is one of the most common findings in our 2024 to 2025 baselines.
Annually at minimum, plus after every acquisition, virtualization change, or hardware refresh. Core counts and cluster topology change processor math even when the software estate is static.
The Assurance Service is a review you request; the Audit Service is one Oracle initiates. Both run on the same measurement data, so collecting the scripts yourself first means you enter either conversation already knowing the numbers.
Query DBA_FEATURE_USAGE_STATISTICS and run the options_packs_usage_statistics.sql report, which only read existing data. The risk is not the query; it is enabling a pack in Enterprise Manager, so restrict pack access before anyone explores.
Not automatically. The assignment clause in the original agreement governs transfer, and Oracle frequently requires written consent. Confirm the language before you assume an acquired entity's licenses are yours to deploy.
One row per owned product and metric, with quantity taken from ordering documents rather than the CSI, plus contract reference, support status, and edition. It records what you own, not merely what you currently pay support on.
For a mid sized estate, a first reconciled baseline typically takes a few weeks: script collection, CSI and contract gathering, hardware inventory, and reconciliation. Refreshing an existing baseline is far faster once the register exists.
The response sequence, the evidence standards, and the settlement levers for the next Oracle license review or audit letter.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
