What Oracle's Data Collection Tool Actually Does

Oracle's LMS (License Management Services) collection tool, now referred to as GLAS (Global License Audit Services) in audit contexts, is a systematic data gathering mechanism designed to assess your organization's Oracle licensing compliance position. When you run the collection tool, it executes a series of SQL queries against your Oracle Database data dictionary to extract critical information about your database configuration, installed features, processor details, and historical feature usage patterns. The tool operates at the data dictionary level, accessing system tables that contain comprehensive information about your deployment.

The fundamental purpose of data collection is straightforward: Oracle wants to understand exactly what you have deployed, what features you are using, and how many processors you are running those features on. This information directly drives licensing requirements and creates the foundation for Oracle's audit calculations. The collection tool is not an auditing tool in itself—it is an information-gathering mechanism. Downloading the tool from My Oracle Support does not trigger an audit. However, submitting the raw results without careful review can create significant compliance exposure if your deployment reveals unlicensed features, improper virtualisation configurations, or historical feature activations that persist in the data dictionary despite no longer being actively used.

The Scripts Oracle Uses

Oracle provides multiple scripts tailored to different technology stacks within your environment. The primary database collection script targets Oracle Database instances and extracts configuration data, option information, and feature usage metrics. Separate scripts exist for Middleware components, Java deployments, and Oracle Cloud Infrastructure environments. Each script is designed to run against specific software components and returns a standardized output format.

The database collection script contains over 100 individual SQL queries that execute against the Oracle data dictionary. These queries look for enabled Database Options such as Advanced Compression, Advanced Security, Real Application Clusters (RAC), Partitioning, Diagnostic Pack, and Tuning Pack. The script also queries DBA_FEATURE_USAGE_STATISTICS, a critical Oracle data dictionary table that tracks every feature accessed in your database, including the timestamp of first and last use. This historical tracking is what makes feature usage data so dangerous—even features activated accidentally during testing, demonstrations, or experimental configurations will appear in this table with timestamps extending back up to 10 years.

The middleware scripts collect information about Oracle Application Server, Oracle WebLogic Server, Oracle SOA Suite, and other application components. The Java collection script identifies Java-based deployments and their configurations. Each script generates standardized output that Oracle can feed into their licensing calculation engine.

What Data is Collected

Oracle's collection scripts extract four primary categories of data: database edition and licensing information, processor and hardware details, enabled Database Options, and feature usage history. The database edition is straightforward—the script determines whether you are running Standard Edition, Enterprise Edition, or other Oracle Database variants. This determines your base licensing costs and which options are even available to you.

Processor information is exceptionally critical because Oracle Database licensing is predominantly processor-based. The collection script queries your system to determine how many CPU cores are available to your database, the processor type and model, and whether you are running on-premises, virtualised, or in cloud environments. For virtualised environments, this is where Oracle's notorious "soft partitioning" problem emerges. If your database runs on a VMware cluster without hard partitioning controls, Oracle may claim you need to license all processor cores on all physical hosts in the cluster, not just the cores allocated to your virtual machines.

The feature usage data extracted by DBA_FEATURE_USAGE_STATISTICS is perhaps the most consequential output. This table contains a complete audit trail of every licensed feature that has been accessed in your database, including Advanced Compression, Advanced Security, RAC, Partitioning, Diagnostic Pack, Tuning Pack, and dozens of others. Each entry includes the timestamp when the feature was first used and when it was last used. Oracle uses this data to build compliance claims: if a feature appears in the table with a recent last-use timestamp, Oracle will assume that feature is actively licensed and may claim significant per-processor licensing costs for it.

Downloading and Running the LMS Collection Tool

The LMS collection tool is available through Oracle's My Oracle Support (MOS) portal. Accessing the tool requires valid MOS credentials tied to your Oracle support contract. The critical point here is that downloading the tool from MOS does not trigger an audit or initiate any kind of Oracle investigation. Downloading is a completely passive action—Oracle's systems do not flag your account or notify your account team that you have obtained the collection tool. Many organizations hesitate to download the tool because they fear it will signal to Oracle that they are ripe for an audit, but this is a misconception. The download itself is a standard technical action with no audit implications.

