Oracle Database Licensing Glossary: 60 Terms Defined for Enterprise Buyers

Oracle's primary licensing metric for Database Enterprise Edition in server deployments. One Processor license is required for each physical CPU socket running Oracle Database — but the effective count is calculated as: number of cores × Core Factor. A server with two Intel Xeon processors at 16 cores each requires 2 × 16 × 0.5 = 16 Processor licenses. Oracle does not count vCPUs for on-premise deployments; it counts physical cores multiplied by the Core Factor. In virtualised environments without Oracle-approved hard partitioning, Oracle counts every physical core in the entire cluster, not just the VMs running Oracle. List price: $47,500 per Processor for Database Enterprise Edition.

An alternative Oracle license metric based on the number of authorized users who can access the database, regardless of concurrency. One NUP license is required per person or device that directly or indirectly accesses the Oracle Database, including through application middleware that queries Oracle on their behalf. The minimum NUP count is 25 per Processor equivalent for Enterprise Edition. NUP is typically lower-cost than Processor in environments with fewer users relative to CPU count, but Oracle LMS specifically investigates NUP deployments to verify that indirect access (third-party apps, batch jobs, data feeds) has been included in the count. List price: $950 per NUP for Database Enterprise Edition.

Oracle's published table assigning multipliers (0.25 to 1.0) to specific processor architectures for Processor license calculations. Intel and AMD x86 processors qualify for 0.5 Core Factor — meaning you need half a Processor license per physical core. Oracle SPARC processors qualify for 0.25–1.0 depending on the specific chip. IBM POWER processors qualify for 0.75–1.0. The Core Factor Table applies only to the Processor metric, not Named User Plus. Oracle updates the Core Factor Table periodically; the applicable factor is the one in effect at the time of license purchase or, in audit contexts, the time of the alleged compliance violation. Applying the wrong Core Factor to a server migration or infrastructure refresh is one of the most common causes of significant compliance gaps in enterprise Oracle environments.

Oracle's licensing metric for Java SE subscriptions, based on the total number of employees of the licensee (and all subsidiaries and affiliates with majority ownership), regardless of whether those employees use Java. Introduced in 2023, the Employee Metric replaced the per-processor and per-user metrics for Java SE and dramatically increased licensing costs for most enterprises. A company with 10,000 employees must license all 10,000 employees even if only 200 developers use Java. Oracle defines "employee" broadly to include contractors with on-site or regular remote access. The Employee Metric does not apply to Oracle Database licensing — only to Java SE subscriptions.

A per-user license metric specific to certain Oracle Applications (EBS, PeopleSoft, JD Edwards, Siebel). Application User licenses are priced differently from Database NUP licenses and cannot be used interchangeably. The Application User metric typically includes access rights to the underlying Oracle Database instances that support the application — meaning enterprises do not need separate Database NUP licenses for users who access Oracle Database exclusively through a licensed Oracle Application. Oracle LMS specifically investigates whether any "back-end" access to the database occurs outside the application, as this can trigger separate Database licensing requirements.

Oracle imposes minimum quantities for Named User Plus licenses relative to the number of Processors deployed. For Oracle Database Enterprise Edition, the minimum is 25 NUPs per Processor. For Standard Edition 2, the minimum is 10 NUPs per socket (maximum 2 sockets). These minimums apply even if the actual user count is lower. Enterprises that switch from Processor licensing to NUP licensing to reduce costs must ensure the actual NUP count exceeds or meets the minimum, or they must license at the minimum — eliminating the cost benefit of the switch in some configurations.

Oracle's cloud-specific compute unit, equal to one physical CPU core with hyperthreading enabled — equivalent to 2 vCPUs in most cloud environments. OCPU is the unit of OCI compute billing and Oracle Database cloud service licensing. When using BYOL on OCI, each Processor license entitles the licensee to 2 OCPUs. The OCPU metric does not use the Core Factor Table; the 2:1 ratio (2 OCPUs per Processor license) is fixed regardless of processor architecture. Enterprises migrating from on-premise Processor licenses to OCI must recalculate their entitlement in OCPUs, which sometimes reveals fewer available BYOL credits than expected.

