Step-by-Step Guide: Analyzing Oracle LMS Tool Output for Database Licensing

Step-by-Step Guide: Analyzing Oracle LMS Tool Output for Database Licensing

Oracle’s License Management Services (LMS) collection tool audits Oracle Database usage and determines licensing needs. The output from this tool includes detailed data on your Oracle Database installations, such as edition (Standard vs. Enterprise), enabled Database Options (like Partitioning or Advanced Compression), and usage of Management Packs (like Diagnostics or Tuning Pack).

This guide provides a step-by-step approach for Software Asset Management (SAM) managers and Oracle license administrators to interpret LMS output and identify required Oracle Database licenses. We focus only on Oracle Database products (not middleware or applications), explaining where to find each piece of data (e.g., in options_report.txt, inventory.xml, DBA_FEATURE_USAGE_STATISTICS, DBA_REGISTRY, etc.), how to interpret feature usage (Partitioning, Advanced Compression, Diagnostics Pack, Tuning Pack, etc.), and map those findings to licensing requirements.

We’ll also highlight common false positives and what to document to prepare for an Oracle audit.

Note: Oracle’s LMS script outputs contain a disclaimer that the data is for informational purposes and may include false positives (e.g., usage by sample schemas or internal operations)​

. Despite this, any usage flagged in the report needs careful review – Oracle may still consider it licensable unless you can prove it’s a known false positive or disabled feature. Keep this in mind as you analyze the data.

Step 1: Collect and Review the LMS Output Files

After running the Oracle LMS collection tool on your database servers, you will receive a bundle of output files (often a ZIP or TAR archive). Begin by gathering the relevant files for Oracle Database from this archive. K

ey files and data sources typically include:

