Oracle Database Options are the single largest source of unexpected audit claims. Diagnostics Pack is accidentally enabled in more than 40% of enterprise environments — often through Oracle Enterprise Manager clicking a single button. Tuning Pack, Partitioning, Advanced Security, In-Memory, and Real Application Clusters each carry separate, significant licence costs. Oracle's LMS scripts interrogate the data dictionary specifically for option feature usage — and the query evidence they collect is difficult to contest without expert preparation.
Oracle Database Enterprise Edition is the base product. The base product includes a broad set of database features — but Oracle has carved out specific advanced capabilities as separately licensed "Options" and "Management Packs." Each Option carries a per-processor licence fee that is typically 100-200% of the base database licence cost. Enterprise Edition at list price runs approximately $47,500 per processor. Diagnostics Pack adds $15,000 per processor. Partitioning adds $17,500 per processor. Real Application Clusters adds $23,000 per processor. In environments with significant processor counts, unlicensed option usage rapidly produces six, seven, and eight-figure compliance claims.
The trigger for an option licence obligation is not purchase or installation — it is use. Oracle's licence terms define use as any utilisation of a feature, regardless of whether it was deliberately activated. This creates the compliance trap: many Database Options are enabled by default in Oracle Enterprise Edition installations, activated inadvertently through tooling, or turned on through a single checkbox in Oracle Enterprise Manager (OEM) that a DBA checked during routine performance investigation.
The DBA Tool problem is one of the most common scenarios we see in our Oracle Compliance Review engagements. An administrator opens OEM to investigate a performance issue, navigates to the Performance Hub or SQL Monitoring screen, and those screens are powered by the Diagnostics Pack and Tuning Pack respectively. The act of viewing that screen — in Oracle's interpretation — constitutes use of the licensed option. The DWM$ (Database Workload Manager) and AWR (Automatic Workload Repository) tables are populated from that point forward, and the LMS scripts will find that data and report the option as "used."
Oracle's LMS audit process involves running a set of SQL queries against your Oracle Database's data dictionary and dynamic performance views. For database options, the relevant queries look at the DBA_FEATURE_USAGE_STATISTICS view — a table that Oracle's internal tracking engine populates with records of every feature that has been accessed since the database was installed. The key columns are:
The DBA_FEATURE_USAGE_STATISTICS view is populated by Oracle's built-in statistics collection mechanism (DBMS_FEATURE_USAGE_INTERNAL), which runs automatically as part of the database's maintenance window. Once a feature is recorded as having non-zero detected_usages, Oracle's auditors treat this as evidence of licence obligation — regardless of whether the use was deliberate, business-critical, or was a single accidental activation years ago.
In addition to feature usage statistics, LMS scripts query the DBA_REGISTRY view for installed components, the V$OPTION view for options compiled into the database binary, and specific system tables associated with each option (for example, WRH$_SNAPSHOT for AWR, which evidences Diagnostics Pack use). The combination of these data sources makes it difficult to argue against feature usage once it has been recorded — but difficult is not impossible, and the extent and business purpose of the usage is contestable.
Our Oracle Compliance Review includes a full database options scan — we identify every feature that Oracle's LMS scripts will flag before they arrive, and build the technical record you need to defend your position.
Diagnostics Pack licences are required for access to Automatic Workload Repository (AWR), Active Session History (ASH), ADDM (Automatic Database Diagnostic Monitor), SQL Monitoring, and the Performance Hub in OEM. AWR data is collected by default in Enterprise Edition databases where the STATISTICS_LEVEL parameter is set to TYPICAL or ALL — which is the default. Simply having an Enterprise Edition database without setting STATISTICS_LEVEL=BASIC means AWR snapshots are being taken and Diagnostics Pack use may be recorded.
Tuning Pack licences are required for SQL Tuning Advisor, SQL Access Advisor, SQL Profiles, and Automatic SQL Tuning. In practice, Tuning Pack use is often driven by Oracle Enterprise Manager's "Advisors" menu, by scheduled automatic SQL tuning tasks (which are enabled by default in some Oracle configurations), and by developers using SQL Developer or OEM's performance tools to investigate query plans. Any EXECUTE call to DBMS_SQLTUNE that is not preceded by a documented DBA decision and licence confirmation constitutes Tuning Pack use.
The defence strategy for Diagnostics Pack and Tuning Pack claims depends on the vintage and context of the usage evidence. Where feature usage statistics show single-digit or low-double-digit usage events concentrated on specific dates (often during an upgrade or OEM configuration), there is a credible argument that the use was incidental, inadvertent, and was not in service of any business function that created value from the option features. This is not a guaranteed defence, but it is a meaningful negotiating position that our audit defence team has used to reduce option claims substantially — sometimes to zero — in engagements where the usage evidence was thin.
Prospectively, the most effective controls are: setting STATISTICS_LEVEL=BASIC on databases where Diagnostics Pack is not licensed; disabling automatic SQL tuning tasks via DBMS_AUTO_TASK_ADMIN; and restricting DBA access to the OEM screens that invoke Tuning Pack functionality. These settings must be implemented and documented before an LMS audit is initiated — attempting to implement them after Oracle's audit letter arrives does not retroactively eliminate the usage history already recorded.
Oracle Partitioning licences are required for any database object that uses range, list, hash, or interval partitioning — including system-managed partitioning used internally by some Oracle features. Partitioning claims frequently arise in two scenarios: deliberate partitioning of large tables (where DBAs implemented partitioning for performance without realising it requires a separate licence) and inherited partitioning (where a database was migrated from a licensed environment to one without the option licence, bringing partitioned tables with it).
The inherited partitioning scenario is particularly problematic in M&A contexts. When an acquired company's Oracle Database is migrated into the acquirer's environment, existing partitioned tables migrate with the data. The acquiring entity's Oracle licence may not include Partitioning, but the data dictionary will record partitioned objects from day one of the migration. Our Oracle Audit Guide covers M&A licensing exposure in detail — it is one of the most complex and most underestimated compliance risks in enterprise transactions.
Detecting partitioning usage in your estate before an audit is straightforward: query DBA_PART_TABLES, DBA_PART_INDEXES, and DBA_FEATURE_USAGE_STATISTICS for Partitioning. The challenge is that many ITAM teams do not run this query as part of standard discovery, and the first time the data is reviewed is when Oracle's LMS report arrives with a multi-million-dollar claim.
Advanced Security licences are required for Transparent Data Encryption (TDE) and Oracle Data Masking. TDE is increasingly triggered by compliance mandates (PCI-DSS, HIPAA, GDPR) — security teams implement TDE to satisfy regulatory requirements without realising that TDE requires an Oracle option licence. The encryption of a single tablespace or column creates a Diagnostics Pack equivalent situation: the feature is recorded in the data dictionary and LMS will identify it.
Database In-Memory licences are required when any database object uses the INMEMORY clause. In-Memory is sometimes inadvertently enabled through migration scripts, third-party tools, or template-based table creation in development environments that then promote to production. Even setting INMEMORY_SIZE to a non-zero value at the instance level can constitute use if Oracle's feature tracking records any In-Memory activity.
Other frequently audited options include Oracle Label Security (required for row-level security policies), Oracle Database Vault (required for access control on DBA accounts), Oracle Multitenant (required for more than one PDB/CDB in certain configurations), and Oracle Spatial and Graph. Each option has its own detection mechanism in the LMS scripts and its own unit price. In a large enterprise Oracle estate, it is common for LMS audits to identify simultaneous accidental use of three to five options — producing a combined back-licence claim that dwarfs the base database licence cost.
Real Application Clusters (RAC) requires a separate Oracle licence for every processor in every node of the cluster. Data Guard, by contrast, is included in Enterprise Edition at no additional licence cost — but only if the standby database is passive (i.e., the secondary instance is not open for read-only queries). The moment Active Data Guard (ADG) is used to open the standby for read queries, an Active Data Guard Option licence is required, at approximately $23,000 per processor.
The distinction between passive Data Guard and Active Data Guard is one of the most frequently exploited compliance gaps in Oracle audits targeting high-availability environments. DBAs configure their standby databases to support query offloading — a natural performance optimisation — without understanding that this configuration triggers the Active Data Guard licence requirement. The LMS scripts query V$DATABASE and the GV$ views to determine whether the standby is open in read-only mode. If it is, and if there is a history of queries having been executed against it, Oracle will claim ADG option licence fees for every processor in the standby environment.
Our Oracle Compliance Review service specifically includes an assessment of RAC and Data Guard configurations as part of our standard engagement scope. We have helped enterprises restructure their high-availability architectures to achieve compliance without sacrificing availability — and we have successfully contested ADG claims where the evidence of active query use was ambiguous or historical usage was de minimis.
Our audit defence specialists have extensive experience challenging Oracle's RAC and Active Data Guard claims. Many enterprises have resolved these disputes for substantially less than Oracle's initial claim — in some cases to zero.
The most effective defence begins before the LMS audit, not after. Our approach to Oracle database option claims involves three phases: internal discovery, evidence documentation, and challenge framing.
Internal Discovery. Before Oracle arrives, run the same queries Oracle will run. Query DBA_FEATURE_USAGE_STATISTICS for all features with detected_usages greater than zero. Cross-reference against your Oracle licence entitlements. For any feature where usage is recorded but the option is not licensed, assess whether the usage was deliberate, business-critical, or inadvertent. Document the date and context of usage. This becomes your audit response evidence base.
Evidence Documentation. For inadvertent or trivial usage, document the business context — who ran what, on which date, and whether it produced any business output dependent on the licensed feature. A single DBA clicking into a performance screen that happened to invoke Diagnostics Pack functionality, with no AWR report having been generated or consumed, is a much weaker compliance claim than a production monitoring architecture built on AWR. Oracle's licence agreement requires use that provides value — use that had no business consequence is a contestable claim.
Challenge Framing. Once Oracle presents its audit report, the quantum of each option claim should be challenged on both technical and contractual grounds. Technical challenges focus on the accuracy and interpretation of the LMS script output. Contractual challenges focus on the licence metric — whether the option claim is calculated against the correct processor count, whether virtualisation rules have been correctly applied using the Core Factor Table, and whether any existing licence entitlements provide coverage that Oracle's audit methodology has not credited.
Case study reference: A multinational logistics firm came to us with a $12M Diagnostics Pack claim from Oracle LMS. The claim was based on AWR snapshot data going back seven years across 14 database instances. Our review established that STATISTICS_LEVEL had been set to TYPICAL across the estate as a default configuration — not as a deliberate choice to use Diagnostics Pack — and that no AWR reports had been generated or consumed by any business process. We challenged the claim on the basis that the feature usage was incidental to the default installation configuration and produced no business value. The claim was settled at $1.9M — an 84% reduction. See our case studies page for similar examples.
A complete guide to Oracle Database editions, options, metrics, and virtualisation rules — with worked examples and the queries you need to audit your own estate before Oracle does.
Download Free →Weekly briefings on audit activity, licensing changes, and negotiation tactics. Read by ITAM and procurement leaders at 200+ enterprises.