Oracle's definition of a licensable user under NUP metrics. Authorized Users include all individuals who are authorized to use the programs, whether or not they are actively using the programs at any given time. This includes employees, contractors, agents, and third parties who access Oracle Database directly or indirectly. The "whether or not actively using" clause means that dormant user accounts, service accounts, and batch processing accounts that technically have database access must be counted — even if no human uses them. Oracle LMS specifically counts all accounts with database login privileges during USMM script execution, not just active sessions.

Oracle's highest-tier database product, supporting unlimited sockets and cores, all Oracle Database Options, and all Oracle Management Packs. Enterprise Edition is the only edition that supports Data Guard, Advanced Security Option, Database Vault, Partitioning, In-Memory Option, Real Application Clusters, and other high-availability and performance features. All Oracle Options and Management Packs are add-on licenses; using them without separate license purchases is the most common source of Oracle audit compliance claims. List price: $47,500 per Processor.

Oracle's mid-tier database edition, limited to a maximum of 2 CPU sockets per server and 16 physical threads (hyperthreaded cores). SE2 does not support Real Application Clusters (RAC), Oracle Data Guard (active standby), or most Oracle Options. SE2 is licensed per socket, not per core — making it significantly cheaper than Enterprise Edition for CPU-heavy workloads on qualifying hardware. Critical compliance trap: the 2-socket maximum applies to the physical server, not the VM. SE2 deployed on a virtualised host that has more than 2 physical sockets violates Oracle's SE2 restrictions, regardless of how many sockets the VM is configured to see. List price: $17,500 per socket.

Separately licenced features that extend Oracle Database Enterprise Edition functionality. Options include: Real Application Clusters ($23,000/Processor), Partitioning ($11,500/Processor), Advanced Security Option ($15,000/Processor), Database Vault ($11,500/Processor), Label Security ($11,500/Processor), In-Memory ($23,000/Processor), GoldenGate ($17,500/Processor), Spatial and Graph ($17,500/Processor). Using a Database Option without a license triggers an audit back-license claim at full list price plus retroactive support from the date of first use. Options are enabled at the database parameter level and are frequently activated accidentally through Oracle tools, monitoring systems, or default configurations.

A separately licenced Oracle Management Pack (not an Option) that enables Oracle's Active Session History, Automatic Workload Repository (AWR), and related performance monitoring features in Oracle Enterprise Manager. Diagnostics Pack is enabled by the CONTROL_MANAGEMENT_PACK_ACCESS database parameter, which defaults to DIAGNOSTIC+TUNING in Oracle Database 11g and later versions. This default setting means that every Oracle Database EE installation activates Diagnostics Pack on installation — without any deliberate action by the DBA. Oracle LMS specifically checks this parameter during audits. List price: $5,000 per Processor. Found unlicensed in an estimated 40%+ of enterprise Oracle environments.

A separately licenced Oracle Management Pack that enables SQL Access Advisor, SQL Tuning Advisor, and Automatic SQL Tuning in Oracle Enterprise Manager and in Oracle's background processes. Like Diagnostics Pack, Tuning Pack is enabled by default via the CONTROL_MANAGEMENT_PACK_ACCESS parameter. DBAs who use "explain plan" features through Oracle Enterprise Manager, run SQL Tuning Advisor queries, or use the Automatic SQL Tuning feature trigger Tuning Pack usage automatically. List price: $5,000 per Processor. Always licenced together with Diagnostics Pack — cannot be licenced independently.

A separately licenced Oracle Database Option that enables table and index partitioning — the ability to divide large tables into physical segments for performance and manageability. Partitioning is one of the most commonly unlicensed Oracle Options in enterprise environments because DBAs use it for performance optimization without realizing it requires a separate license purchase. Oracle's USMM scripts detect partitioned objects in DBA_PART_TABLES and DBA_PART_INDEXES and report any partitioning usage as unlicensed. List price: $11,500 per Processor. Back-license claims for Partitioning frequently reach $1M+ in large Oracle environments.

Oracle's active-active clustering technology that allows multiple database instances to access a single database simultaneously across multiple nodes. RAC requires Oracle Database Enterprise Edition plus a separate RAC Option license ($23,000/Processor). In Oracle's licensing model, all nodes in a RAC cluster must be fully licenced — you cannot license a subset of RAC nodes. The cluster licensing requirement applies to every physical core across all RAC nodes after Core Factor adjustment. RAC is one of Oracle's highest-value upsell items and is heavily promoted in large enterprise environments, but the per-node license cost escalates rapidly in large clusters.