• inventory.xml: An XML inventory of Oracle products installed on the server. This will list the Oracle Database software version and edition, such as Oracle Database 19c Enterprise Edition or Standard Edition. It may also include details such as the Oracle home location and the components installed.
• Options usage report (e.g. options_report.txt or LMS_OPTIONS.csvA summary report generated by the script shows which Database Options and Management Packs are installed or used. This is often compiled from queries against the database (such as V$OPTION, DBA_FEATURE_USAGE_STATISTICS, DBA_REGISTRY, etc.). It will indicate whether each optional feature is enabled/installed and whether usage has been detected.
• Database feature usage data: The LMS tool usually runs Oracle’s feature usage tracking queries. This may be included in the options report or as separate outputs. Key sources are:
  • DBA_FEATURE_USAGE_STATISTICS: an Oracle view that tracks usage counts and last usage dates for various database features (options and pack features).
  • DBA_REGISTRY Shows which components are installed in the database (e.g., Oracle Partitioning, Oracle OLAP, Oracle Advanced Analytics, etc.) if they are installed.
  • V$OPTION: shows boolean values (TRUE/FALSE) for whether certain options are available/enabled in the binary (e.g., Partitioning, Real Application Clusters, etc.).
• Hardware and user data: The LMS script also collects hardware info and user counts:
  • CPU information: number of processors/cores, CPU architecture, and in some cases, virtualization details. This might be found in a hardware summary section or a file like db_server_info.txt. For example, it might list a server name, operating system, CPU model, number of cores, and whether it is running in a virtualized environment.
  • Database user counts: The script may query DBA_USERS or similar to count Named Users. It might list total users and active accounts, which is relevant if you license by Named User Plus (NUP)​.
• Other files: Depending on the LMS script version, there could be additional files (like LMS_DBA_USERS.csv, LMS_OVERVIEW.csv, etc., as seen in some tools​). Review the file list and open any that pertain to database options, features, or license. Many SAM tools or scripts will label these clearly (e.g., anything with “options”, “usage”, or “license” in the name).

Tip: Organize the output files per database server. If multiple Oracle instances exist on one server, the output usually has separate sections or files for each instance. Make sure you identify which data corresponds to which database instance.

Step 2: Identify Database Instances, Editions, and Versions

The first licensing question is: Which edition of Oracle Database is running, and what version? The edition (Standard vs. Enterprise) determines which features can be used and the required base license type.

Using the LMS output:

• Locate Edition and Version: Open the inventory or overview file (e.g. inventory.xml) and search for the database product name. You should find entries indicating the Oracle Database version and edition. For example, an LMS report might show a line like:
  Oracle Database Edition: Enterprise Edition 19.12.0.0.0​ (meaning Oracle 19c Enterprise Edition, patch level 19.12). In another case, it might indicate Standard Edition (or Standard Edition 2). Record the edition for each instance.
• Identify Standard vs. Enterprise: This is crucial because Standard Edition (SE) databases include only core functionality, while Enterprise Edition (EE) databases can utilize additional options or packs, which require separate licenses. If the output indicates that an instance is Standard Edition, you should not expect any Enterprise-only options to be in use; if they are, that’s a compliance issue. If it’s the Enterprise Edition, you must check for the use of optional features in the subsequent steps.
  • Standard Edition naming: Depending on the version, you may see ‘Standard Edition’ (SE), ‘Standard Edition 1’ (SE1), or ‘Standard Edition 2’ (SE2) in the output. SE1 was used in older versions (10g and 11g), and SE2 was introduced with 12c. For licensing analysis, all are considered part of the Standard Edition family (licensed per socket, with feature limitations).
  • Enterprise Edition: Usually labeled “Enterprise Edition” in the output. Only EE supports add-on options and packs, such as Partitioning and Advanced Security.
• Example: In a sample LMS output for a server, you might see: pgsqlCopyDatabase Instance: ORCL1 Edition = Oracle Database Enterprise Edition (19.12.0.0.0) Database Instance: ORCL2 Edition = Oracle Database Standard Edition 2 (19.12.0.0.0) This tells us ORCL1 is EE (which means we must check for any EE options used), and ORCL2 is SE2 (which cannot use EE-only options or packs). Document these for each instance.
• Version and Patch Level: Note the version (e.g., 11g, 12c, 19c), as some features become available or licensable only in certain versions. For instance, Oracle Multitenant (Pluggable Databases) is a feature introduced in 12c. If you have 12c or later, the LMS output may mention if multitenant is in use, which is an Enterprise Edition (EE) option. Also, the licensing rules for Standard Edition changed in 12c (SE2 replaced SE/SE1, with core/socket limits), which may be relevant when analyzing hardware limits.

By the end of this step, you should have a list of all Oracle DB instances covered by the LMS output, along with each instance’s edition and version. This forms the foundation for licensing requirements: e.g. an Enterprise Edition instance will need at least an EE license for the server’s processors, whereas a Standard Edition instance will need SE processor licenses (and cannot use EE-only add-ons).

Step 3: Analyze Database Options Usage (Partitioning, Advanced Compression, etc.)

Next, evaluate the usage of Database Options. These are optional features of Oracle Database (mostly available only with Enterprise Edition) that require separate licenses if used.

Examples include Oracle Partitioning, Advanced Compression, Real Application Testing, OLAP, Spatial and Graph, Oracle Multitenant, etc.

The LMS output provides insight into which options are installed and which have been used:

• Find the Options Usage Report: Open options_report.txt or the equivalent report file from the LMS output that lists database options. It might be organized as a list of features with statuses such as “Installed”, “Used”, and “Not Used”. For example, an output might show: markdownCopyInstalled Options for instance ORCL1: – Partitioning: Installed **Used** (Last Used: 2024-11-01) – Advanced Compression: Installed **Not Used** – OLAP: Installed **Used** – Data Guard Broker: Enabled (for standby management) This indicates Partitioning and OLAP options are installed and used, while Advanced Compression is installed but not used. “Data Guard Broker: Enabled” means the database is configured for Data Guard. However, basic Data Guard is part of EE and not a separately licensed option, unless using Active Data Guard – more on that later.
• DBA_REGISTRY and V$OPTION: In some outputs, you might see raw data from DBA_REGISTRY or V$OPTION. For example, V$OPTION might list Partitioning = TRUE (enabled in binary) and Oracle Label Security = FALSE if it is not installed. DBA_REGISTRY Would list components like “Oracle Database Partitioning” with a status (VALID) if installed. These confirm what options are present in the database installation. Presence does not equal usage, so we check feature usage next.
• Feature Usage Statistics: The usage of options is determined by DBA_FEATURE_USAGE_STATISTICS. The LMS tool likely uses this to mark an option as “Used” if any usage was recorded. For instance, if a single partitioned table exists or existed, the feature usage view will have an entry for partitioning with a detected usage count. The options report may include a count or date, e.g. “Partitioning… Used 10 times, Last Used: 2024-11-01​. A “Not Used” status typically means no usage was recorded (Detected_Uages = 0 in the view).
• Interpreting Option Usage: For each option listed:
  • “Used” means the feature was utilized at least once. A single use (creating one partitioned table or running one compressed backup that counts as Advanced Compression) will flag the option as used. Oracle’s policy is that if an option is used, you must license it for that database environment. The LMS output often shows historical usage, so it might catch features that were used in the past and even later disabled. For example, if Partitioning was used but later turned off, the report will still show it was used (with the last usage date). Oracle could consider that non-compliant for the period of use​.
  • “Not Used” means the feature hasn’t been exercised according to Oracle’s tracking. Generally, if an option is installed but not used, you don’t need to purchase its license. However, installing it is risky – it could be triggered accidentally. Oracle LMS scripts are designed to detect any usage, even unintended. Removing or disabling unlicensed options is a good practice to prevent accidental use.
  • Counts and Dates: Consider any usage counts or dates in the report. They indicate how frequently and when the feature was last used. For instance, “Advanced Compression – Used 3 times, Last Used: 2025-02-10” tells you that the feature was actively used and when it was last used. This helps in assessing if usage is ongoing or historical.
• Common Database Options to check:
  Here are some of the main options and what to know about them:
  • Partitioning – Allows partitioned tables and indexes. A license is required if you want to use it on the Enterprise Edition. (Standard Edition databases do not support Partitioning at all; any indication of Partitioning usage on an SE database could be a false positive or a sign of an attempted partitioned object.)
  • Advanced Compression—Enables OLTP Table Compression, Data Pump compression, etc. If used, it requires an Advanced Compression license. Check for compression use in backups or tables. (Note: Oracle SecureFiles compression (for LOBs) also falls under this option in newer versions.)
  • OLAP – Oracle OLAP option for analytic cubes. Requires a license if used (primarily in EE). If your workload doesn’t intentionally use cubes, but OLAP shows “Used,” investigate (could be a false positive or something like sample schemas using OLAP).
  • Real Application Testing (RAT)—Includes Database Replay and SQL Performance Analyzer. If used, it requires the Real Application Testing option license. The report might flag usage if those features were run.
  • Spatial and Graph—If used, they require a license. However, as of Oracle 19c, Standard Edition 2 includes basic Spatial features at no additional cost. Oracle made Spatial free for EE and SE2 in 2019. Older versions required licensing. If the tool shows that Spatial is used (e.g., by SDO_* functions), ensure you check Oracle’s current licensing rules.
  • Oracle Multitenant – If using pluggable databases (PDBs). In 12c and up, having more than one user-created PDB per container database requires the Multitenant license. The LMS output may explicitly list “Multitenant: X PDBs” in use. For example, “Multitenant Option: 3 PDBs (license required)”. If only 1 PDB (besides the seed) is present, that’s allowed without the option license; more than one PDB in a CDB triggers the need for Multitenant licensing.
  • Advanced Security, Database Vault, Label Security – These are security options. If features like Transparent Data Encryption (TDE), Data Redaction (Advanced Security option), or Database Vault are enabled, they require separate licenses. The usage might not always be obvious from DBA_FEATURE_USAGE_STATISTICS (e.g., TDE usage might be tracked differently), But the LMS script could detect if the feature is configured.
  • Real Application Clusters (RAC) – RAC is technically an option for Enterprise Edition, which allows clustering a single database across multiple servers. The Oracle RAC option must be licensed if the output indicates RAC is “Enabled” or in use (e.g., it lists multiple instances as a cluster or V$OPTION shows Real Application Clusters = TRUE with usage). (Note: Standard Edition (SE) included RAC at no extra cost for up to 4 nodes in SE1 and up to 2 in SE2 for versions 12.1 and 12.2; Oracle 19c SE2 no longer allows RAC. But in any case, if your environment is using RAC with EE, license the RAC option for all cores. If using SE2 RAC (pre-19c), ensure it is within the allowed limits.
• Watch for False Positives: Sometimes, feature usage tracking can show an option as used even if you think you never used it. Known examples:
  • Partitioning: Installing Oracle’s sample schemas, such as the SH schema, can create partitioned tables as examples. This would flag Partitioning as “used” even if your application didn’t use it. Oracle’s script notes explicitly mention that sample schemas (such as HR and SH) can trigger false usage. Nevertheless, you would need to explain this in an audit and show that it was only the sample schema. The best practice is to remove sample schemas from production.
  • Advanced Compression: Certain Oracle internal operations or bugs have caused false positives. For example, a known bug caused RMAN backup with default compression to be misreported as Advanced Compression usage​. Also, Hybrid Columnar Compression (an Exadata feature) may appear incorrectly if you migrate a table with that attribute to a non-Exadata system.
  • Others: As a former LMS auditor noted, there are numerous bugs where DBA_FEATURE_USAGE_STATISTICS Misreport usage​. For example, the In-Memory option was reported as being used even when not configured (a bug in early 12c releases), and Real-Time SQL Monitoring (a feature of the Tuning Pack) could show “permanent usage” even if it was only run for a moment. Keep these in mind – if an option is flagged and surprises you, research if there’s a known bug or false positive for your DB version.

Action: For each option marked “Used” in the output, determine if you have a corresponding Oracle option license. If you do not, investigate whether the usage is legitimate or a false positive. Document any findings (e.g., “Partitioning used – 5 partitioned tables exist in schema X” or “Partitioning used – only in sample schema, now removed”).

We’ll address licensing implications in Step 5, but first, let’s check the management packs.

Step 4: Analyze Management Packs Usage (Diagnostics Pack, Tuning Pack, etc.)

In addition to these options, Oracle Enterprise Edition offers Management Packs that extend database manageability, performance monitoring, and security. The most common (and critical for license compliance) are the Diagnostics Pack and Tuning Pack, which are often enabled by default in EE environments.

Others include Database Lifecycle Management Pack, Data Masking and Subsetting, etc. Use the LMS output to identify any usage of these packs:

• Find Pack Usage in the Report: The options/usage report typically lists the status of management packs separately or alongside options. Look for names like “Diagnostic Pack”, “Tuning Pack”, “Database Vault”, “Data Masking Pack”, etc., often with an indication of “Used” or “Not Used”. For example: markdownCopyManagement Packs Usage: - Diagnostic Pack: **Used** - Tuning Pack: **Used** - Database Vault: Not Used This tells us that the Diagnostics Pack and Tuning Pack features were accessed in that database​, , while Database Vault was not used.
• What are Diagnostics and Tuning Packs?
  • The Diagnostics Pack includes Automatic Workload Repository (AWR), Automatic Database Diagnostic Monitor (ADDM), Active Session History (ASH), and other performance monitoring utilities. It is a separately licensed pack that requires Enterprise Edition. Any use of AWR or related features implies the use of the Diagnostics Pack. Oracle, by default, collects AWR snapshots in EE (every hour), which ironically means you are expected to disable this collection if you haven’t licensed Diagnostics. The LMS script will detect if AWR is active, if ADDM reports have been run, etc. A tell-tale sign is the presence of data in DBA_HIST* views or execution of DBMS_ADVISOR tasks.
  • The Tuning Pack includes SQL Tuning Advisor, SQL Access Advisor, and SQL Plan Management features. It also requires the EE and Diagnostics Pack as prerequisites. The Tuning Pack’s usage may be recorded if the automated SQL Tuning Advisor runs during maintenance windows, if a tuning task is manually invoked, or if the Enterprise Manager’s tuning features are used. The LMS tool can detect this through feature usage statistics (e.g., entries for “SQL Tuning Advisor” usage) or internal indicators.
• Other Packs:
  • Oracle Database Vault – A security product (separate license) that, if enabled, will be visible (Database Vault status = ENABLED in the DB). LMS output often flags if DB Vault is configured. If it’s “Used”, you need a license for it.
  • Oracle Label Security is another security option, often listed in the options section, but Oracle refers to it as a “feature.” If it exists, it requires a license.
  • Data Masking and Subsetting Pack—used for masking data in non-production; typically used via Oracle Enterprise Manager. It is unlikely to appear unless EM was used to mask the data, but if present, it requires a license.
  • Cloud Management Packs, etc. – Less common are packs for specific purposes, such as the Database Lifecycle Management Pack. Check the output for any mention of these.
• Interpreting Pack Usage: If a pack is listed as “Used”, it means some feature of that pack was utilized:
  • Diagnostics Pack – Used: This usually means AWR snapshots exist and/or someone accessed an AWR report or ADDM. Since AWR is enabled by default, many EE databases inadvertently “use” Diagnostics Pack unless DBAs explicitly disable it. From a licensing perspective, if LMS shows that Diagnostics Pack is used, Oracle will assert that you need to license it for that database. (To avoid this, DBAs can set CONTROL_MANAGEMENT_PACK_ACCESS = NONE to disable these packs if they aren’t licensed​.)
  • Tuning Pack—Used: This can be triggered by the automatic SQL tuning advisor (which runs by default weekly) or by manually using tuning tools. If flagged, assume that the Tuning Pack license is required. Note that you also need to have the Diagnostics Pack licensed to use the Tuning Pack.
  • Both Packs Used: It’s common to see both Diagnostic and tuning packs used together, as tuning features often leverage diagnostic data. Each requires its license.
  • Other Packs—Used: For example, ‘Database Vault’ used means DB Vault was active (a license is needed).
• False Positives for Packs: Similar to options, there are a few known scenarios:
  • Some Oracle background tasks might flip a feature usage bit. For example, Real-Time SQL Monitoring (a feature under the Tuning Pack) could show “TRUE” even if you didn’t explicitly use it due to an Oracle bug​.
  • However, if the LMS output says a pack was used, you should assume it’s valid unless you have evidence otherwise. Oracle’s stance is typically that any reported usage = a licensable event. The onus would be on you to argue that a bug or mistake is false if you claim it’s not.
  • If you know your team never used a certain pack, yet it’s marked as used, investigate the specific features. For instance, check if AWR (Diagnostic) was running by default or if any SQL tuning sets exist. Sometimes, DBAs are unaware of the default behavior that triggers pack usage.
• Example: Suppose the LMS report, for instance, ORCL1, shows Diagnostics and Tuning Pack as “Used”. Upon investigation, you find that AWR is enabled (by default in EE) and the Auto SQL Tuning Advisor runs weekly. That explains the usage. You’re technically out of compliance if you have not licensed these packs. You can disable them going forward (stop AWR tasks via a parameter and disable auto-tuning tasks) – but past usage is already recorded.

Action: List all management packs reported as used for each database. Cross-check this with your entitlements:

• If you have licenses for them (e.g., you purchased Diagnostics Pack for four processors for that instance), great – ensure the licenses cover the usage.
• If not, mark this as a compliance gap. You must either acquire the license or cease usage and be prepared to justify to Oracle. In the next step, we’ll cover how to calculate quantities.

Step 5: Determine Required License Counts and Types

After identifying what is installed and used (edition, options, and packs), the next step is to determine how many licenses of each type are required to cover this usage.

This involves understanding Oracle’s licensing metrics (Processor vs Named User Plus) and applying them to the data:

1. Database Edition License – Processor or NUP:
   Oracle database licenses are usually sold by Processor (unlimited users on a given CPU configuration) or by Named User Plus (NUP, which is per user with a minimum per processor). Determine how your organization licenses each database. If you’re unsure, a safe assumption in an audit context is that processor licenses are for server environments (common for production) unless it’s a small environment where NUP was chosen. Use the LMS hardware data to calculate requirements:
   • Count the number of processor licenses required for Enterprise Edition on a given server. Oracle defines “processors” as cores multiplied by a core factor (specific to CPU type) for EE. The LMS output often provides core counts and may note the processor type. For example, if a server has 16 cores of Intel Xeon (each with a core factor of 0.5), that equates to 8 processor licenses for EE. Document the core count and the factor (Oracle’s core factor table can be referenced – e.g., Intel x86_64 is 0.5, SPARC might be 0.5 or 0.75 depending on model, etc.). Typically, the LMS script does not multiply for you; it just gives hardware info. You must apply the core factor and round up to the next number of licenses.
   • If the environment is virtualized (e.g., VMware), note that Oracle generally requires licensing all cores in the cluster, even if VMs can move across hosts, as Oracle does not recognize soft partitioning. The LMS output might show “Virtualization: VMware (Yes)”​, a red flag that you may need to consider the entire cluster’s cores for licensing, not just the VM’s cores. This is an advanced topic, but SAM managers should document if a DB is on VMware or another hypervisor, as it affects license scope.
   • For the Standard Edition (SE/SE2), licensing is based on processor sockets (not cores). SE2, for instance, counts up to 2 sockets max. The LMS output will show the number of sockets or the hardware type. For example, if an SE2 database is on a 2-socket server, you need 2 SE2 processor licenses (core counts don’t matter for SE, but there’s a limitation that SE2 can only run on servers with a maximum of 2 sockets). Ensure no violation of that (the script might not warn if someone accidentally ran SE2 on a 4-socket machine, which would violate license terms). Document how many SE processor licenses each Standard Edition DB needs (it should equal the number of occupied sockets, up to the edition’s limit).
   • Named User Plus (NUP): If your licenses are NUP, use the user count from the LMS output. For example, if the output shows ‘150 named users (120 active)”, then at least 150 NUP licenses are needed (Oracle licenses all named users, not just the active ones). Also, Oracle requires a minimum of 25 NUP per processor for EE (and 10 NUP per processor for Standard Edition). So, even if a DB has few users, you might need to license the minimum. For instance, an EE database on eight processors must have at least 8*25 = 200 NUP licenses, even if only 120 users are using it. If the LMS output shows 120 users but you have 100 NUP licenses, you’re under both the count and the minimum required​.
   • Example: ORCL1 (EE) on 16 cores (Intel) -> 8 Processor licenses required (if using Processor metric). ORCL2 (SE2) on two sockets -> 2 SE2 licenses are required. ORCL1 has 150 users -> if using NUP, needs 150 NUP licenses (which also meets the minimum since eight procs * 25 = 200 minimum, actually 150 would not meet 200; so Processor metric would likely apply or they need 200 NUP to cover).
2. Optional Database Options License Requirements:
   For each database where an option was “Used” (from Step 3), you need to account for a license of that option. Oracle’s policy is that options are licensed per the same metric and quantity as the database. That means if your database is licensed per processor and you use partitioning on that database, you must license partitioning for the same number of processors. If by NUP, then Partition by NUP for all users with the same minimums per processor. Summarize for each option:
   • For example, Partitioning is used on ORCL1 (which we determined needs 8 EE processors), and eight licenses of the Oracle Partitioning option are required​.
   • Advanced Compression used on that instance -> 8 licenses of the Advanced Compression option required.
   • If an option is used on a Standard Edition database (which normally can’t happen unless it was a false positive or a mistake), technically, that option isn’t even allowed. In an audit, Oracle might think you effectively needed Enterprise Edition + that option license for that usage. However, typically, they would discuss why an EE-only feature appears on SE. Avoid that scenario; it usually indicates a misclassified instance or a migration left with artifacts behind.
   • Some options, like RAC or Multitenant, apply at the cluster or instance level. For example, RAC used on a 2-node cluster with EE requires licensing the RAC option for all processors on both nodes (i.e., matching the EE licenses for those servers). Multitenant used (more than one PDB) on an EE database—license it for the entire instance (all processes).
   • Summarize per instance: For each instance, list the required option licenses. For example:
     ORCL1: Enterprise Edition (8 processors) plus Partitioning (8 processors), Advanced Compression (8 processors).
     ORCL2: Standard Edition 2 (2 processors) – no options are allowed/used, so no options license is needed.
3. Management Packs License Requirements:
   Similar to options, any management pack requires a license for that database. These packs are also licensed per processor or per user, matching the DB’s licensing. Key packs to account for:
   • Diagnostics Pack: If used on ORCL1 (8 processors EE), you need eight diagnostics pack licenses for that server. If ORCL1 were NUP licensed, you would need to have Diagnostics Pack NUP licenses for all those users. Oracle sells pack licenses per processor or NUP, usually aligning with how you license the database.
   • Tuning Pack: It requires licenses (in the same quantity as Diagnostics, as it covers the same servers and users). Remember, Oracle doesn’t allow licensing Tuning Pack without Diagnostics Pack – so you can’t have tuning alone. Diagnostics are assumed to be used or licensed if tuning is used. So, if both are used, you need both licenses equally.
   • Other Packs: e.g., Database Vault used on ORCL1 -> 8 licenses of Database Vault. If on NUP, the license is per user.
   • Named User minimums: Oracle’s minimum NUP per processor also applies to packs if you license by NUP. Typically, if your database is NUP-licensed, the packs for that database must at least cover the same user count (and meet the min). This detail is often handled by aligning metrics (most prefer to license packs by processor to avoid tracking separate user counts).
   • Example continued: ORCL1 used Diagnostics and Tuning -> needs 8 Diagnostics Pack and 8 Tuning Pack licenses. ORCL2 (SE) cannot use these packs. If LMS is run on SE, it normally won’t report them because SE doesn’t have AWR or tuning.
4. Check for Overlaps or Unusual Cases:
   • If a feature like Active Data Guard (ADG) is used, note that it is a separately licensable option. The LMS output might show “Active Data Guard – Real-Time Query = Used” in the feature usage section. That would require the ADG option license (again, per processor). Basic Data Guard (physical standby with apply-only, no read-only queries) does not require a separate license; it is included in EE. So distinguish if the usage is the licensed ADG feature (typically indicated by “real-time query” or open read-only standby usage).
   • If Multitenant usage was noted (multiple PDBs in one CDB), ensure you count the Multitenant option license.
   • If you have any uncertainty, refer to Oracle’s official Database Licensing Guide for your version, which includes tables of features that require separate licenses. This can help double-check mappings (for example, Data Mining (part of “Advanced Analytics”) requires an option license if used, etc., although that might be less common).
   • Also, consider environment factors: e.g., if a server has multiple EE databases, you might have already licensed the server’s processors for EE – that covers all EE databases. However, options or packs are usually needed per database if that database uses them. However, since licenses are per processor, if two databases on the same server use Partitioning, you still need just one set of Partitioning licenses for that server (not double-counting the same core twice). Effectively, a license per core covers any number of instances on that core. Count the unique physical processors, but ensure that all instances using a feature on that server are accounted for. (If different servers, then each needs coverage.)

After this analysis, you should have a comprehensive list like:

• Server A / Instance ORCL1: 8 Processor licenses of Oracle EE; 8 Partitioning; 8 Advanced Compression; 8 Diagnostics Pack; 8 Tuning Pack. (Plus note if NUP minimums are an issue or if any shortfall exists.)
• Server A / Instance ORCL2: 2 Processor licenses of Oracle SE2; no options/packs used (no additional licenses).
• Server B / Instance XYZ: e.g., 4 Processor EE; 4 RAC; 4 Multitenant; etc., depending on usage.

Compare this with your current entitlements (what you own). Any item for which usage requires a license and you have none (or not enough) is a compliance gap that needs to be addressed.

Step 6: Document Findings and Prepare for an Audit

The final step is to compile all the information into a clear documentation or report for internal stakeholders and be prepared for an Oracle audit.

Here’s what to include and tips to get audit-ready:

• Summary of Each Database Instance: For each Oracle Database instance, document:
  • Server name and environment (production/test).
  • Oracle edition and version (from Step 2).
  • Hardware details: the number of cores (and core factor) or sockets if SE, plus any virtualization notes (e.g., “running on VMware cluster with X hosts”—Oracle will be interested in that).
  • License metric assumption (Processor or NUP and how many licenses are allocated to this instance currently).
  • Options Used: List any “Used” options (Partitioning, etc.) found on this instance​. For each, note whether you currently have that option licensed. If not, mark it as an issue. If usage is a false positive or trivial (e.g., “Partitioning – used by sample schemas only”), write that explanation. It’s advisable to remove or disable any unlicensed option and note the date you did so to show remediation.
  • Packs Used: List any “Used” management packs (Diagnostics, Tuning, etc.) and similarly note license status. If, for example, the Diagnostics Pack was used without a license, note that as a compliance gap and consider turning off the pack’s features to stop further usage. Document if you have now disabled it (e.g., set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on 5/Jan/2025) – This shows proactive compliance effort.
  • License Required vs Owned: For each instance, create a mini table of “Licenses Required” vs “Licenses Owned.” For example, you might have:
    • Enterprise Edition – Required: 8 processors, Owned: 4 → Deficit: 4 (meaning you’re under-licensed for EE on that server).
    • Partitioning Option – Required: 8, Owned: 0 → Deficit: 8 (used with no licenses owned).
    • Diagnostics Pack – Required: 8, Owned: 0 → Deficit: 8.
    • Tuning Pack – Required: 8, Owned: 0 → Deficit: 8.
    • This explicitly highlights the compliance issues in numeric terms.
• Consolidate Across Environments: If you have multiple servers, roll up the total licenses required versus those owned. Oracle will review compliance at the company level (although each instance typically requires a license). Suppose you have a surplus on one and a deficit on another. In that case, that can’t usually be offset unless the licenses are truly pooled – licenses are typically global but tied to usage. However, summarizing company-wide can help you see the big picture (e.g., “Total EE licenses owned: 20, total needed: 24, shortage of 4”).
• False Positives and Clarifications: Prepare a section explaining any known false positives or confusing output.
  • If sample schemas caused a feature to show “used”, mention that those schemas have been removed (with date) and that feature usage was an error. Keep evidence (e.g., screen captures of the schema/user or output from a refreshed DBA_FEATURE_USAGE_STATISTICS after removal showing the usage count stopped increasing).
  • If a feature was used in the past but is now disabled, note the date it was disabled. Oracle might still flag it, but demonstrating that it was a one-time or historical use and is no longer in use might influence their approach (they could still technically charge for past usage, but it’s part of the negotiation).
  • If any usage corresponds to a known bug (as per Oracle MOS notes) and did not provide the actual benefit of the feature, have the MOS IDs or documents ready​. For instance, you can reference “MOS Bug #16088534 – RMAN Compression false positive for Advanced Compression – confirms our usage was falsely logged.” This can sometimes be used in discussions with Oracle to waive that finding.
• Action Plan for Compliance Gaps: For any deficits found, outline your plan:
  • Will you purchase additional licenses? If so, list which ones and how many.
  • Will you remove or turn off features? For example, “Diagnostics Pack will be disabled on these 3 instances to stop unlicensed usage; going forward, we will use Statspack (which is free) for performance stats instead of AWR.”
  • Are there architectural changes planned? (Sometimes, an option can be eliminated by redesign, etc. Document if relevant.)
  • Oracle auditors appreciate when you’ve taken compliance seriously. Showing a plan or steps taken can sometimes alleviate penalties if an audit occurs, as it demonstrates good faith efforts.
• Internal Review: Have the documentation reviewed by the technical DBAs and the SAM compliance team together. Ensure that everyone agrees on what was found and how it is interpreted. DBAs can confirm whether the reported “usage” was expected or a surprise. This is also a good time to educate the DBA team on these findings – for example, they might not have realized that having AWR on with no Diagnostic Pack license was a compliance issue.
• Maintain an Evidence Archive: Keep the raw LMS output files and any subsequent logs, such as those from running a fresh feature usage report after making changes. In an audit, Oracle will want the raw output (don’t alter those). Your documentation is for internal use and to prepare for audit defense. You won’t normally give Oracle your internal analysis (especially if it highlights gaps!), but it prepares you to answer questions and decide what to fix beforehand​. Oracle’s advice (and that of license consultants) is to always analyze LMS script output internally before handing it to Oracle​. This way, you can address non-compliance quietly.
• Stay Updated: Oracle licensing rules and the LMS scripts evolve. For example, Oracle may include new options in later versions or change what is free versus licensable. For instance, Oracle has made certain features free in recent versions; always check the latest “Oracle Database Licensing Information” guide for your version. Also, if you run LMS scripts again in the future, compare the results to see if any new usage has appeared.
• Audit Simulation: It might help to treat your findings as if you were the auditor. Prepare a mock audit report with findings and ensure you have answers or fixes for each finding. That way, when/if Oracle initiates an official review, you’re ready to present your licensing position confidently and with evidence.

You create a solid defense file by thoroughly documenting the LMS findings and your entitlement mappings. In the case of an Oracle audit, you can provide the raw data (since you must), but you will already know what it contains.

You can proactively address questions like “Why is Partitioning used on this server with no licenses?” with a prepared explanation or proof that it was an error and has been resolved. This level of preparation can significantly reduce the stress of an audit and may prevent financial surprises.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit