Oracle Database audit: what LMS looks for.

An Oracle Database audit is a structured exercise. Oracle Licence Management Services, the LMS team that runs the formal audit, follows a methodology that has been refined over twenty years. The methodology covers a defined list of deployment scenarios, runs a defined set of scripts, and produces findings in defined categories. The auditor is not improvising. The customer who understands the methodology can defend against it. The customer who treats the audit as an open ended fishing expedition gives Oracle the room to find what it is looking for.

This article walks through what LMS actually looks at in an Oracle Database audit. It covers the scripts, the deployment patterns that trigger findings, the metric calculations that drive the dollar number, and the contract clauses that govern the audit itself. The objective is to remove the asymmetry between what Oracle knows about audit and what the customer knows.

The audit notification and the contract right

An Oracle Database audit begins with an audit notification letter. The notification cites the audit clause in the customer's Oracle Master Agreement or Software Licence and Services Agreement. The clause typically grants Oracle the right to audit on 45 days notice, during normal business hours, with reasonable scope. The clause does not grant Oracle the right to run discovery scripts against production environments without negotiation.

The buyer side response to the notification is to acknowledge receipt, request the audit scope in writing, request the list of products and entities covered, and confirm the notification window. Every subsequent step in the audit happens against this defined scope. Customers who fail to scope the audit at notification stage often find the audit expanding into adjacent product lines and adjacent business units during the data collection phase. How to reject Oracle audit demands covers the demand response in detail.

The LMS scripts and what they collect

Oracle LMS uses a standard collection toolkit on Database audits. The most common scripts are Oracle Server Worksheet, which collects database installation metadata, and the LMS Collection Tool, which queries production databases for option usage. The scripts collect three categories of data. Installation data, including version, edition, patch level, and host metadata. Configuration data, including initialisation parameters, granted privileges, and enabled features. Usage data, including option usage views, DBA_FEATURE_USAGE_STATISTICS, and segment statistics.

The usage data is where most findings originate. Oracle's view is that any usage of a chargeable option, however brief, however accidental, constitutes a licensable deployment. A single test query against the Partitioning option, run on a single database, on a single day, three years ago, is a finding. Customers commonly run the LMS scripts thinking they are providing factual data and discover that the scripts have collected several million dollars of incidental option usage. Audit defense includes a script review step before any data leaves the customer environment.

The named user plus metric and processor metric

Oracle Database licences run on one of two metrics, named user plus or processor. The metric calculation produces the licence count from the deployment fact. Named user plus counts every human user and every device that connects to the database, plus a minimum count per processor as defined in the licence definitions document. Processor counts the cores on the host running the database, multiplied by the Oracle core factor for the processor type.

The processor calculation is where most audit dollar overstatements occur. Oracle's default position is to count every core on every host that has Oracle Database installed, regardless of whether the database is running, regardless of whether the host is in production, regardless of whether the customer can reasonably restrict the deployment to a subset of cores. The buyer side mark up applies the actual processor count to the actual licensable deployment, using approved partitioning technology, with documentation that meets Oracle's hard partitioning policy. Oracle named user plus audit issues covers the named user calculation in detail.

Virtualisation and the soft partitioning trap

Oracle's soft partitioning policy is the highest leverage finding category in Database audits. Oracle defines a list of approved hard partitioning technologies, including Oracle VM with CPU pinning, LPAR on AIX, and Solaris Zones with capped projects. Everything else, including VMware on Intel, is soft partitioning in Oracle's view. Soft partitioning requires licensing of every core in the virtual cluster, not just the cores running the Oracle workload.

A customer running Oracle Database on three virtual machines in a VMware cluster with one hundred and twenty cores will be assessed as requiring one hundred and twenty licensable cores, not the four cores actually running Oracle. The dollar number is straightforwardly enormous. The buyer side defence is a combination of contractual mark up at signature, technical isolation of Oracle workloads in dedicated clusters, and documentary evidence of the actual deployment boundary. Database licensing covers the deal type level mechanics.

The disaster recovery and standby instance question

Oracle's standard position on disaster recovery is that any database instance running Oracle software requires a full licence, regardless of whether the instance is active, regardless of whether the instance has ever been used. The exception is the ten day rule, which allows an unlicensed standby for up to ten days per year of actual production failover. Customers commonly run hot standbys, cold standbys, and disaster recovery clusters that all carry full licence requirements under Oracle's interpretation.

The negotiation lever is in the contract language at signature, where the customer can establish a defined disaster recovery exception. The audit defence lever is in the documentation of standby usage, which must demonstrate that the ten day rule is met. Customers who cannot demonstrate compliance with the ten day rule will be assessed for full licences on every standby instance. Oracle Database covers the broader product context.

The option usage findings and the Diagnostics Pack trap

The Oracle Database options and packs sit on a separate licence layer above the core database. The Diagnostics Pack and the Tuning Pack are the two most commonly found in audit. Each pack is licensed by named user plus or processor count against the database it serves. A customer with twenty unlicensed databases, each running on twenty cores, who has been using the Diagnostics Pack views faces a four hundred core licence demand at list price, on top of the base database licensing.

The trap is that the Diagnostics Pack views, including the AWR and ASH reports, are enabled by default. A database administrator who pulls an AWR report, even once, has used the Diagnostics Pack. The DBA_FEATURE_USAGE_STATISTICS view records the usage. The LMS script reads the view. The audit finding follows. The buyer side defence is to disable the option entirely at the database parameter level on unlicensed databases, with a documented change date that precedes the audit notification.

The audit settlement dynamic

An Oracle Database audit produces a findings document, typically two to four months after the data collection. The findings document lists each compliance gap, the dollar value at list price, and Oracle's preferred remediation. The remediation is invariably the purchase of additional licences and several years of back support, sometimes plus a cloud component. The dollar number on the findings document is the negotiation starting point, not the answer.

The buyer side settlement work is to deconstruct the findings, contest the disputable items, reduce the list price to a negotiated discount, and structure the settlement as a forward looking deal rather than a back support payment. A well negotiated Database audit settlement typically resolves at 20 to 40 percent of the initial findings number. When to engage an audit defense advisor covers the engagement timing. For the broader framework download The Audit Defense Handbook.