The collection tool is typically delivered as a ZIP archive containing SQL scripts, supporting files, and documentation. For Oracle Database, the primary script is usually named something like aru11213.sql or similar, with the naming convention varying by tool version. The script requires DBA privileges to execute because it must access system tables and run queries against the data dictionary.

Where to Get It

Navigate to My Oracle Support at support.oracle.com using your MOS credentials. Search for "License Management Services" or "GLAS" to locate the current collection tool. Oracle frequently updates these tools as new features and options are introduced, so you should always download the latest version. The search will return several results; look for the official Oracle tool marked as the current production version. Download the archive to a secure location accessible to your database administration team.

Before running the scripts, review the README documentation included in the archive. Oracle provides detailed instructions on prerequisites, security considerations, and expected output formats. Understanding the documentation first prevents misconfigurations and ensures you capture all necessary data.

Running Scripts Safely

Running collection scripts safely requires careful execution and output validation. Always run the collection tool against a copy of your production database or in a non-production environment that mirrors your production configuration, rather than directly against production systems during business hours. Connect as a user with DBA privileges. Execute the script and allow it to complete without interruption—the tool typically takes 15-45 minutes depending on database size and system load.

Capture all output to a file so you can review the results before sharing them with anyone, including Oracle. The script output will include system configuration data, option availability, processor information, and feature usage statistics. Examine every section of the output before deciding whether to submit it to Oracle or use it for internal compliance assessment.

Critical safety practice: never email raw collection tool output or share it through unsecured channels. The data contains sensitive system configuration information that could expose security details. If you must share results with Oracle as part of an audit response, do so through secure channels or in-person meetings.

Understanding the Key Script Outputs

Oracle's collection scripts produce structured output that can be overwhelming at first glance. The output typically spans multiple pages and includes both human-readable sections and raw data. Understanding what each section means is essential for interpreting your compliance position.

Database Edition and Options

The first critical output section identifies your database edition and lists all installed Database Options. This section shows whether you are running Standard Edition or Enterprise Edition, which determines your licensing baseline. The Enterprise Edition license is mandatory before you can use premium features like Advanced Compression or Advanced Security. If you are running Enterprise Edition, the tool lists which optional database features are actually installed and available in your database.

The presence of a feature in this section does not necessarily mean you are licensed for it—it means the software is installed and available. Oracle will then cross-reference this against your license agreements and feature usage data to determine whether you owe licensing costs. A feature listed here with recent usage in the DBA_FEATURE_USAGE_STATISTICS table creates licensing exposure. A feature listed as installed but with no usage history may still create exposure if Oracle believes you should have licensed it when you enabled it.

Feature Usage Statistics

The DBA_FEATURE_USAGE_STATISTICS output is the most critical section because it shows Oracle which features have actually been used in your database and when. Each feature entry includes the feature name, the database component it belongs to, whether it is considered "detected" or "currently used," first use date, and last use date. Oracle uses this information to construct licensing claims.

Features with recent last-use dates create the most exposure. If your feature usage shows that Advanced Compression was last used within the past 30 days, Oracle will assume it is currently licensed and may claim per-processor licensing for all processors serving that database. Features with old last-use dates (from years ago) create different but still significant exposure—Oracle may argue that you should have licensed the feature when you first enabled it, creating retroactive licensing claims that can span multiple years.

Critically, features that were enabled accidentally during testing, demonstrations, or misconfiguration persist in the feature usage table indefinitely. There is no way to "clear" feature usage data from this table without manual manipulation (which Oracle would consider audit evidence tampering). Even features that were enabled years ago, used once, and never accessed again will continue to appear in this table with their original timestamp.

The DBA_FEATURE_USAGE_STATISTICS Trap

The DBA_FEATURE_USAGE_STATISTICS table represents one of the most dangerous aspects of Oracle licensing compliance. This table is designed to track Oracle's usage-based licensing model, but it has become a licensing liability trap because Oracle uses historical data to construct aggressive compliance claims. Understanding this trap is essential for managing your audit risk.

