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 (e.g., Oracle Database 19c Enterprise Edition or Standard Edition). It may also include details like the Oracle home location and 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. will appear here if 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, OS, CPU model, cores, and whether it’s running in a virtualized environment​.
  • Database user counts: The script may query DBA_USERS or similar to count Named Users. It might list total user 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​docs.microfocus.com). 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 what features can be used and the base license type required.

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 use additional options/packs (which require separate licenses). If the output indicates an instance is Standard Edition, you should not expect any Enterprise-only options to be in use (and if they are, that’s a compliance issue). If it’s Enterprise Edition, you must check for optional features usage in subsequent steps.
  • Standard Edition naming: Depending on the version, you may see Standard Edition (SE), Standard Edition One (SE1), or Standard Edition 2 (SE2) in the output. SE1 was used in older versions (10g/11g), and SE2 started with 12c. For licensing analysis, all are considered Standard Edition family (licensed per socket, with feature limitations).
  • Enterprise Edition: Usually labeled “Enterprise Edition” in the output. Only EE supports the add-on options/packs like Partitioning, Advanced Security, etc.
• 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) since some features became 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 might mention if multitenant is in use (which is an EE option). Also, Standard Edition licensing rules changed in 12c (SE2 replaced SE/SE1, with core/socket limits), which might be relevant if 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 like “Installed/Used/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 (though basic Data Guard itself is part of EE, 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 never used, you do not 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 good practice (to prevent accidental use).
  • Counts and Dates: Consider any usage counts or dates in the report. They indicate how frequently and how recently the feature was used. For instance, “Advanced Compression – Used 3 times, Last Used: 2025-02-10” tells you the feature was actively used and when last seen. 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 it is to be used on 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 uses 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 (though 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; however, 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 call out “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 (one that 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’s within allowed limits.)
• Watch for False Positives: Sometimes, the feature usage tracking can show an option that is used even if you think you never used it. Known examples:
  • Partitioning: Installing Oracle’s sample schemas (like 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 sample schemas (HR, SH, etc.) can trigger false usage. Nevertheless, you’d need to explain this in an audit and show 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) could show up incorrectly if you migrated 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 used even when not configured (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 will usually list 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/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 Diagnostics Pack usage. 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 EE and the Diagnostics Pack as a prerequisite. The Tuning Pack’s usage might be recorded if the automated SQL Tuning Advisor runs during maintenance windows, if someone manually invokes a tuning task, or if the Enterprise Manager’s tuning features are used. The LMS tool can pick this up via feature usage stats (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 calls it a “feature”). If used (policies exist), 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 show up unless EM was used to mask data, but if present, it requires a license.
  • Cloud Management Packs, etc. – Less common are packs for specific purposes (like 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 license perspective, if LMS shows Diagnostics Pack used, Oracle will assert 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 could be triggered by the automatic SQL tuning advisor (which runs by default weekly) or manual use of tuning tools. If flagged, assume the Tuning Pack license is required (and note that you must have Diagnostics Pack licensed as well to use Tuning Pack).
  • Both Packs Used: It’s common to see both Diagnostic and tuning used together (since tuning features often leverage diagnostic data). Each requires its license.
  • Other Packs—Used: For example, Database Vault used means DB Vault was active (license 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 a bug or mistake if you claim it’s false.
  • If you know your team never used a certain pack, yet it’s marked used, investigate the specific features: for instance, check if AWR (Diagnostic) was running by default or if any SQL tuning set exists. Sometimes, DBAs are unaware of 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 on (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 could disable them going forward (stop AWR tasks via parameter and disable auto tuning tasks) – but the 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, packs), the next step is determining 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 (core factor 0.5 each), 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 if VMs can move across hosts (Oracle doesn’t 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 Standard Edition (SE/SE2), licensing is per processor socket (not per core). 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 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 exist. 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 2 sockets -> 2 SE2 licenses are required. ORCL1 has 150 users -> if using NUP, needs 150 NUP licenses (which also meets the minimum since 8 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 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 Partitioning by NUP for all those 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 8 licenses of the Oracle Partitioning option are required​,
   • Advanced Compression used on that instance -> 8 licenses of 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/instance level: e.g., RAC used on a 2-node cluster with EE—you need to license the RAC option for all processors on both nodes (i.e., match the EE licenses for those servers). Multitenant used (more than one PDB) on an EE database—license it for that whole instance (all procs).
   • Summarize per instance: For each instance, list the option licenses needed. For example:
     ORCL1: Enterprise Edition (8 processors) plus Partitioning (8 proc), Advanced Compression (8 proc).
     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’d need to have Diagnostics Pack NUP licenses for all those users (Oracle sells pack licenses per processor or NUP as well, usually aligning with how you license the DB).
   • Tuning Pack: It requires licenses (same quantity as Diagnostics since it covers the same server/users). Remember, Oracle doesn’t allow licensing Tuning Pack without Diagnostics Pack – so you can’t have tuning alone. Diagnostics is assumed to be used/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 (and if LMS is run on SE, it normally wouldn’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) was used, note that Active Data Guard 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 beyond EE; it’s 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 any uncertainty, refer to Oracle’s official Database Licensing Guide for your version, which has tables of which features 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/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, license per core covers any number of instances on that core. So count unique physical processors, but ensure 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 where usage requires a license and you have none (or not enough) is a compliance gap 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 Environment: If you have multiple servers, roll up the total licenses required vs owned. Oracle will look at compliance at the company level (though, usually, each instance must be licensed). 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 timeline. 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 everyone agrees on what was found and how it’s 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 subsequent logs (like if you ran 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 audit defense preparation. 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​redresscompliance.com. In fact, Oracle’s advice (and that of license consultants) is to always analyze LMS script output internally before handing it to Oracle​redresscompliance.com. 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 vs. licensable (for example, Oracle 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 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 *

Email *

Company

Message *

Submit