I have been through enough Oracle audits on the client side to know how they go. Oracle shows up, or sends a letter, and the first instinct in the room is to treat it like a compliance conversation. It is not. By the time they make contact, they have usually already run their calculation. The audit is the presentation of a number they have already arrived at, and the negotiation that follows.
Understanding what that number is built from is the only way to respond to it effectively.
The License Management Services letter
Most audits start with a letter from Oracle License Management Services requesting a software asset survey. The survey asks you to run scripts on your systems that collect processor counts, installed features, and database options in use. What most organizations do not realize is that Oracle has often already modeled your environment from data collected through support portals, My Oracle Support, and the Automatic Diagnostic Repository uploads that happen by default when you open service requests.
The scripts they send you are a confirmation exercise, not a discovery exercise.
What they are actually counting
The core of any Oracle audit is processor licensing. Oracle Database Enterprise Edition is licensed per processor, and Oracle’s processor core factor table determines how many licenses each physical core requires. For Intel x86 processors, the factor is 0.5, meaning a server with 32 physical cores requires 16 Oracle processor licenses.
The calculation sounds simple. The complications come from:
Virtualization and partitioning. If you are running Oracle on VMware, Oracle’s position is that you are licensed for the entire physical host, not just the cores allocated to the VM. This is Oracle’s interpretation of their virtualization policy, and it is the single most common source of audit exposure I have seen. Customers assume they are licensed for four vCPUs. Oracle calculates based on the 32-core physical host underneath.
Database options in use. Enterprise Edition includes the base database. Everything else (Partitioning, Advanced Compression, RAC, Active Data Guard, Diagnostics Pack, Tuning Pack) is a separately licensed option. Oracle’s audit scripts check which features have been used, not which features you intended to use. A DBA who ran a single query against V$SQL_PLAN_STATISTICS_ALL in a test environment activated the Tuning Pack in Oracle’s feature usage tracking. That usage is now in the audit data.
Named user plus minimums. If you are licensed per named user rather than per processor, Oracle applies a minimum of 25 users per processor license. This catches organizations that licensed per user at small scale and have since grown the underlying infrastructure.
The feature usage tracking you probably have not checked
Oracle Database tracks feature usage in the DBA_FEATURE_USAGE_STATISTICS view. This view records every licensed feature that has been invoked, including the timestamp of first use and last use. Oracle’s audit scripts pull this view and cross-reference it against what you are licensed to use.
The features that generate the most unexpected exposure:
Diagnostics Pack. Anything that queries AWR, ADDM, or ASH uses the Diagnostics Pack. This includes third-party monitoring tools that connect to the database and pull performance data from these views. It includes DBAs running ad-hoc performance queries. It includes some default configurations in Oracle Enterprise Manager.
Tuning Pack. SQL Tuning Advisor, SQL Access Advisor, and automatic SQL tuning all require the Tuning Pack. If you have auto task maintenance jobs enabled with their default settings, Tuning Pack usage may be appearing in your feature usage data without anyone having made a deliberate choice to use it.
Partitioning. If any table in the database uses range, list, hash, or composite partitioning, Partitioning is in use. This one is usually intentional, but I have seen inherited environments where the option was enabled years ago by a previous DBA and no one had thought to check the licensing status.
What you can do before Oracle contacts you
The most valuable thing you can do is run your own assessment before Oracle does theirs. Pull DBA_FEATURE_USAGE_STATISTICS, review it against your license entitlements, and understand the gap before it becomes a negotiation.
If there is exposure, you have more options before the audit than after it. You can remediate usage, adjust infrastructure, restructure license agreements proactively, or at minimum enter the negotiation with accurate data rather than being reactive to Oracle’s calculation.
The Oracle License Risk Assessment I offer covers all of this: processor counts across your estate, virtualization policy analysis, feature usage review, and a remediation priority order that gives you a clear picture of where to focus first.
If you are running Oracle in production and have not done a licensing review in the last two years, you are flying without instruments. The next True-Up or audit will be the first time you see the gap.