Why Historical Data Is So Dangerous

Oracle maintains feature usage statistics continuously from database creation. This means your database is potentially recording feature usage data going back 10 years or more, depending on your database's age. Every time any user or process triggers code that accesses a licensed feature, that feature gets recorded in DBA_FEATURE_USAGE_STATISTICS with a first-use and last-use timestamp.

The danger emerges because Oracle interprets this historical data very aggressively. If a feature appears in the table, Oracle assumes you should have licensed it during the entire period shown in the data. If Advanced Compression appears with a first-use date from 2016 and you only purchased the license in 2023, Oracle may claim that you owe licensing costs for seven years of unlicensed usage. This creates retroactive licensing liability that can extend back a decade.

Even more problematic is that features can be triggered accidentally. A developer testing compression features, a consultant demonstrating database options, or a system misconfiguration might activate a feature. That single activation creates a feature usage record that persists forever. Oracle will then cite that record as evidence that the feature was "used" and therefore should have been licensed.

Common Features That Create Audit Exposure

Certain features are particularly common culprits in Oracle audit disputes. Advanced Compression is frequently enabled accidentally when DBAs enable compression on specific tables or tablespaces, triggering the feature usage flag even though compression might not be the intended or budgeted feature. Advanced Security, which covers Transparent Data Encryption (TDE) and other encryption capabilities, is often activated during security implementations without explicit feature licensing.

Real Application Clusters (RAC) creates exposure in environments where HA/DR clustering solutions are deployed. Simply having RAC software installed or having attempted RAC configurations can trigger the feature usage flag. Partitioning, another expensive feature, appears in many databases where table partitioning has been tested or implemented. Diagnostic Pack and Tuning Pack, which unlock performance monitoring and diagnostic capabilities, are frequently triggered by monitoring solutions or automated performance analysis tools.

The trap is complete because you cannot simply disable these features to eliminate the usage record. Once triggered, the feature appears in the table permanently. Your only defense is to demonstrate that the feature was either properly licensed during the entire period of usage, or to argue that the usage was incidental, accidental, or covered under different licensing provisions.

Virtualisation and the Processor Licensing Challenge

Virtualisation fundamentally changes Oracle Database licensing calculus. Oracle's processor licensing model assumes a 1:1 relationship between purchased processor licenses and available processor cores. Virtualisation breaks this assumption, creating what Oracle calls "soft partitioning" scenarios that significantly increase licensing exposure.

The VMware Soft Partitioning Problem

If your Oracle Database runs on VMware virtual machines within a cluster without hard partitioning controls, Oracle will potentially count all processor cores on all physical hosts in the cluster as available to your database. This is not stated explicitly in your license agreement, but it emerges from Oracle's audit methodology and aggressive licensing interpretations. If you have a six-host cluster with 32 cores per host (192 cores total), and your Oracle Database VM is allocated just 8 virtual CPUs, Oracle may claim you need to license 192 processor cores, not 8.

The core issue is that VMware resource allocation is soft—virtual CPUs can be reallocated, burst above limits, or access host resources dynamically depending on workload. Oracle does not accept soft limits as evidence that a database's processor availability is capped at the number of allocated vCPUs. Without contractual hard partitioning, Oracle considers the entire cluster as potentially available processor resources.

This problem extends to any virtualised environment without explicit hard partitioning. AWS EC2 instances, Azure VMs, and Google Cloud Compute Engines all suffer from similar soft partitioning exposure. If you are running Oracle Database on a virtual machine without explicit hard partitioning guarantees and contractual commitments from your cloud provider, you may face licensing claims for far more processor cores than you actually use.

Hard Partitioning Solutions

Oracle recognizes certain hard partitioning technologies as valid solutions to the soft partitioning problem. On physical servers, using NUMA memory node binding, explicit BIOS core allocation, or similar mechanisms can create hard partitioning that Oracle accepts. On virtualisation platforms, Oracle has certified specific approaches: VMware vSphere with explicit resource pool reservation and DRS rules, Hyper-V with NUMA-aware partitioning, and certain Oracle Cloud Infrastructure configurations.