Oracle Data Guard is the license-free standby database feature included with Oracle Database Enterprise Edition — but the "free" element applies only when the standby database is in mount mode (not open for reads or reporting). Active Data Guard, which enables the standby database to serve read queries while in standby mode, requires a separate license ($11,500/Processor). Active Data Guard is frequently used without a separate license because DBAs enable read-only standby access for reporting without realizing the feature requires additional licensing. Oracle LMS specifically checks V$DATABASE.OPEN_MODE on standby instances to detect Active Data Guard usage.

A separately licenced Oracle Database Option covering Transparent Data Encryption (TDE), native database encryption, and network encryption. TDE, which encrypts data at rest at the tablespace or column level, is one of the most commonly deployed Oracle security features — and one of the most commonly unlicensed. Oracle's DBA_ENCRYPTED_COLUMNS and V$ENCRYPTED_TABLESPACES views are queried by LMS scripts to detect TDE usage. Organizations using TDE for regulatory compliance (PCI-DSS, HIPAA, GDPR) but without an ASO license face back-license claims that can exceed $20M in large Processor-licensed environments. List price: $15,000 per Processor.

Oracle Database Free is Oracle's zero-cost, feature-limited database edition, replacing Oracle Database Express Edition (XE). Database Free is limited to 2 CPUs, 2GB RAM, and 20GB of user data storage. Database Free may be used freely for development, production, and distribution — including in commercial applications — without license fees. However, Database Free cannot be used as a stepping stone to Enterprise Edition features, and any upgrade or migration from Database Free to Enterprise Edition requires full license purchase. Many Oracle licensing analyses miss Database Free deployments because ITAM tools inventory them as "Oracle Database" without edition qualification.

Oracle's self-managing database service available exclusively on Oracle Cloud Infrastructure (OCI). Autonomous Database is not a separately licenced on-premise product — it is an OCI-native cloud service priced per OCPU per hour. BYOL applies to Autonomous Database: each on-premise Processor license entitles the holder to 2 OCPUs of Autonomous Database compute time. Autonomous Database is available in Shared Infrastructure (ADB-S) and Dedicated Infrastructure (ADB-D, running on dedicated Exadata hardware) variants. The licensing economics of migrating on-premise Oracle Database to Autonomous Database depend entirely on your current license utilization rate and BYOL credit calculation — models that Oracle's cloud sales team consistently presents optimistically.

Oracle's real-time data replication and integration product, separately licenced from Oracle Database. GoldenGate enables heterogeneous database replication — including replication between Oracle and non-Oracle databases — and is commonly used for migrations, disaster recovery, and real-time data integration. GoldenGate is licenced per Processor on both the source and target databases, making the total license cost 2× the per-database rate for bidirectional configurations. Oracle's OGG (Oracle GoldenGate) cloud service provides GoldenGate capabilities on OCI with consumption-based pricing. List price: $17,500 per Processor.

Oracle's internal audit team, officially called Oracle License Management Services. LMS is Oracle's primary mechanism for enforcing license compliance — initiating audits, running measurement scripts, analyzing deployment data, and presenting compliance claims to customers. LMS operates as a revenue-generating function, and Oracle's sales teams use LMS audit findings as leverage to close cloud migration and additional license deals. The LMS team is distinct from Oracle's customer success and support organizations, and LMS representatives operate within Oracle's commercial framework — they are not objective auditors. All LMS communications should be reviewed with independent counsel before responding. Our Oracle Audit Defense service manages all LMS interactions on your behalf.

Oracle's rebranded audit and advisory organization, replacing the LMS branding in some regions and communications. GLAS performs the same function as LMS but is positioned as more consultative in initial customer communications. In practice, GLAS follows the same methodology and commercial objectives as LMS. The renaming from LMS to GLAS is a marketing decision, not an operational change. Enterprises should treat GLAS audit requests with the same caution as LMS audit requests. See our comparison: Oracle LMS vs GLAS.

