Usage Comparison: Identify Gaps Between Licenses Owned and Actual Usage
With a comprehensive inventory of Oracle deployments and a clear record of license entitlements in hand, the next step for IT managers is to perform a Usage Comparison.
This step is essentially a license compliance audit that you conduct on yourself: comparing what you have deployed (usage) against what you have bought (licenses owned).
Read Oracle License Compliance Checklist for IT Managers.
The goal is to identify any discrepancies, whether they are due to overuse (compliance risks) or underuse (potential cost savings).
This article, written from the lens of an Oracle licensing expert, walks you through identifying gaps between licenses owned and actual usage.
By systematically analyzing these gaps, you can address issues proactively, long before Oracle’s auditors come knocking.
Building the Compliance Ledger: Marrying Inventory and Entitlements
Start by aligning each Oracle product in your inventory with a corresponding license entitlement:
- Map Each Installation to a License: For every Oracle item in your inventory, determine which entitlement (from your contracts) covers it. This could be straightforward (e.g., an Oracle Database Enterprise Edition instance mapped to Oracle Database EE processor licenses) or require more detail (e.g., a WebLogic instance – is it covered under a WebLogic Suite license or a specific WebLogic Server license?). Create a list or table of deployments vs. licenses.
- Include Version/Edition Matching: Ensure that if your entitlement is for Standard Edition but inventory shows Enterprise Edition deployed, that’s an immediate gap. Licenses aren’t interchangeable between editions. The same goes for options and packs: inventory might show usage of an option, like Advanced Compression; check if you have a license for it.
- Quantify the Usage: For each deployment, quantify how much it “consumes” in license terms:
- If using Processor licensing: calculate the number of processor licenses required (e.g., a database on a server with eight cores, assuming Oracle’s core factor of 0.5 for that processor type, requires four processor licenses if Enterprise Edition).
- If using Named User Plus (NUP): determine how many distinct users (including non-human operated accounts) are accessing the Oracle software. This might require collating user lists from databases or apps.
- If using application user or module metrics (common in E-Business Suite or other Oracle apps): get the count of actual users or records that metric is based on.
- If you are using Oracle Cloud credits or BYOL in the cloud, check how many OCPUs or other units are in use compared to what is allowed.
- Compared to Entitlement: Now, for each item, compare the required licenses (from usage) to available licenses (from entitlements).
Example of a simple comparison table entry:
- Deployment:
Database1 on ServerA– Usage: 4 Processor licenses required (8 cores * 0.5) – Entitlement: 2 Processor licenses owned – Gap: Shortfall of 2 Processor licenses. - Deployment:
Database2 on ServerB– Usage: 50 Named Users – Entitlement: 100 Named User Plus licenses owned – Gap: Surplus of 50 (over-licensed, possibly a chance to reduce cost). - Deployment:
WebLogic Cluster X– Usage: running on 4 CPUs – Entitlement: 4 WebLogic Standard Edition CPU licenses – Gap: None (compliant). - Deployment:
Oracle Diagnostics Pack on DB Y– Usage: Enabled 1 pack – Entitlement: 0 packs licensed – Gap: Unlicensed use of Diagnostics Pack.
This ledger of gaps becomes the focus of your compliance analysis and subsequent remediation.
Identifying Compliance Gaps (Under-Licensing)
Focus first on gaps where your usage exceeds your entitlements, as these represent compliance issues:
- Unlicensed Products: The most glaring gap is finding any Oracle product installed for which you have no licenses. Perhaps a team installed Oracle Business Intelligence, but no one procured it. These are high-priority red flags.
- Excess Processor or Core Usage: If any installation is running on more cores or sockets than you have licenses for, quantify the exact overage. For example, using 10 cores but having only eight licenses means two cores are unlicensed. Keep Oracle’s licensing rules in mind – if those two cores are on a separate server, you can’t just average it out; each deployment must be licensed individually unless you have some unlimited agreement.
- Named User Plus Overuse: Check each environment where NUP licenses apply. Oracle’s counting can be tricky – if users access multiple databases, depending on your contract, you might need to license them for each DB unless you have a network license agreement. If Database A and Database B are both Enterprise Editions licensed by NUP, Oracle typically counts users separately for each database (unless those databases are part of the same “instance” and support the same application). Ensure you’re not undercounting unique users.
- Optional Packs and Features: Oracle database options, such as Partitioning and Advanced Security, and management packs, including Diagnostic Pack and Tuning Pack, must be licensed separately if used. Check your inventory (or better, run Oracle’s DBA_FEATURE_USAGE_STATISTICS view or LMS scripts) to see if these options are being used on any database. If yes, confirm you have the license. Unlicensed use of options is a common compliance gap, often unintentional.
- Virtualization Gaps: Virtualization is a notorious area:
- If running on VMware (or a similar “soft partitioning” system), Oracle may require all physical hosts in the cluster to be licensed, not just the host of the VM. Check if your entitlements cover that entire cluster. Many companies find a huge gap here because they licensed only a slice of a VMware cluster.
- If using Oracle’s hard partitioning (such as Oracle VM with pinned CPUs or Solaris Zones configured properly), ensure you have records of that configuration – Oracle accepts certain methods to limit licensing to a subset of hardware. If you claimed a partitioned licensing but haven’t strictly followed Oracle’s approved methods, that’s a gap.
- Indirect Usage: Perhaps your inventory shows only one Oracle database, fully licensed, but an in-house application indirectly uses another Oracle component, such as an Oracle Database embedded in a third-party software or using Oracle’s JDK in production. Indirect usage still needs licensing. If any such patterns exist, note them as gaps if not licensed.
- Geographical/User Segment Restrictions: Perhaps you have licenses for EMEA, but you find an installation being used in the US, which is technically not allowed under that license. That’s a compliance gap as well, albeit a contractual one rather than extra installations.
Prioritize these gaps by severity (based on the amount of unlicensed usage) and likelihood of Oracle detection (e.g., options usage and virtualization gaps are low-hanging fruit for auditors).
Read about Entitlement Review: Gather and Understand Your Oracle License Contracts.
Identifying Over-Licensing (Surplus or Inefficiencies)
It’s also beneficial to note where you have more licenses than needed:
- Unutilized Licenses: Instances where you deployed less than what you bought. For example, you have 100 NUP licenses for a development environment but only 20 active users. That’s 80 potential licenses unused. While compliance-wise you’re fine, this might indicate an opportunity to reallocate or reduce maintenance costs.
- Shelfware: Products you own but can not find in inventory. This could be an old Oracle product that’s not used anymore but sis till on support. It might be wise to consider terminating support for it or planning a future use or a license swap if Oracle allows.
- Expensive Editions Not Justified: Inventory may show Standard Edition usage when you have Enterprise licenses, or vice versa. If you’re always deploying Standard Edition features but bought Enterprise licenses, you might be overspending.
- Cloud vs On-Prem: Suppose you moved some workloads to Oracle Cloud and they are covered under cloud subscription, but you still have on-prem licenses idle as a result. Those on-prem could potentially be terminated or repurposed elsewhere.
While over-licensing doesn’t pose a compliance risk, it’s relevant to an IT manager’s objectives because it could free up budget (why pay support on licenses you don’t use?).
It might also become part of your remediation plan, for example, using surplus licenses to cover an underlicensed area, if allowed by contract.
Read Remediation Plan: Steps to Address Oracle License Compliance Issues.
Validate the Findings
Before rushing to fix things, validate the gaps you identified:
- Double-check Calculations: Ensure that core counts, user counts, and other details are accurate and that Oracle’s licensing rules are applied properly. For instance, if a server has hyper-threading enabled, it doesn’t change the core count for licensing purposes, but an inexperienced analyst might mistakenly double-count threads as cores.
- Peer Review: Have another team member or an external expert review the comparison. This can catch misunderstandings, such as a certain deployment being covered by a different license (maybe a ULA or a migration right that was overlooked).
- Update Documentation: Annotate your inventory and entitlement documents with notes about these gaps. This creates a paper trail of what’s non-compliant or over-licensed.
Example Scenario (Under-Licensing): A healthcare company’s usage comparison revealed they were running Oracle Database Enterprise Edition on a 4-node test cluster with Oracle Real Application Clusters (RAC) enabled.
They had licenses for EE, but not enough to cover all four nodes with RAC. RAC is a separately licensable option, and they only owned a 2-node license. This gap meant two nodes of RAC were unlicensed. It was a classic case of a DBA enabling RAC on all nodes for convenience, not realizing the license limit.
Because they caught it internally, they could disable RAC on the extra nodes (falling back to 2 nodes as licensed) before any audit. Alternatively, they could decide to purchase additional RAC licenses if that test usage was truly necessary.
Example Scenario (Over-Licensing): In the same company, they discovered they had 50 spare Processor licenses for Oracle WebLogic that were purchased for a project that was canceled.
These licenses were sitting on support, costing maintenance dollars annually. Recognizing this “shelfware” in the usage comparison, they flagged it for possible termination or reuse in the future, saving costs.
Documenting the Gap Analysis
Prepare a summary report or table of all findings. This is useful for communicating to management and forms the basis of a remediation plan:
- List each gap, the type (shortfall or surplus), magnitude, and potential risk/cost. For instance: “Unlicensed usage of Diagnostics Pack on three databases – high risk, potential $300k liability if audited.”
- Sometimes it’s helpful to categorize gaps by cause: configuration issue (like a feature toggled on accidentally), growth issue (more users than expected), process issue (unapproved installation), etc. This helps address root causes.
- Also note any quick wins: e.g., “Surplus licenses of product X can be applied to a shortfall in product Y if allowed by Oracle” (often not directly allowed, but worth exploring via contract negotiations).
Leveraging Gap Analysis for Remediation Strategy
Now that gaps are identified:
- Plan Priorities: Which gaps need immediate action (usually under-licensing in production environments)? Which can wait or just be monitored (maybe slight overuse in a test environment that you plan to decommission next month anyway)?
- Consider Interim Measures: If an Oracle audit letter came tomorrow, what could you do quickly to mitigate each gap? For instance, disabling a feature is faster than negotiating a purchase. You can temporarily ensure compliance with a quick configuration change while planning a longer-term solution, such as procurement.
- Engage Stakeholders: Present the findings to key stakeholders, including IT directors, application owners, and finance. They need to be aware of the exposure and will likely have input on remediation. For example, the application owner might say that those extra 20 users can be removed because they were old accounts, solving a NUP overage at no cost.
This usage comparison is not a one-time task either. It should be redone periodically, especially if significant changes occur, such as new projects or expansions.
Many organizations do this on a yearly or even quarterly basis as part of their internal compliance audits.
Recommendations
- Be Meticulous in Comparison: Small details, like one option pack on one database, can add up to huge license fees. Don’t ignore minor discrepancies.
- Use Tools for Data Gathering: If possible, use Oracle’s LMS reports or third-party tools to generate usage data. They can often produce a detailed breakdown of license requirements that you can then match to entitlements, minimizing human error.
- Maintain a Living Compliance Document: Record the results of each comparison. Over time, you can track if gaps are widening or shrinking, which indicates how well you’re controlling the environment.
- Treat Surplus as Opportunity: Whenever you find you’re over-licensed, mark it as a cost optimization opportunity. Perhaps during your next negotiation with Oracle, you can trade those in for credit on something else your organization needs.
- Watch for Emerging Gaps: New projects or tech (like suddenly deploying Oracle on Docker) can create new types of gaps. Keep an eye on tech trends in your company.
- Stay Educated: Oracle’s product features and licensing rules are constantly evolving. For example, if Oracle were to change how Java or cloud is licensed, your comparison method might need adjusting. Follow updates from Oracle or experts.
Performing a thorough usage comparison arms you with a clear understanding of your compliance posture. It’s like a diagnostic report on your Oracle licensing health. With that diagnosis, you can now move to the next phase: crafting a remediation plan to address any issues found.