The key requirement is that hard partitioning must be irreversible without administrative intervention, must be documented contractually, and must be validated through collection tool output. Simply setting a vCPU limit in VMware is not sufficient. You need formal documentation showing that the database is physically isolated from other workloads and that processors are reserved exclusively for your database.

For cloud environments, investigate whether your provider offers hard partitioning options. AWS has EC2 Dedicated Hosts, Azure has Dedicated Hosts, and GCP has similar offerings. These services provide physical processor isolation that Oracle recognizes. However, they typically cost significantly more than standard instances. The financial trade-off between hard partitioning and potential audit exposure requires careful analysis.

Oracle's Core Factor Table

Oracle's licensing model is not simply per-core. Different processor types have different "core factors" that multiply the base licensing cost. Understanding the core factor table is essential for calculating potential licensing exposure and understanding Oracle's compliance claims.

Why CPU Type Determines License Cost

Oracle's licensing philosophy assumes different processor types have different computational capacities. A modern Intel Xeon processor offers different performance characteristics than a legacy processor from 10 years ago. Oracle uses core factors to normalize licensing across different processor types. Intel Xeon processors, which power most enterprise deployments, have a core factor of 0.5. This means you need only half as many processor licenses as you have physical cores on Intel Xeon systems—one processor license covers two cores.

Oracle SPARC processors and Oracle processors have different core factors depending on the specific model. UltraSPARC processors have varying factors. AMD processors have different factors than Intel. Even within the Intel line, different generations have different factors. This complexity matters because Oracle will look at your processor type and apply the corresponding core factor to calculate your licensing obligation.

A practical example illustrates the impact: a system with 16 Intel Xeon cores requires 8 processor licenses (16 cores × 0.5 factor). The same system with a different processor type might require 16, 12, or some other number of licenses depending on that processor's core factor. Oracle determines the processor type from your collection tool output, applies the appropriate core factor, and multiplies by the number of processors running Oracle features to calculate your licensing cost.

Common Core Factor Calculations

Most enterprise systems run on Intel Xeon processors, making the 0.5 core factor the most common scenario. With this factor, your licensing requirement is straightforward: divide your physical core count by 2. A 32-core system requires 16 processor licenses for Enterprise Edition (and appropriately scaled licensing for specific options).

Oracle SPARC systems, still common in certain enterprises particularly those with long-standing Sun/Oracle relationships, typically have core factors between 0.5 and 1.0 depending on the specific processor generation. Newer SPARC processors have lower factors; older processors have higher factors. If you are running on SPARC, verify the exact processor model and look up the corresponding core factor on Oracle's official table before calculating licensing exposure.

When you run the collection tool, it will report your processor type. Cross-reference this against Oracle's current core factor table to understand the multiplier that will be applied to your licensing calculation. This is essential context for audits or licensing reviews. If your collection tool shows an Intel Xeon processor but Oracle's audit team claims a different processor type, you will have data to dispute their claim.

Middleware and Applications Data Collection

Oracle's licensing model extends beyond Database to include Middleware, Applications, and specialized platforms. If your organization uses Oracle WebLogic Server, Oracle SOA Suite, Oracle Service Bus, or other Oracle middleware products, separate licensing obligations apply. The collection tool includes scripts for these components, and understanding what data they collect helps you identify additional licensing exposure.

Oracle middleware products are licensed per-processor, similar to Database, but with different cost structures. WebLogic Server licensing, for instance, is based on the number of processor cores available to the server, not on actual utilization. If you run WebLogic on your virtualised infrastructure, you face the same soft partitioning challenges as with Database. Oracle Applications, including Oracle EBS (E-Business Suite), use different licensing models—some are per-processor, some are per-user, some are module-specific. The middleware collection tool attempts to identify which applications you are running and report data relevant to their licensing.