Oracle's primary database measurement tool, deployed during LMS audits to collect license usage data directly from Oracle Database instances. USMM queries Oracle's data dictionary views (DBA_FEATURE_USAGE_STATISTICS, DBA_AUDIT_MGMT, V$PARAMETER, and others) to detect which Oracle features, Options, and Management Packs are in use. USMM does not require database admin access to run — it can be executed with SELECT_CATALOG_ROLE. USMM output becomes Oracle's primary evidence in compliance claims. Enterprises should run USMM proactively on their own environments before any LMS engagement to understand their exact exposure before Oracle does. Our Oracle Compliance Review includes USMM execution and interpretation as a standard component.

Oracle's collection of SQL scripts used by LMS to measure database usage during an audit. The primary scripts are the Collection Scripts (cpu.sql, options.sql, and others) and the consolidated Review Lite collection. LMS scripts collect information about processor counts, Oracle feature usage, installed options, and database configuration. Enterprise legal teams frequently advise restricting what LMS script output is shared with Oracle — because the scripts are designed to identify maximum license requirements, and not all captured data creates a license obligation. Review Lite was introduced in approximately 2017 to streamline the audit process; it collects more granular data than earlier scripts. Never provide LMS script output to Oracle without independent review.

Oracle's internal data dictionary view tracking which database features have been detected as in-use. This view is Oracle's primary source of Options and Pack compliance evidence. It tracks whether features like TDE (Advanced Security Option), partitioned objects (Partitioning Option), AWR reports (Diagnostics Pack), and hundreds of other features have been executed. Feature usage is captured automatically by Oracle's internal monitoring process and cannot be easily cleared or manipulated without disabling the feature entirely. Organizations conducting proactive compliance reviews should query this view and investigate every non-zero usage count against their license entitlement.