The middleware scripts examine installed application components, configured servers and instances, feature flags in your application configuration, and historical usage patterns. For many organizations, middleware licensing represents a secondary compliance exposure that emerges only during comprehensive collection tool analysis. If you have deployed middleware products without explicit licensing planning, the collection tool output may reveal significant undiscovered licensing costs.

How Oracle Uses Collection Data in Audits

Understanding how Oracle processes collection data in the audit context is essential for developing audit defense strategy. The collection tool is designed to feed data directly into Oracle's licensing compliance calculation engine. When you submit collection results to Oracle (either voluntarily or under audit), Oracle's systems use that data to generate licensing compliance reports showing your current licensing position and any identified discrepancies.

The GLAS Audit Process

When Oracle initiates a formal audit (GLAS), Oracle's audit team uses collection data to build a preliminary compliance assessment. The audit team runs collection scripts in your environment or requests that you run scripts and submit results. Oracle then feeds this data into their calculation systems, which apply core factors, identify enabled features, cross-reference against your license agreements, and generate a detailed compliance report showing licensing gaps.

The audit process typically unfolds over 45 days from initial notice, though the timeline can be extended. During this period, Oracle requests that you provide collection results demonstrating your current configuration. The GLAS team analyzes the data, builds a compliance claim showing identified gaps, and presents findings to your organization. You then have opportunity to dispute findings, provide additional documentation, or negotiate settlements.

Oracle's audit process is confrontational by design. The GLAS audit team is incentivized to find licensing discrepancies—their performance is measured by identified compliance gaps. They will interpret collection data aggressively, apply the most expensive licensing models, and construct claims that maximize identified exposure. Having your own collection results analyzed before Oracle launches a formal audit allows you to identify discrepancies first and develop defense strategies.

Building Oracle's Compliance Claim

Oracle builds compliance claims through a systematic process: they extract processor count and type from collection results, apply the appropriate core factor to calculate licensing requirements, cross-reference enabled features against your agreements to identify unlicensed options, examine feature usage history to identify retroactive licensing exposure, and examine virtualisation configuration to maximize processor core counts under soft partitioning interpretations.

Each step creates opportunity for Oracle to increase their compliance claim. If they can reinterpret your processor count upward (through soft partitioning arguments), they increase licensing exposure proportionally. If they identify features with recent usage history, they claim those features require licensing. If they find features that were used years ago according to the feature usage table, they may claim retroactive licensing from first use date forward. The cumulative effect is usually a substantial compliance claim.

Understanding this methodology allows you to pre-audit your own systems, identify vulnerabilities, and develop responses before Oracle launches a formal audit.

Running a Self-Assessment Before Oracle Arrives

The strategic advantage of running collection tool analysis before Oracle arrives is enormous. A self-assessment allows you to identify compliance gaps on your own timeline, develop remediation strategies, and if necessary, negotiate with Oracle from a position of strength. Organizations that understand their compliance position before Oracle initiates an audit can often settle disputes far more favorably than organizations caught off-guard.

Reviewing Results Before Submission

When you run the collection tool independently, carefully review every section of the output before sharing it with anyone. The output will show your processor type and count—verify this matches your actual hardware configuration. It will show enabled Database Options—note which features are present and whether you are licensed for them. It will show feature usage history—examine which features have been used recently and which have old usage timestamps.

For each feature with usage history, determine why that feature appears. Was it intentionally enabled and licensed? Was it activated accidentally? Was it used for testing and never intended for production? Document your findings. If you discover unlicensed features with recent usage, you now have opportunity to either purchase licenses or disable the features before Oracle arrives.

Virtualisation configuration review is particularly critical. If your database runs on virtualised infrastructure, examine the collection tool output to see what processor counts are being reported. If the reported count is much higher than your allocated vCPUs, investigate whether soft partitioning is creating exposure. If so, work with your infrastructure team to implement hard partitioning or develop documentation explaining your current configuration.

Engaging Advisory Support

Many organizations benefit from engaging external advisory support to interpret collection tool results. Compliance advisors with Oracle audit experience can quickly identify red flags, assess the severity of compliance gaps, and recommend remediation priorities. An advisor can also help you understand Oracle's likely audit position and develop strategies to address identified issues before Oracle arrives.