The contractual right Oracle retains to audit licensee compliance, specified in the Oracle Master Agreement. Oracle's standard audit rights clause grants Oracle or its designated third-party auditor the right to audit the licensee's Oracle software usage with reasonable notice (typically 45 days). The scope, methodology, and data sharing obligations during an audit are all negotiable at contract time — but almost never negotiated in practice. Key negotiation points include: the audit frequency (Oracle's standard terms allow unlimited audits), the methodology Oracle can use, the data sharing obligations, and what happens with audit data after completion. Our Oracle Audit Rights guide covers the contract-level defences available to enterprise buyers.

The formal written notification Oracle sends to initiate an LMS audit. The letter typically references the Oracle Master Agreement audit rights clause, requests specific cooperation with Oracle's audit process, and sets an initial timeline for data collection. Receiving an Oracle LMS audit letter does not obligate you to respond on Oracle's proposed schedule or provide data in Oracle's preferred format. The appropriate response is to acknowledge receipt, confirm you are reviewing the request with legal counsel, and engage an independent Oracle licensing advisor immediately. The first 48 hours after receiving an LMS audit letter are the most important for establishing your negotiating position. See our guide: How to Respond to an Oracle LMS Audit Letter.

A formal written statement provided by the licensee to Oracle certifying their current license usage and compliance position. Oracle sometimes requests compliance declarations outside of formal audit processes. A compliance declaration is a legally significant document and should never be provided without independent review. Incorrect or incomplete declarations can create additional legal exposure. In the context of Oracle ULA certifications, the compliance declaration (or "certification" document) formally records the ULA license counts at certification, establishing the permanent post-ULA license entitlement.

Oracle's demand for payment of retroactive license fees for unlicensed software usage detected during an audit. Oracle calculates back-license claims at current list price (without historical discounts) plus retroactive support fees from the alleged first date of non-compliant use. The average Oracle audit claim is 3–5× what the customer actually owes after independent analysis and challenge. Back-license claims are Oracle's opening negotiation position in an audit commercial settlement — not an enforceable invoice. Independent legal and licensing analysis consistently identifies significant elements of back-license claims that are technically or contractually challengeable.

The unique identifier assigned to each Oracle license or support agreement, used to access Oracle My Support (MOS) and link deployments to entitlements. CSI stands for Customer Support Identifier (legacy term); SLI is the current terminology in Oracle's support systems. The CSI/SLI is critical for BYOL in cloud environments — each BYOL deployment must reference a valid CSI with active support. Enterprises with poorly maintained CSI records frequently discover during audits that their BYOL credits are lower than expected because CSIs have lapsed, been retired, or are associated with incorrect Processor counts in Oracle's records.

A virtualisation or partitioning technology that Oracle formally accepts as limiting the number of processor cores available to Oracle software. Hard partitioning allows Oracle Database to be licenced only for the cores allocated to the Oracle partition, rather than all physical cores in the server or cluster. Oracle's approved hard partitioning technologies include: Oracle VM (OracleVM Server for x86), Oracle Solaris Zones, IBM LPAR, IBM Micro-Partitioning, HP Superdome (nPars/vPars), physical servers, and (on specific hardware) physical cores with software-enforced CPU binding. VMware vSphere is explicitly NOT an approved hard partitioning technology. AWS Dedicated Hosts without OracleVM and Azure Dedicated Hosts without OracleVM are also NOT approved hard partitioning.

Any virtualisation or partitioning technology that Oracle does not accept as limiting Oracle license requirements. When Oracle Database is deployed in a soft partition, Oracle claims the license requirement is calculated based on all physical cores in the entire physical server or cluster, not just the cores visible to or allocated to the virtual machine. VMware vSphere, Microsoft Hyper-V (standard configurations), KVM, Docker (without hard partition boundaries), Kubernetes, CPU pinning via vSphere, NUMA affinity, and Azure/AWS standard VMs are all soft partitioning technologies. Soft partitioning is the single largest source of Oracle audit claims in enterprise environments — with the typical claim calculating license requirements for an entire VMware cluster rather than just the VMs running Oracle.

Oracle's policy on VMware vSphere is that it constitutes soft partitioning — meaning Oracle claims license requirements for every physical core in the vSphere cluster, even if Oracle Database runs on only one VM in the cluster. This policy is Oracle's internal licensing position, not a VMware-confirmed technical determination. Oracle's policy document ("Oracle's Partitioning Policy") is the basis for this claim. The policy is contested — there are legal and technical arguments that Oracle's application of this policy is overbroad — but Oracle maintains it consistently during audits. Enterprises running Oracle Database on VMware without comprehensive hard partition documentation are at significant audit risk. See our detailed guide: Oracle Database Licensing on VMware.

Oracle's own virtualisation platform (OracleVM Server for x86), based on the Xen hypervisor. OracleVM is one of Oracle's formally approved hard partitioning technologies, allowing Oracle Database to be licenced only for the CPU resources allocated to the specific OracleVM virtual machine. Using OracleVM on VMware ESXi hosts (a common configuration) does not qualify as hard partitioning — Oracle's policy requires OracleVM to be deployed directly on physical hardware, not nested within another hypervisor. OracleVM is declining in enterprise adoption, being replaced by Oracle Linux KVM in Oracle's own recommendations.

Oracle Solaris Zones (Containers) are an Oracle-approved hard partitioning technology when deployed on Oracle SPARC hardware. Solaris Zones on x86 hardware are not universally accepted as hard partitioning by Oracle LMS — the approved configuration requires specific hardware and zone configuration documentation. Oracle Solaris Global Zones (the full server context) do not constitute partitioning. Non-Global Zones with dedicated CPUs (capped zones) are the approved configuration for hard partitioning on Oracle SPARC servers.

A VMware or Hyper-V configuration that binds a virtual machine's vCPUs to specific physical CPU cores, preventing the VM from using other cores. CPU pinning is a soft partitioning technique — Oracle explicitly rejects CPU pinning (including VMware CPU affinity) as hard partitioning for Oracle Database licensing purposes. Enterprises that have implemented CPU pinning to limit Oracle license requirements are still exposed to full physical cluster licensing under Oracle's audit methodology, unless OracleVM or another approved hard partitioning technology is also in use.

A physical server running Oracle Database with no other virtualised workloads or hypervisor layer constitutes the simplest hard partition — the physical server itself. Oracle Database on a dedicated physical server requires Processor licenses only for the physical cores in that server (multiplied by Core Factor), not for any other servers in a network or cluster. Physical isolation is increasingly rare in modern enterprise environments but remains the simplest Oracle-compliant deployment architecture for environments with high Oracle licensing costs relative to hardware costs.

When Oracle Database is deployed in a cluster (whether VMware cluster, RAC cluster, or any other shared-resource cluster configuration), Oracle's licensing policy may require licensing all physical cores in the entire cluster, not just the cores where Oracle Database is currently running. For VMware clusters, this means all cores in all ESXi hosts in the vSphere cluster must potentially be licenced. For RAC clusters, all cores in all RAC nodes must be licenced. Cluster licensing creates exponential cost scaling — a 10-node cluster with Oracle on only 1 node may still require 10 nodes' worth of licenses under Oracle's interpretation. Our Processor Factor Calculator models these scenarios.

The foundational contract governing an enterprise's Oracle relationship — covering license terms, audit rights, support obligations, warranty limitations, and liability caps. The OMA is typically supplemented by Ordering Documents (Order Forms) specifying individual license purchases and an applicable Technology License Schedule. Most enterprises accept Oracle's standard OMA terms without negotiation — a significant commercial error. The audit rights clause, the license metric definitions, the support termination rights, and the intellectual property indemnification terms are all negotiable in the OMA and directly affect the organization's compliance risk profile. See our detailed analysis: Oracle Master Agreement Guide.

A fixed-duration (typically 3 years) Oracle agreement that grants the licensee unlimited deployment rights for specified Oracle products in exchange for a fixed annual fee. At ULA expiry, the licensee must certify their deployment count — which becomes their permanent post-ULA license entitlement. ULAs eliminate per-Processor compliance risk during the ULA term but create a high-stakes certification event at expiry. Oracle actively seeks ULA certifications that undercount actual deployments to maximize renewal value. Our team has successfully certified 40+ ULAs, including all complex virtualisation, cloud, and multi-entity scenarios. See our Oracle ULA Guide and ULA Advisory service.

Oracle's broad-scope enterprise license agreement, covering all Oracle products used by the licensee across specified territories and entities. EAs typically run 3–5 years with annual true-up provisions (when the licensee pays for deployment growth above the contracted baseline). Oracle agreement pricing is heavily negotiated based on historical spend, growth projections, and Oracle's competitive pressure. Enterprise Agreement renewals are Oracle's highest-value commercial events and the primary opportunity for significant cost reduction — but only if the renewal is managed with benchmarked pricing intelligence and competitive pressure on Oracle's negotiating position. See our Oracle Contract Negotiation service.

Oracle's annual maintenance and support subscription, charged at 22% of net license value per year. SULS entitles the licensee to product updates, patches, security fixes, and access to Oracle My Support (MOS). SULS is not optional for most enterprise Oracle customers — Oracle requires active SULS for BYOL cloud deployments, and lapsing SULS terminates the licensee's entitlement to product updates. The 22% rate is Oracle's stated standard and is higher than most enterprise software vendors. Third-party support providers (Rimini Street, Spinnaker Support) offer equivalent support services at 50% of Oracle's rate, creating negotiating leverage at renewal that our Oracle Support Reduction service deploys systematically.

A periodic license reconciliation process — typically annual — where an enterprise's actual Oracle deployment is measured against its contracted license baseline, and any shortfall (deployments exceeding licenses) is remediated through additional license purchases. True-up provisions are standard in Oracle Enterprise Agreements. True-up events are Oracle's commercial opportunity to grow revenue from existing customers, and Oracle's account teams actively manage the true-up process to maximize additional purchase value. Proactive license management throughout the true-up cycle — deploying our Audit Risk Assessment tool — prevents last-minute true-up discoveries and the premium pricing that emergency license purchases attract.

The individual purchase document that specifies the Oracle products, quantities, metrics, and prices for a specific license transaction. Order Forms sit beneath the Master Agreement and supersede it on matters of specific terms (product pricing, delivery, payment). Order Forms specify the program name (the exact product SKU), quantity, metric (Processor or Named User Plus), unit price, and any product-specific terms. Discrepancies between what Order Forms specify and what is actually deployed are the mechanism by which most Oracle compliance claims arise. Maintaining accurate Order Form archives — and mapping each Order Form to its corresponding deployment — is the foundation of defensible Oracle license management.

Oracle's program allowing licensees to apply existing on-premise Oracle Database license entitlements to Oracle's cloud services (OCI) or to designated Authorized Cloud Environment (ACE) providers (AWS, Azure, GCP). BYOL reduces cloud deployment costs by applying already-purchased license value against OCI compute charges or against ACE providers' Oracle Database licensing requirements. BYOL conditions require: (a) active SULS on the corresponding on-premise license, (b) the on-premise license not being simultaneously deployed and claimed as BYOL credit, and (c) the deployment matching the Oracle ACE rules for the specific cloud provider. Oracle's cloud sales team consistently presents BYOL conditions in the most favorable possible light during pre-sale discussions; the post-deployment audit reality is more restrictive.

Oracle's program that applies a credit of 33% of OCI spending against Oracle software support bills. Support Rewards are available to enterprises with Oracle Cloud Infrastructure consumption — for every $3 spent on qualifying OCI services, $1 is credited against Oracle support invoices. The maximum Support Rewards credit is typically 25% of the Oracle support bill, and credits cannot reduce support payments below a contractually agreed floor (typically 85% of the standard support bill). Support Rewards is Oracle's primary mechanism to create financial incentive for OCI adoption — but the economics only work if OCI spending is genuinely incremental rather than on-premise workload replacement.

A report available through Oracle's My Oracle Support (MOS) portal showing all licensed Oracle products associated with an Oracle account, including product names, quantities, metrics, support expiration dates, and CSI/SLI identifiers. The Oracle License Summary Report is the starting point for any entitlement inventory and the primary document for validating what Oracle has on record against what the enterprise believes it has purchased. Discrepancies between the License Summary Report and the enterprise's internal records frequently reveal both unrecorded licenses (at risk of audit claim) and historical license purchases that were abandoned (potential right-sizing opportunity).

Oracle's published list prices for all license products, available at oracle.com/corporate/pricing. Oracle's published list prices bear no relationship to the prices that enterprises actually pay — large enterprise discounts of 50–80% off list are standard. The published list price is Oracle's opening position in a negotiation and is the basis for back-license claim calculations in audits (Oracle calculates claims at list price). Enterprises should never pay list price for Oracle products, and any Oracle quote within 20% of list price without additional negotiation represents a significant commercial opportunity missed.

A variant of the Oracle Unlimited License Agreement that does not have a certification date — the unlimited deployment rights are perpetual rather than time-limited. PULAs are rarer than standard ULAs and typically more expensive. The commercial value of a PULA is the permanent elimination of per-Processor counting compliance risk. PULAs are most appropriate for organizations with rapidly growing Oracle deployments or complex virtualisation environments where Processor counting is difficult to maintain accurately. See our Oracle PULA vs ULA guide for the comparison of when each structure is appropriate.

The use of Oracle Database by third-party applications, middleware, or integration layers that query Oracle on behalf of end users — without those users having direct Oracle Database connections. Oracle's licensing policy requires Named User Plus licenses for every user who indirectly accesses Oracle through third-party applications, regardless of whether the third-party application has a separate Oracle Application license. Indirect access is one of Oracle's most aggressive and contested audit targets, particularly for ERP systems (SAP, Workday, Salesforce) that extract or query data from Oracle Database backends. Oracle has sought back-license claims of hundreds of millions of dollars from large enterprises based on indirect access theories that are actively disputed in courts and arbitrations.

Oracle's second-generation cloud platform, launched in 2016 to replace Oracle's first-generation cloud services (Oracle Cloud Classic). OCI provides IaaS, PaaS, and SaaS services across compute, storage, networking, database, and application tiers. OCI is Oracle's strategic cloud platform and the primary vehicle for Oracle's cloud migration strategy. OCI pricing is generally competitive with AWS and Azure for Oracle-specific workloads when BYOL credits are fully applied — but significantly less competitive for non-Oracle workloads where BYOL does not apply. Oracle frequently uses audit pressure to accelerate on-premise customers toward OCI migration. Our Oracle Cloud Licensing Guide and Cloud & OCI Advisory service cover the full OCI licensing framework.

Oracle's consumption-based OCI pricing model where enterprise customers pre-purchase a pool of cloud credits that can be applied to any OCI service. Universal Credits provide pricing flexibility — unused credits roll forward within the commitment period — and typically offer 20–40% discount off Oracle's standard pay-as-you-go OCI rates for large commitments. Universal Credits commitments are typically 1–3 years and are negotiable. Oracle's initial Universal Credits proposals are invariably overpriced relative to the actual consumption level the enterprise will achieve, particularly in the first year of OCI adoption where usage ramp-up is slower than Oracle projects. See our detailed guide: Oracle OCI Universal Credits.

Cloud platforms formally approved by Oracle for BYOL deployments. The current ACEs are: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and IBM Cloud. ACE status entitles the cloud provider's customers to apply Oracle BYOL credits when running Oracle Database on the provider's infrastructure, subject to the BYOL conditions. The 0.5 Core Factor applies to Intel and AMD processors in ACE environments. ACE status can be revoked — Oracle periodically updates its list, and enterprises should verify current ACE status for their cloud provider before planning BYOL deployments. Non-ACE cloud providers require separate Oracle license purchases for cloud deployments; BYOL is not available.

Oracle's co-location infrastructure partnership with Microsoft that places OCI hardware in Azure data centers, enabling Oracle Database workloads (particularly Exadata Database Service) to run with Azure-native networking and management integration. Oracle@Azure uses OCI licensing rules, not Azure BYOL rules — the two frameworks are distinct. Enterprises using Oracle@Azure for Exadata Database Service pay OCI Exadata rates with BYOL credit applied, plus Azure network and integration costs. See our detailed analysis: Oracle Database on Azure.

Oracle's engineered database hardware platform combining Oracle Database, Oracle Linux, and custom storage cells for high-performance OLTP and analytics workloads. Exadata is available on-premise (Oracle Exadata Database Machine), as a cloud service on OCI (Exadata Database Service), and through Oracle Cloud@Customer (ExaCC, physical Exadata hardware deployed in customer data centers). Exadata licensing is all-inclusive for the Exadata Database Service on OCI — compute and software are priced together. On-premise Exadata Database Machine licensing follows standard Processor license rules, with the number of licenses depending on the Exadata configuration and which cores are allocated to Oracle Database workloads.

Oracle's offering that places OCI hardware physically in customer data centers while Oracle manages the infrastructure remotely. Cloud@Customer variants include Exadata Cloud@Customer (ExaCC) for database workloads and Dedicated Region Cloud@Customer for full OCI region deployment. Cloud@Customer uses OCI pricing and licensing — consumption-based OCPU billing — with Oracle responsible for hardware maintenance and upgrades. Cloud@Customer eliminates data sovereignty and latency concerns for organizations that want OCI economics without sending data outside their own facilities.

A specific Oracle@Azure offering that enables Oracle Database workloads (running on OCI Exadata in Azure data centers) to be managed through the Azure portal with native Azure Active Directory integration, Azure monitoring, and Azure DevOps tooling. The Oracle Database Service for Azure creates a unified operational experience for enterprises with Azure-centric operations teams who need Oracle Database performance characteristics. Licensing follows OCI Exadata Database Service rules, with BYOL credit available for enterprises with qualifying on-premise Oracle Database Processor licenses.

The shared-infrastructure variant of Oracle Autonomous Database (ADB-S), where Oracle provisions and manages compute and storage from a shared pool. ADB-S is priced per OCPU-hour and storage TB per month, with BYOL available. The "serverless" terminology is Oracle's marketing description of the automated scaling capability, not a technical serverless architecture in the AWS Lambda sense. ADB-S is Oracle's most accessible cloud database entry point for enterprises with smaller Oracle workloads or development use cases where dedicated Exadata performance is not required.

Oracle's incentive program crediting 33% of qualifying OCI spending against Oracle software support invoices, to a maximum of 25% support cost reduction. Support Rewards is Oracle's primary commercial lever for encouraging existing Oracle support customers to adopt OCI for new workloads. The maximum effective Support Rewards saving for an enterprise spending $2M per year on Oracle support is approximately $500K — achievable only if OCI consumption exceeds $1.5M per year. Enterprises should model Support Rewards credits against OCI infrastructure costs before factoring them into OCI economic projections.

Oracle's full OCI region deployed in a customer data center — a minimum of 140 racks of Oracle hardware providing complete OCI services including Exadata, Autonomous Database, Oracle Applications, and all OCI IaaS and PaaS services. Dedicated Region Cloud@Customer is Oracle's response to hyperscale cloud providers' dedicated/local zone offerings and is targeted at enterprises with strict data sovereignty requirements, financial services firms with regulatory restrictions on public cloud, and government organizations requiring isolated cloud infrastructure. Pricing is based on minimum OCI consumption commitments that typically start at $3M+ per year.