Advisory engagement is particularly valuable if your collection results reveal complex scenarios: multiple databases across distributed infrastructure, sophisticated virtualisation configurations, middleware deployments with unclear licensing, or feature usage patterns that raise audit red flags. An experienced advisor provides both technical analysis and strategic guidance on prioritizing remediation efforts.

The cost of advisory engagement is typically far less than the cost of reactive responses to Oracle audits. Early intervention allows you to shape your compliance position rather than defend against Oracle's aggressively interpreted claims.

Priority Actions After Running the Collection Tool

Once you have reviewed collection tool output and understood your compliance position, execute these priority actions in sequence:

  1. Document Your Current Configuration. Create detailed documentation of your Oracle environment, including database versions, installed options, processor types, virtualisation platforms, and feature usage. This documentation serves as your foundation for audits and disputes with Oracle.
  2. Identify Unlicensed Features with Active Usage. Cross-reference your license agreements against the feature usage statistics. For any feature that appears with recent usage but is not licensed, plan to either purchase a license or disable the feature immediately. Features with old usage dates are lower priority; features with current usage are critical.
  3. Validate Processor Count and Core Factor. Verify that the processor count reported by the collection tool matches your actual hardware. Check that the reported processor type matches your actual processors. Use the correct core factor when calculating licensing requirements. Correct any discrepancies immediately.
  4. Assess Virtualisation Risk. If your databases run on virtualised infrastructure, assess whether soft partitioning creates exposure. If exposure exists, either implement hard partitioning solutions or budget for increased licensing costs if Oracle audits and requires licensing for additional processors.
  5. Inventory Database Options Licensing. For each Database Option identified in the collection output, verify that your organization holds appropriate licenses. If you are running an option without a license, determine whether remediation (purchasing a license or disabling the feature) is appropriate.
  6. Develop Remediation Timeline. If you have identified multiple compliance gaps, prioritize them based on audit risk and cost impact. Some gaps can be remediated quickly (disabling unnecessary features, updating license agreements); others require more substantial work (implementing hard partitioning, reorganizing infrastructure).
  7. Update Your License Inventory and Agreements. Ensure that your license tracking system accurately reflects your current agreement terms, features purchased, and processor counts covered. Discrepancies between what you believe you are licensed for and what your agreements actually cover create dispute risks.
  8. Implement Feature Usage Monitoring. After addressing identified feature usage issues, implement ongoing monitoring to ensure that expensive licensed features are only activated when intentionally used. Monitor DBA_FEATURE_USAGE_STATISTICS regularly to catch unintended feature activations quickly.
  9. Prepare Audit Documentation and Responses. Compile your collection results, supporting documentation, license agreements, and remediation steps into a organized audit response package. If Oracle initiates an audit, you will already have much of the supporting documentation ready.
  10. Schedule Periodic Re-Assessment. Technology environments change continuously. New databases are deployed, features are updated, virtualisation configurations change. Run collection tool analysis annually or whenever significant infrastructure changes occur, ensuring that you maintain current understanding of your compliance position.

Conclusion: Strategic Positioning for Oracle Licensing Compliance

Oracle's data collection tool provides invaluable insight into your actual licensing position if you use it strategically. The tool is not something to fear or avoid—it is a mechanism for understanding the gap between your current configuration and your license agreements. Understanding this gap before Oracle arrives allows you to shape your compliance position, remediate critical issues, and negotiate from a position of informed strength.

The core principles are straightforward: download the tool and review your results before sharing them with Oracle. Identify feature usage patterns, processor licensing requirements, virtualisation exposures, and unlicensed options. Prioritize remediation based on audit risk and cost impact. Use advisory support when complex scenarios require external expertise. And maintain ongoing assessment as your environment evolves. Organizations that follow this disciplined approach to self-assessment dramatically reduce their audit risk and often negotiate significantly more favorable audit settlements when Oracle eventually arrives.