Oracle Database Licensing FAQs
What license metrics are available for Oracle Database?
Oracle Database is typically licensed under two main metrics: Processor and Named User Plus (NUP). These determine how usage is measured:
- Processor License: Based on the number of processor cores on the servers where the database is installed/running. This metric is often used for environments with many users or public-facing applications.
- Named User Plus License: Based on counting actual users (or devices) accessing the database. This metric is suitable for internal applications with a limited user population. You must purchase a license for each named user (with some minimum counts per server or processor).
What is an Oracle Database Processor license, and how do I calculate how many I need?
A Processor license allows an unlimited number of users to access the database on a server, and the cost is based on the CPU cores of that server. Oracle defines a “processor” for licensing as a hardware core multiplied by a core factor (a multiplier based on CPU type).
To calculate the number of Processor licenses needed:
- Count the physical cores in the server (or cluster) where the Oracle Database will run.
- Apply Oracle’s Core Factor for the processor type (for example, Intel x86 chips have a factor of 0.5).
- Multiply cores × core factor to get the required licenses (round up fractions to the next whole license).
Example: A server with 8 Intel cores requires 8 × 0.5 = 4 Processor licenses. This metric covers any number of users on that server.
What is a Named User Plus (NUP) license, and how do I count users for licensing?
A Named User Plus license is based on the number of distinct users or devices accessing the Oracle Database. Every person or device that uses the database (directly or indirectly) needs a license. Key points for NUP licensing:
- Counting Users: Count all individuals (or non-human operated devices) authorized to use the database, regardless of how often they use it. (Even users connecting through a shared app or multiplexing must be counted individually.)
- Minimums: Oracle requires a minimum number of NUP licenses per processor to ensure a base level. For Enterprise Edition, the minimum is 25 Named Users per processor. For Standard Edition 2, the minimum is typically 10 Named Users per server (since SE2 is licensed per socket, up to 2 sockets).
- You must license all those users if your user count exceeds the minimum. Even if it’s lower, you still must meet the minimum requirement.
Example: If an Enterprise Edition database runs on a server requiring 2 Processor licenses, you need at least 2×25 = 50 Named User Plus licenses, or more if you have more than 50 users.
When should I choose Named User Plus licensing instead of Processor licensing?
Choose Named User Plus (NUP) licensing when you have a known, relatively small user population. It can be more cost-effective for internal systems.
Scenarios where NUP is appropriate:
- Internal Applications: NUP licensing could cost less than buying per-processor licenses if the database is used by a specific team or a fixed number of employees (say 20 or 50 users).
- Development/Test Systems: If only a few developers or testers access the database, NUP can cover them at a lower cost (ensuring minimums are met).
On the other hand, use Processor licensing when: - User Count is High or Unpredictable: For public web applications, customer-facing systems, or any scenario where the number of users is large or not capped (for example, a website or packaged software), it’s usually required to license per Processor because counting each user is impractical or impossible.
- Third-Party or Batch Access: If many devices or an unknown number of sensors connect, or if usage comes through an application server pooling connections, Processor licensing avoids counting every endpoint.
NUP is best for smaller, controlled user bases, while Processor is best for unlimited or large user bases. Always compare costs: if the NUP count (including minimums) exceeds the cost of processor licenses, go with the processor metric.
How do multi-core processors and Oracle’s Core Factor table affect database licensing?
Oracle uses a Core Factor table to account for the performance of different CPU architectures. Instead of licensing every core 1-for-1, Oracle applies a factor (a decimal) to the core count.
This means that multi-core processors might require fewer licenses than the total number of cores. For example:
- Intel/AMD x86 processors: Core factor is 0.5. So, two cores = 1 license (approximately). A 16-core Intel CPU would need 16×0.5 = 8 Processor licenses.
- IBM POWER CPUs: The core factor might be 1.0 (depending on the model), so every core counts fully. Eight cores would need eight licenses.
- Oracle SPARC processors: Many have a factor of 0.5 or 0.75, so licensing is reduced similarly.
When calculating licenses on multi-core systems, always multiply core count by the factor. Oracle publishes the official Core Factor table on its site. This approach ensures you don’t overpay for highly multi-core CPUs – e.g., an 8-core Intel server requires 4 licenses (with 0.5 factor) instead of 8. (Note: Core factors apply only to Processor licenses on-premises; in certain cloud scenarios, as noted later, core factors are not used.)
Is a minimum number of Named User Plus licenses required per processor or server?
Yes. Oracle enforces minimum NUP counts to ensure baseline license coverage:
- Enterprise Edition (EE): The minimum is 25 Named User Plus per Processor. This means that for each processor license (as calculated by cores × core factor) on the server, you need at least 25 user licenses. For example, if an EE database runs on a machine that counts as 2 Processors, you must have at least 50 Named User Plus licenses, even if actual users are fewer.
- Standard Edition 2 (SE2): The minimum is 10 Named User Plus per server (or per organization for that server). Since SE2 is licensed per socket (up to 2 sockets), if you use NUP licensing on SE2, you need at least 10 named users for that server. (If you have multiple servers with SE2, each needs a minimum of 10 users licensed.)
These minimums are per Oracle’s licensing policy to prevent extremely low user counts on a large system. You always compare the actual number of users to the minimum and license whichever is higher. If you cannot meet these minimum user counts (for example, a single-user system), you might consider processor licensing instead or consolidate with fewer processors to reduce the minimum.
How is Oracle Database licensed in a VMware or other virtualized environment?
Licensing Oracle on VMware (and similar virtualization platforms) can be challenging because Oracle’s rules generally don’t recognize software partitioning as a way to limit licenses.
Key considerations:
- All Physical Cores Must Be Licensed: In a VMware environment, if an Oracle Database runs on a host (or cluster), Oracle requires you to license every physical core on every host where the VM could run. Even if you allocate the VM only two vCPUs, Oracle does not accept that as a limit, since VMware allows VMs to move between hosts (vMotion). Unless you have isolated Oracle to a dedicated host or cluster, you may need to cover the whole cluster.
- License per Host or Cluster: A common practice is restricting Oracle VMs to specific hosts (a dedicated cluster for Oracle workloads). You then license all cores on those hosts. For example, if you have a VMware cluster of 3 hosts, each with 16 cores, and Oracle VMs can run on any of them, you must license 3×16 cores (with core factor applied if applicable). If you instead pin the Oracle VM to one 16-core host (and it cannot move elsewhere), you could license just that host’s cores.
- Soft vs. Hard Partitioning: Oracle classifies VMware and most hypervisors as “soft partitioning,” which means they do not limit license requirements. Only certain technologies (called hard partitioning – e.g., Oracle’s VM with specific CPU pinning, Oracle Linux KVM with CPU binding, IBM LPAR, etc.) are recognized as ways to limit CPU licensing. If you’re using VMware, assume you must license the entire physical environment that Oracle might run on.
In summary, in virtual environments like VMware, plan to license Oracle Database as if it’s running on the full physical resources available to it. To control costs, isolate Oracle workloads to dedicated hosts or use Oracle-approved hard partitioning methods.
Can I license only certain CPU cores (hard partitioning) to reduce Oracle licensing costs?
Oracle allows sub-capacity licensing only if you use approved “hard partitioning” methods or certain virtualization technologies that Oracle recognizes. You cannot simply decide to use fewer cores on an unapproved platform to pay fewer licenses.
For example:
- If you have a 32-core server but only want to license 8 cores for Oracle, you must physically partition or cap the server using an Oracle-approved method. Approved methods include Oracle VM Server with pinned vCPUs, Oracle Linux KVM with hard partitioning configuration, Solaris Zones (capped zones), IBM LPAR, etc. These techniques dedicate a fixed number of cores to Oracle, and Oracle agrees you can license just those cores.
- Methods like VMware vSphere, Microsoft Hyper-V, or Docker CPU shares are not accepted as license reducers. These are considered “soft partitioning.” Even if you restrict an Oracle VM to certain cores via software, Oracle will still require the licensing of the full machine or cluster.
Example: Using Oracle VM, you could allocate a VM to 4 specific cores of a 16-core server and license just those 4 cores (with the appropriate core factor). But doing the same on VMware or an uncapped Docker container wouldn’t be recognized – you’d need to license all 16 cores.
In practice, if you want to limit Oracle licensing, use Oracle’s virtualization or physically limit the hardware. Otherwise, assume all available cores need to be licensed.
What are the differences between Oracle Database Enterprise Edition and Standard Edition 2 licensing?
Oracle offers Enterprise Edition (EE) and Standard Edition 2 (SE2), and they differ in both capabilities and licensing rules:
- Cost and Metric: Enterprise Edition is higher-end and is usually licensed per core (Processor or NUP with core factors). Standard Edition 2 is lower-cost and licensed per socket (for Processor metric) or NUP. SE2 licenses are sold per socket, with a maximum of 2 sockets allowed on any server. You do not count cores or use core factors for SE2 – one Processor license covers one occupied socket.
- Feature Availability: Enterprise Edition can be enhanced with add-on options (RAC, Partitioning, Multitenant, etc. – each at extra cost). Standard Edition 2 includes the basic database functionality but does not include most advanced features and cannot use separately licensed options (they’re simply not available in SE2). For example, Partitioning, Active Data Guard, and other EE options are not usable with SE2.
- Hardware Limits: SE2 is restricted to smaller servers. You can only deploy SE2 on servers with up to 2 CPU sockets (regardless of how many cores are in those sockets). Enterprise Edition has no socket limit – you can run it on large multi-socket, multi-core machines (just license all the cores with factors).
- Scalability: Because of the socket limit and some technical limits (SE2 will only use up to 16 CPU threads per instance), SE2 is meant for small to mid-size workloads. Enterprise Edition can scale to larger hardware and clusters.
- Included High Availability: SE2 (up to version 18c) allowed the use of Real Application Clusters on two nodes at no extra cost, but as of 19c, SE2 no longer supports RAC (we discuss this below). Enterprise Edition supports RAC as a paid option.
Standard Edition 2 is cheaper and simpler to license (great for small deployments) but cannot run on big hardware or use advanced database options. Enterprise Edition is more flexible and powerful but has a higher licensing cost proportional to cores and any extra options you enable.
Are there hardware limits or restrictions when using Oracle Database Standard Edition 2?
Yes, Oracle Database Standard Edition 2 (SE2) has specific restrictions by design:
- Maximum 2 Sockets: SE2 may only be licensed on servers with a maximum of 2 processor sockets. It doesn’t matter if one socket is empty – the server’s capacity must be two sockets or less. (For a 2-node cluster, each node must meet the 2-socket limit.)
- Core Count Per Socket: There is no core limit per socket – if your 2-socket server has processors with many cores, you only need one SE2 license per socket. This means SE2’s cost doesn’t increase if you upgrade to a CPU with more cores, as long as you stay within two sockets.
- Real Application Clusters (RAC): In Oracle 12c and 18c, SE2 allowed RAC across up to 2 nodes (each node up to 2 sockets). However, starting with Oracle 19c, RAC is no longer permitted on Standard Edition 2. Oracle replaced it with “Standard Edition High Availability (SEHA),” a cluster failover solution (one active instance at a time) that uses Oracle Clusterware. This provides high availability without both nodes being active, and it’s included with SE2 (no extra license for SEHA).
- Deployment Size: In cloud environments, Oracle’s policy limits SE2 to instances with up to 8 virtual CPUs (which correspond roughly to 2 sockets in the cloud – we’ll detail this later).
These limits mean SE2 is targeted at smaller deployments. If your environment exceeds two sockets or requires active-active clustering or advanced options, you’d need to consider Enterprise Edition.
How do I license Oracle Database for high availability or failover scenarios?
Oracle provides special licensing accommodations for failover (standby) servers to support high availability:
- Cold/Passive Failover: If a secondary server is normally shut down or only used when the primary fails, Oracle’s licensing rules allow you to use that secondary for up to 10 days per year without requiring a separate license. This is often called the “10-day rule.” It means you can install Oracle Database on the failover server and keep it ready, and if you switch over during a failure or for testing, you don’t need to license it as long as usage doesn’t exceed 10 distinct days in a calendar year. After 10 days of total use, that server must be fully licensed.
- Only one failover node can be exempt like this. If you have multiple backup nodes, only one can run unlicensed during an outage; additional standby servers would require licensing.
- The failover environment should be in the same cluster or data center and only used when the primary is down. When you regularly use both primary and secondary (for active workloads), the secondary isn’t considered “failover” and needs full licensing.
- Active Standby (Active Data Guard): If you want the standby database to be open and in use (for read-only queries or reporting while it continuously applies changes), that is not covered by the free 10-day rule. In that case, you must license the standby server fully and the Active Data Guard option (see the question on Active Data Guard). Essentially, an active replica requires the same licensing as a production server.
Examples:- If you have an Oracle EE database on an 8-core server and an identical 8-core standby that is normally off, you can keep the standby unlicensed until a failover occurs. If the primary fails and you run on the standby for 3 days and later for 2 days during testing, 5 out of 10 free days are used. Beyond 10 days, you’d need to buy licenses for that standby.
- If you use Standard Edition 2, Oracle’s SE High Availability (one instance active at a time using Clusterware) can also take advantage of the 10-day rule for the secondary node being mostly idle. You wouldn’t need separate licenses for the second node unless it runs more than 10 days as the active database.
How do I license Oracle Database on Amazon Web Services (AWS) or Microsoft Azure?
On AWS and Azure (as well as Google Cloud), you typically use your existing Oracle licenses in a Bring Your Own License (BYOL) model for Oracle Database. Oracle has a cloud licensing policy that dictates how to count cloud vCPUs against your licenses:
- Counting vCPUs: Oracle considers every two virtual CPUs (vCPUs) equivalent to 1 Oracle Processor license on AWS or Azure because these clouds use hyper-threaded cores. (If a cloud instance type did not use hyper-threading, one vCPU would count as 1 Processor license, but in AWS/Azure, vCPUs are threads.) For example, an AWS EC2 instance with eight vCPUs would require 4 Enterprise Edition Oracle Processor licenses.
- No Core Factor in Cloud: The core factor table is not applied in these authorized cloud environments. Oracle uses the simpler 2-for-1 vCPU rule regardless of processor type in the cloud. So even though an Intel core has a 0.5 factor on-prem, in AWS/Azure, you already get that effect via the two vCPU = 1 license rule.
- Named User Plus in Cloud: You can also use NUP licensing in the cloud, though it’s less common. The same two vCPU = 1 processor logic applies for minimums. For instance, on an eight vCPU Azure VM (which counts as four processors by Oracle’s cloud rule), you’d need at least 4×25 = 100 Named User Plus licenses (if using Enterprise Edition by NUP). In practice, many cloud deployments go with Processor licensing for simplicity, unless the user count is very small.
- Example: Suppose you want to run Oracle EE on an AWS EC2 m5 instance with four vCPUs. Since 2 vCPUs = 1 Oracle Processor, four vCPUs count as 2 Oracle Processors. You would need two processor licenses for Oracle Database Enterprise Edition. That license covers all uses on that VM.
- Include all VMs/Nodes: Ensure you count all the cloud instances where the database will run. If you use auto-scaling or multiple AZs/regions, each needs appropriate licensing (there’s no 10-day rule for cloud failover; that rule is for on-prem clusters).
To license Oracle on AWS/Azure, count your instance’s vCPUs and divide by 2 (round up) to get the required licenses. Use your existing Oracle licenses to cover that, or purchase new licenses accordingly. Always adhere to Oracle’s cloud policy specifics.
Does Oracle’s core factor apply to cloud environments like AWS and Azure?
No – Oracle’s Core Factor is not used in public cloud licensing for AWS, Azure, or Google Cloud. Instead, Oracle has a fixed conversion for virtual CPUs in these Authorized Cloud Environments: two vCPUs are one license (for the Enterprise Edition Processor metric). This effectively assumes a core factor of 1.0 for cloud simplicity. Details:
- In AWS/Azure, regardless of the underlying chip, you use the 2 vCPU = 1 Oracle Processor rule. For example, even though an on-prem Intel core has a 0.5 factor, in AWS, an 8 vCPU VM needs four licenses—the same outcome as core factor 0.5 would give. However, Oracle explicitly says not to use the core factor table, just the vCPU rule.
- This means you don’t get additional reductions for any specific processor type in the cloud – the formula is standardized.
- If a cloud instance does not use hyper-threading (some specialized instances), Oracle would count one vCPU as 1 Processor license. However, the common instances in AWS/Azure use hyper-threading, so the 2-for-1 rule applies by default.
In short, do not apply the core factor table to cloud VMs. Instead, use Oracle’s cloud policy guidelines (2 vCPUs = one license) to determine the licensing requirements on AWS/Azure.
Can I use Oracle Database Standard Edition 2 on AWS or Azure, and what are the limitations?
Yes, you can use Standard Edition 2 on AWS/Azure under BYOL, but there are important limitations consistent with SE2’s rules:
- Instance Size Limit: Oracle’s cloud licensing policy limits Standard Edition deployments. Standard Edition 2 may be used on instances with up to 8 vCPUs in AWS or Azure. This corresponds to SE2’s 2-socket limit (Oracle treats four vCPUs as one “socket” in the cloud). If you go above 8 vCPUs, you exceed SE2’s allowed size.
- Counting SE2 Licenses in Cloud: Oracle counts up to 4 vCPUs as one socket (one SE2 license). For >4 vCPUs up to 8, that counts as two sockets (two SE2 licenses). You round up to the nearest increment of 4 vCPUs as a socket. For example, a six vCPU VM on Azure would count as 2 sockets (since it’s over 4), requiring 2 SE2 processor licenses (and six vCPUs is within the 8 vCPU max).
- No Enterprise Features: SE2 can’t use Enterprise Edition options, even in the cloud. So you couldn’t deploy an SE2 instance with partitioning or RAC (RAC is not allowed from 19c on anyway).
- BYOL Only: AWS and Azure don’t provide SE2 as a license-included service (except possibly Amazon RDS, which has separate rules). So you must bring your own SE2 licenses. Ensure you have enough licenses (e.g., 2 SE2 licenses to cover a 2-socket equivalent cloud VM).
Example: If you want to run an Oracle SE2 database on an AWS instance with 8 vCPUs, that’s the maximum. Oracle would treat that as 2 sockets (since 8 vCPUs = two 4-vCPU chunks). You’d need 2 SE2 Processor licenses to cover it. If you tried to use a 16 vCPU instance, that would violate SE2’s policy (exceeding 8 vCPU limit). In that case, you’d have to use Enterprise Edition or scale out multiple smaller VMs.
What does “Bring Your Own License (BYOL)” mean for Oracle Database?
Bring Your Own License (BYOL) means you take an Oracle Database license you’ve purchased (for on-premises use) and apply it to an environment in the cloud or other deployment. Key points about BYOL:
- Use Existing Entitlement: With BYOL, you leverage your investment in Oracle licenses. Instead of buying a new license from the cloud provider, you allocate your on-prem license to cover the cloud instance or service.
- Supported Platforms: Oracle explicitly allows BYOL in their own Oracle Cloud Infrastructure (OCI) and on authorized cloud providers like AWS and Azure (and in other scenarios like VMware, provided you adhere to license rules). You must follow the same license metrics (Processor or NUP) and ensure the cloud usage doesn’t exceed your purchase.
- Example: If you own 4 Processor licenses of Oracle Database Enterprise Edition, you can launch an AWS EC2 VM that requires up to 4 licenses (for instance, an 8 vCPU EC2 as we discussed) and designate your licenses for that VM. You continue to pay Oracle support on those licenses but don’t pay Oracle any new license fee for running in AWS.
- BYOL vs. License-Included: BYOL differs from “license-included” cloud services, where you pay for the license as part of the VM or service cost. BYOL means you only pay the cloud provider for infrastructure; licensing is covered by what you’ve already bought from Oracle. Often, BYOL can be cost-efficient if you already have licenses under maintenance.
- Keep Compliance: Even in BYOL, you are responsible for staying compliant. Track how many licenses are in use in the cloud vs. on-prem. You cannot “double dip” (simultaneously use the same licenses on-prem and in the cloud beyond your entitlements). Usually, you’d migrate a license from on-prem to cloud (i.e., stop using it on-prem if you’re now using it for the cloud deployment unless you have enough licenses to cover both).
How do I license Oracle Database on Oracle Cloud Infrastructure (OCI)?
Oracle Cloud offers two licensing models for database services: License Included and BYOL (Bring Your Own License).
To license on OCI:
- License Included (LI): You simply provision an Oracle Database service (on VM, Bare Metal, Autonomous DB, etc.) and pay for the compute/service with the Oracle license bundled in. The hourly rate or monthly cost for the service includes the cost of the Oracle Database license. You do not need to own any Oracle license separately – it’s a rental. This is straightforward if you have no existing licenses.
- BYOL on OCI: Oracle gives a pricing discount if you bring your license. You certify that you have a certain number of licenses, and then you can run Oracle Database on OCI at a lower cost (since you’re only paying for the cloud resources, not the license). For example, if you BYOL a 2-processor Enterprise Edition to OCI, you can spin up an OCI DB system using up to 2 OCPUs of EE, and you’ll be charged the lower BYOL rate for the VM or DB service.
- Counting OCPUs: OCI uses the term OCPU, which typically equals one physical core of an Intel/AMD processor (with hyperthreading, that shows as two vCPUs to the OS). Oracle’s policy on OCI is that 1 OCPU corresponds to 1 Oracle Processor license (because an OCPU is one full core). So, if you have four Processor licenses for Oracle EE, you can use up to four OCPUs of equivalent OCI compute under BYOL.
- Named User Plus on OCI: You can also apply NUP licenses to OCI instances if you have them, subject to the same minima. However, most OCI Database services in BYOL assume you’re bringing processor licenses. If using NUP, you’d typically use it on a VM compute instance where you install Oracle manually. Ensure the user counts meet Oracle requirements.
In summary, on Oracle’s cloud, you either pay Oracle for the license as part of the cloud service (License Included) or pay a reduced rate by bringing your existing licenses (BYOL). The actual license counting (OCPUs to licenses) aligns closely with on-prem rules (1 core = 1 license for Enterprise Edition on OCI).
What is the difference between “license included” and BYOL in Oracle Database cloud services?
The difference is whether you are using a new license bundled with the cloud service or an existing license you already own.
- License Included: The cloud provider (Oracle Cloud or even AWS RDS in some cases) provides you the Oracle Database license as part of the service subscription. You pay an all-in-one price. You do not need to have any Oracle license beforehand. For instance, choosing an “Oracle Database Cloud Service – License Included” means Oracle charges you a higher hourly rate that covers software license fees. This is convenient if you don’t own licenses or want a purely operational expense model.
- Pros: Simplicity (no separate Oracle support contract needed), flexibility (start/stop anytime).
- The cons: The cost can be higher over the long term since you’re renting the license. You also cannot use that license outside the cloud service.
- Bring Your Own License (BYOL): You supply an existing Oracle license to cover the deployment. The cloud service (Oracle’s or others) charges you a lower rate for the infrastructure because you’re not paying for the database software itself through them. You remain responsible for the Oracle license (you must keep it active on support with Oracle).
- Pros: It can be cost-effective if you already have licenses; you can leverage your investment and pay only for cloud resources. Oracle Cloud often discounts BYOL on Autonomous Database or DB systems.
- Cons: You must manage compliance (ensure you have enough licenses for what you deploy). If your cloud usage changes, you may need to adjust your license counts accordingly.
Example: In Oracle Cloud Infrastructure, an Autonomous Database might cost $2.52 per hour with license included but only $1.20 per hour with BYOL (illustrative figures). The BYOL rate assumes you have appropriate licenses in your inventory. You’d have to acquire them or use the license-included rate if you don’t.
Are there free or trial options for Oracle Database that don’t require a paid license?
Yes, Oracle provides a couple of free options for limited use cases, which are great for learning, development, or small workloads:
- Oracle Database Express Edition (XE): This is a free edition of Oracle Database you can install on-premises (or even in a VM). It has limitations (for example, it can use only up to 2 CPU threads and 2GB of RAM and store up to 12GB of user data in the latest versions). XE is free to use for any purpose, including production, but its technical limits mean it’s suitable only for small workloads or testing. You don’t need any license for Oracle XE – just accept the free license agreement (which restricts support/updates).
- Oracle Cloud Free Tier: Oracle Cloud offers an Always Free tier where you can use certain resources at no cost, including Oracle Autonomous Database. This allows you to run a small Oracle Database in the cloud (with fixed low CPU and storage limits) for free indefinitely. It doesn’t consume your licenses and is a good way to experiment or build a prototype without license fees.
- Developer License for Oracle Software: Oracle also allows you to download Enterprise Edition (and other editions) for development and testing under the Oracle Technology Network (OTN) Developer License. This isn’t a production license – it’s a free agreement allowing product evaluation and development use. If you’re just a developer trying out Oracle locally, you can use the full software under this license. However, for any production or commercial use, you must purchase licenses.
Keep in mind that these free options have restrictions (either technical or license scope). If your needs outgrow XE or the free tier, move to a licensed edition (Standard or Enterprise) and comply with the standard licensing rules discussed.
Do I need to purchase separate licenses for Oracle Database options like RAC, Partitioning, or others?
Yes. Many advanced features of the Oracle Database are packaged as options or packs that require additional licenses on top of the base database license. An Enterprise Edition license allows you to use the core database engine, but options such as those listed are not included by default.
For each option you use, you must license it for the same processors or users as your database. For example:
- Oracle Real Application Clusters (RAC): Separately licensed option. If you run EE on a cluster and use RAC, you must pay for RAC licenses for all the processors on those nodes.
- Oracle Partitioning: Separately licensed. You must have Partitioning option licenses for all processors where the database using partitions runs.
- Oracle Multitenant: Separately licensed (for more than a certain number of pluggable databases).
- Oracle Active Data Guard: Separately licensed for using a standby database in open read-only mode or other ADG features.
- Other Options/Packs: Oracle offers many options, such as an in-memory column store, advanced security, diagnostics pack, tuning pack, etc. Each has its licensing requirement. Some are options (additional database capabilities), and some are management packs (for tools/monitoring). Generally, if it’s listed as an “Option” or “Pack” in Oracle’s price list, it requires a separate license.
Important: If you’re on Standard Edition 2, you cannot use these options (they’re only available with Enterprise Edition). The exception in recent times is that some options have been made free for everyone (for example, Oracle made Spatial and Graph features and Oracle Machine Learning free with all editions in 19c). Always check current Oracle documentation because an option’s licensing status can change occasionally.
In summary, assume that major features outside the core database require an extra license. Always enable options only if you have purchased the rights to use them, as Oracle often audits their usage. Below, we cover specific licensing for some of the most common options.
How is Oracle Real Application Clusters (RAC) licensed?
Oracle RAC allows a single database to run across multiple servers (cluster nodes) for high availability and scalability. Licensing RAC involves:
- Enterprise Edition RAC: Oracle RAC is a licensed option for Enterprise Edition. You must pay for each server’s Oracle Database Enterprise Edition and Oracle RAC option licenses. The RAC option is licensed per processor (or NUP), just like the database. If you have a cluster with two nodes, each with eight cores (0.5 factor), you might need 4 EE licenses per node and 4 RAC option licenses per node. So in total, that cluster would have 8 EE licenses and 8 RAC option licenses. RAC licensing can effectively double the cost since you license the option in addition to the base DB.
- All Nodes Must Be Licensed: You must license RAC for every node in the RAC cluster. You cannot, for example, license only some nodes for RAC. Even the passive nodes in a RAC cluster (in RAC, all nodes can be active anyway).
- Standard Edition RAC: In older versions, Standard Edition (before 19c) included RAC for free on up to 2 nodes. However, RAC is not supported with SE2 19c and above. You don’t pay for RAC in SE2 because you simply can’t use it. Instead, SE2 uses the free SE High Availability (not RAC, just failover). If you are on 18c or earlier with SE2, you could use RAC on two 2-socket servers without needing an extra license (included in the SE2 license). Upgrading past 18c would remove that ability.
- Example: Suppose you have an Oracle EE database deployed on a 3-node RAC cluster, each node with four cores (and factor 0.5, so two licenses per node). You would purchase 2×3 = 6 Processor licenses of Oracle EE and 6 Processor licenses of the RAC option. If you have Named User Plus licensing, you would count users normally for EE (with 25 per processor minimums across the cluster) and also ensure the RAC option has the equivalent number of NUP licenses (Oracle requires that options have at least the same number of NUP as the base DB).
RAC can greatly improve availability, but remember to budget for the base database and the RAC option licensing on all participating machines.
Is Oracle Multitenant included with Oracle Database, or does it require a separate license?
Oracle Multitenant is the option that enables the use of multiple pluggable databases (PDBs) within a single container database (CDB). Licensing depends on how many PDBs you want:
- Single PDB (without license): In Enterprise Edition, you are allowed to create a CDB with up to 3 pluggable databases without purchasing the Multitenant option (this policy was introduced in Oracle 19c; before 19c, it was one user-created PDB without a license). This means small-scale consolidation (a few databases) can be done at no extra cost beyond the EE license.
- Multiple PDBs (with license): If you want more than the allowed free PDBs in one container (for example, 5, 10, or 50 PDBs in one Oracle instance for heavy consolidation), you must purchase the Oracle Multitenant option. This option is licensed per processor (or user) just like other options. You need to license all CDB processors for Multitenant. So if your server requires 4 processor licenses for EE and you have more than 3 PDBs, you’ll also need 4 licenses for a multitenant.
- Standard Edition 2: SE2 cannot purchase or use the Multitenant option. Starting with Oracle 21c, all Oracle databases use the multitenant architecture under the hood, but SE2 is effectively limited to a single user PDB (no license is needed since you can’t go beyond one anyway). So SE2 users don’t pay for Multitenant and cannot create extra PDBs beyond the one.
- Example: You have a large server running Enterprise Edition and want to host 10 separate databases on it as PDBs (to save resources vs separate instances). You are running Oracle 19c. Oracle allows 3 PDBs free, but you need the Multitenant license for the additional 7 PDBs (making a total of>3). If the server is 16 cores (Intel, 0.5 factor = 8 EE licenses), you would buy 8 licenses of the Multitenant option in addition to the 8 EE licenses. This permits you to create up to 252 PDBs in one CDB (the technical limit with the option).
The Multitenant option is only needed if you exceed the free PDB count. You can avoid that cost by using a small number of consolidated databases. However, for heavy consolidation, factor in the multitenant licensing for Enterprise Edition.
How do I license Oracle Active Data Guard for a standby database?
Active Data Guard (ADG) is an option for Enterprise Edition that extends Data Guard functionality. It allows you to have a standby database open read-only while applying changes (and use advanced features like fast incrementally updated backups on standby, automatic block repair, etc.). Licensing rules for Active Data Guard:
- Separate Option License: Active Data Guard is not included with Enterprise Edition by default; it requires its license. You must license Active Data Guard for the same number of processors or NUPs as your Oracle Database on the standby server. Where your standby database is running, if it’s open for reading or using ADG features, those cores/users must have ADG option licenses.
- Primary vs Standby: You typically do not need to license ADG on the primary database server – the option is all about the standby. You license the standby. (The primary database uses Data Guard transport, which is included in EE, but if you want to open the standby or use ADG-specific features, that standby must be licensed for ADG.)
- If Standby is Idle: If you are not using Active Data Guard (i.e., the standby is either constantly in recovery mode and not open for reads except potentially during a failover), you don’t need ADG licenses at all – Data Guard (transmission of redo) is included in EE. You could use the normal failover rights (and the standby would need its own EE license if it’s ever actively open beyond the 10-day rule). The ADG license is specifically for activating the standby for read-only queries or any ADG-exclusive feature while still applying logs.
- Named User Plus: If using NUP licensing, the standby with ADG enabled must have at least the same user count of licenses as the primary. Typically, the user population for primary and standby is the same, so you’d just ensure that the ADG option NUP licenses match that.
Example: You have a primary database on an 8-core server (with 4 EE licenses after core factor) and a standby on another 8-core server. You want to offload reporting queries to the standby (read-only) continuously. You would purchase 4 Processor licenses of Active Data Guard (matching the 4 EE licenses on that standby). This allows you to run the standby open for reading while in sync. If you decide not to open the standby for read (using it only for failover), you could avoid buying ADG licenses altogether and just license the standby with EE (or rely on the 10-day rule if truly idle until failover).
What are the licensing requirements for Oracle’s Partitioning option?
The Oracle Partitioning option (part of Enterprise Edition) must be licensed if you use partitioned tables or indexes in your database. Key points:
- Enterprise Edition Only: Partitioning is only available with the Enterprise Edition of Oracle Database. You cannot add it to Standard Edition. In EE, it’s not included by default—it requires purchasing the Partitioning option.
- License All Processors: You need to license Partitioning for every processor on which your Oracle database runs (or an equivalent number of NUP licenses if you’re using NUP metric). The option must be licensed at the same scale as the database. If your database is licensed for 8 processors of EE, and you want to use partitioning, you must also buy 8 processor licenses of Partitioning.
- No Partial Use: You cannot license Partitioning on only some subset of CPUs or for some schemas – it’s either on or off for the database instance. So if partitioning is used anywhere in that Oracle instance, all the CPUs that instance runs on need the option.
- Cost Consideration: Partitioning is an extra cost, but it can be invaluable for managing large tables. Some organizations choose not to use it to avoid the license fee, but others find the performance and maintenance benefits worth it. It’s a decision to weigh, and if budget is a concern, note that newer Oracle versions include some basic partitioning-like features for free (like partitioning of XML tables or sharding, which is separate) – but the classic Partitioning of tables requires the option license.
- Example: Suppose you have a data warehouse on an Oracle EE database running on 4 processors (let’s say 8 cores at 0.5 each). The data volume is large, and you want to partition a huge sales table by month. To legally use that partitioning feature, you must have 4 Partitioning licenses (in addition to your EE licenses). If you later scale the server up to 8 processors, you’d need to increase to 8 Partitioning licenses to cover the new cores. If you remove partitioning (no partitioned tables), you could drop the Partitioning option from a licensing perspective at the next renewal.
Do I need to license Oracle Database for development, testing, or QA environments?
Yes. Any installation of Oracle Database not covered by a special free license will generally need to be licensed, even if it’s non-production. Oracle’s standard licenses apply to production and non-production alike.
However, you have a few ways to handle development/testing:
- Use existing licenses: Many companies use Oracle to cover dev/test systems. For example, if you have a license for 2 processors of EE in production, and you have another test server with 2 processors, that test server needs its licenses as well (Oracle doesn’t automatically allow you to duplicate a prod license for test). You’d either allocate additional licenses or include it under an Unlimited License Agreement if you have one. Every environment where the software is installed should be licensed.
- Named User Plus for Test: If your test systems have only a few users (developers/QA), you might license them with Named User Plus licenses instead of processor licenses to save cost – as long as they meet the minimums. For instance, you could license a development database by naming the specific developers as users. This can be cheaper than licensing by core if the environment is small.
- Oracle Developer License / Personal Use: Oracle provides free developer-use downloads. A single developer can install Oracle Database under the OTN Developer License for personal test and development (not for use by a whole team or for staging). This is more for individuals experimenting or building skills, not for organizational use. An organization’s test environment that multiple people use is expected to be licensed under normal terms.
- Oracle Cloud for Dev/Test: Some teams spin up temporary Oracle instances in Oracle Cloud or AWS for testing using license-included models or free tiers and terminate them when they are done. This way, they pay only for short-term use without needing full licenses. That’s a pay-as-you-go approach for testing.
In summary, there isn’t a blanket “free for dev” license for Oracle Database (aside from the limited OTN developer license or free XE edition). If your dev/test environment is permanently running and used by a team, treat it as needing proper licensing, just like production. Often, companies buy enough licenses to cover production and non-prod or use lower-cost editions for non-prod if that’s acceptable. Always ensure any installed Oracle software in your organization is under a paid license or clearly under a free developer/XE usage that meets Oracle’s criteria.
How is Oracle Database licensed when using Docker containers or Kubernetes?
Running Oracle Database in Docker containers (or Kubernetes orchestration) doesn’t change Oracle’s licensing requirements – it is treated like any other installation on a server:
- Physical Host Counts: Oracle will license based on the container’s physical host (or VM) resources. Containers are considered soft partitioning. So, if you spin up an Oracle Database Docker container on a 16-core VM, that’s the same as running the database directly on that 16-core VM for licensing purposes. You’d need to license according to all cores that the container can potentially use.
- No Free Lunch with Containers: Even if you limit the container’s CPU resources (say, to 2 cores), Oracle does not automatically accept that as a license limit unless the underlying technology is an approved hard partition. Standard Docker or Kubernetes CPU limits are not recognized as hard partitions. This means unless you’re using something like an LPAR or Oracle’s zone partitioning underneath, the safest stance is to license the full host or VM where the container runs.
- Kubernetes Clusters: If you use Kubernetes and Oracle containers can move across hosts (similar to VMs on VMware), you need to license all the nodes in the K8s cluster where the Oracle container might run unless you pin the Oracle workloads to specific nodes (like using node affinity/taints to dedicate certain nodes to Oracle and license those nodes fully).
- Multiple Containers on one host: You do not need to double-count licenses if multiple Oracle containers run on the same physical host. Licensing is per host resources, not per container. For example, if you have one physical server with 8 cores and run two Oracle Database containers, you still need to license 8 (with the appropriate core factor), not 16. The containers share the same licensed compute resource.
Example: You deploy an Oracle EE database in a Docker container on a cloud VM with 4 vCPUs. By Oracle’s cloud rule, that’s 2 Processor licenses needed (just as if it were not containerized). If you use Kubernetes and have a pool of 3 such VMs where the container could run, you’d need to cover all 3 × 4 vCPUs = 12 vCPUs (which is 6 licenses in cloud terms) or constrain the Oracle pod to a specific node and license only that node.
In summary, containers do not reduce licensing requirements by themselves. Treat the deployment as if installing on the host directly. Containers have the advantages of agility and consistency, but from a licensing viewpoint, you must license the underlying servers (or VMs) where Oracle is running.
Can I run Oracle Database on Google Cloud Platform (GCP), and how is it licensed?
You can run Oracle Database on GCP using your licenses (BYOL). Google Cloud is now also considered an authorized cloud environment by Oracle, with similar rules to AWS/Azure:
- BYOL on GCP Compute Engine: Google doesn’t have an Oracle service, so you’ll be running Oracle on a VM instance. Oracle’s policy for GCP states two vCPUs = 1 Oracle Processor license (when hyper-threading is enabled, typically on GCP machines). So, the counting is essentially the same for AWS/Azure. For instance, a GCP VM with eight vCPUs would require 4 Oracle Database EE Processor licenses.
- Instance Size Limits for SE2: The same cloud instance size limits apply for Standard Edition on GCP as well (though check Oracle’s most current policy document for GCP). Generally, SE2 is limited to instances up to 8 vCPUs on GCP (similar to AWS/Azure). Up to 4 vCPUs = one socket, eight vCPUs = 2 sockets for licensing SE2. You cannot use SE2 on a large GCP instance beyond eight vCPUs.
- No Core Factor: As with other clouds, you do not use the core factor table; just apply the vCPU conversion.
- Bring Your Own License: Ensure you have the licenses available. GCP is not a license-included model for Oracle Database, so BYOL is the only route. This means you must already own Oracle licenses (or buy them) and then deploy Oracle on GCP just like you would on any VM.
- Other Considerations: Oracle and Google don’t have an official support agreement like Oracle does with Azure (Oracle has an interconnect with Azure and a partnership). So while running Oracle on GCP is technically possible and many do it, follow Oracle’s support policies (use certified OS versions, etc., because Oracle support will treat it like any other third-party cloud deployment).
Example: If you run an Oracle Standard Edition 2 database on a GCP e2-standard-4 instance (4 vCPUs), Oracle would consider that one socket, so you need 1 SE2 license. If you scale up to an e2-standard-16 (16 vCPUs), that’s beyond SE2’s eight vCPU limit, so you would need to switch to Enterprise Edition licenses for that size. For an Enterprise Edition on an n2-highmem-8 (8 vCPUs), you’d count 8/2 = 4 Processor licenses needed.
Can I move or reuse my Oracle Database licenses on new servers or cloud platforms?
In general, yes – Oracle licenses are typically perpetual. They can be reassigned to new hardware or moved to the cloud under BYOL, as long as you maintain the required support and comply with licensing rules:
- Reusing on New Servers: If you retire old hardware and deploy Oracle on a new server, you can apply your existing licenses to the new server. You should no longer be running the software on the old machine (unless you have enough licenses to cover both). Oracle licenses aren’t tied to a specific machine; they’re tied to your organization and the quantity of usage (cores or users). So, migrating from one server to another is fine. For example, suppose you had 4 Processor licenses for Server A, and you decommission A and move Oracle to Server B. In that case, you still have those four licenses to cover B – just ensure B’s core count doesn’t exceed what four licenses cover, or adjust accordingly.
- Moving to Virtual/Cloud: You can repurpose VMs or cloud instances licenses. This is exactly what BYOL is. You might assign some of your on-prem processor licenses to an AWS EC2 deployment. The key is to track license usage. Oracle expects you to be able to document which licenses are covering which environment at any given time, especially during an audit.
- One License, One Deployment (at a time): You cannot use the same licenses simultaneously in two places (e.g., using one set of licenses for an on-prem DB and a cloud DB simultaneously, unless you own enough licenses to cover both). You’d allocate the license to one environment or split them (e.g., two processors worth used on-prem and 2 in the cloud if you have four total).
- Notification/Approval: You generally do not need to inform Oracle when moving licenses (there’s no formal license transfer process if it is within the same legal entity). Just ensure your support contract is updated with any changes in hardware if required (Oracle’s support renewal might list server details, but that’s usually for your reference). If moving to a cloud, adhere to the cloud policy for counting and keep evidence that your usage matches your entitlements.
- Cloud to On-Prem: Likewise, if you BYOL to Oracle Cloud or AWS for a while and later decide to bring it back on-prem, you can do so with the same licenses. The licenses are portable if the environment is eligible (e.g., authorized cloud or your servers).
Oracle licenses are flexible enough to deploy in any eligible environment. Still, you must use them in one place at a time and not exceed the number you own. Always maintain good records (which servers/instances use which licenses) to demonstrate compliance.
Are Oracle Database management packs (like Diagnostics Pack and Tuning Pack) included in my license?
No. Management packs such as Oracle Diagnostics Pack and Oracle Tuning Pack are separate licensed products (for Enterprise Edition) – they are not included with a standard database license. Here’s what to know:
- Diagnostics Pack: Provides performance monitoring, automatic workload repository (AWR) reports, etc. To use features like AWR, ADDM, and Oracle Enterprise Manager performance pages, you need to license Diagnostics Pack. It is licensed per processor or per named user (same metric as the DB) on the databases it uses. If you’re using Enterprise Manager Cloud Control to monitor databases and enable Diagnostic Pack features for those targets, those targets must be licensed.
- Tuning Pack: Provides SQL Tuning Advisor, SQL Access Advisor, and other tuning utilities. You also need a diagnostics pack, licensed separately per processor or NUP. For instance, using the SQL Tuning Advisor triggers a requirement for a Tuning Pack license on that database.
- Not Applicable to SE2: These packs are only available for Enterprise Edition. If you run Standard Edition 2, you don’t have AWR or these advisors (SE2 uses older Statspack, etc., which doesn’t require a pack license). So SE2 users don’t pay for packs because they cannot use them.
- Other Packs: Oracle has other management packs (Data Masking pack, Database Lifecycle Management Pack, etc.), and each has its licensing requirements. None are free with the database, except that some basic functionality might be available but not full features. Always check if a feature you use is part of a separately licensed pack.
- Example: If you have a 4-core EE database (with 2 Processor licenses after core factor) and you want to regularly run AWR reports to troubleshoot performance, you need to purchase 2 Processor licenses of Diagnostics Pack (and possibly Tuning Pack if you also use the tuning advisor). Without that, technically, you are not authorized to query the AWR views or use OEM performance pages.
In summary, management packs are not included in the base database license. You must license them explicitly if you use their functionality. Be careful because it’s easy to inadvertently use them (for instance, clicking on certain performance features in Oracle Enterprise Manager). Ensure your team knows what features are tied to extra licenses.
What Oracle Database features are included with Enterprise Edition at no extra cost?
While many advanced features require separate licenses, it’s good to know which ones are included with the base Enterprise Edition (and even Standard Edition) at no additional charge:
- Data Guard (Primary/Standby automation): Oracle Data Guard (the ability to have a physical standby database and apply archive logs) is included with Enterprise Edition. You do not need to pay extra to set up a basic standby database for disaster recovery. (Active Data Guard – using the standby for queries – is the paid option, but simply having a standby in recovery mode is free with EE.)
- Basic Compression: Oracle includes some forms of data compression (like table compression for bulk loads and read-only data) in EE without the Advanced Compression option. Advanced Compression (for OLTP compression, etc.) is an extra, but you can use basic compression for certain cases with no extra license.
- Oracle Transparent Data Encryption (TDE) for Cloud: TDE is included by default for databases in Oracle Cloud environments. On-premises, TDE is part of the Advanced Security option (extra cost), but if you’re using an Oracle Database Cloud Service or Autonomous Database, you get encryption included. (This is more of a cloud service inclusion, not an EE feature per se, but it is worth noting.)
- Spatial, Graph, Machine Learning: As of Oracle 19c, Oracle made Spatial and Graph features and the Oracle Advanced Analytics (now Machine Learning) features free with Enterprise Edition (and even SE2). Previously these were separate licenses. Now you can use Oracle Spatial (for GIS data types, spatial indexes) and Oracle Graph and the machine learning algorithms in the database without additional cost. This was a big change to include more value in the base product.
- SQL Developer, APEX, and Tools: Oracle provides the SQL Developer client, Oracle Application Express (APEX), and Oracle REST Data Services free for use with the database. These aren’t exactly “database features,” but they are part of the ecosystem and come at no extra license cost.
- Multitenant (limited): In Enterprise Edition, you can have up to 3 PDBs in a CDB without purchasing the Multitenant option. This includes the capacity for consolidation.
- Parallel Query, BITMAP indexes, etc.: Enterprise Edition license includes capabilities like parallel query execution, bitmap indexing, transportable tablespaces, online index rebuilds, etc., which are unavailable in Standard Edition. These are part of EE core functionality, so no separate license is needed if you have EE.
In short, Enterprise Edition is quite feature-rich, and Oracle has gradually moved some previously paid features into EE (or even SE). Always check the latest “Oracle Database Licensing Information” manual for your version – it has a section listing which features/options are included and which require extra licensing. It’s a helpful reference to understand what you can use freely versus what triggers an additional license requirement.
Can I run multiple Oracle Database instances on one server with a single license?
Yes. Oracle’s licensing is generally per server/processor, not per instance. Suppose you have one physical server (or VM) licensed for Oracle Database. In that case, you can run multiple database instances on that machine under the same license umbrella as long as the hardware resources are covered. For example:
- Suppose you have an 8-core server and purchase the necessary Processor licenses for those eight cores (or NUP licenses for its users). In that case, you can create multiple Oracle databases or instances on that server without buying additional licenses for each instance. The license is tied to the server’s CPUs and users, not how many databases you create.
- This is common in consolidation scenarios: instead of running 10 separate servers with one database each (each needing licenses), you might run 10 databases on one big server. You then just license that one server’s processors, which can be much more cost-effective. (Be mindful if those were separate environments for different business units; you still need to have the appropriate license metric covering combined usage.)
- Named User Plus consideration: If using NUP licenses, all users across all instances on that server must be counted. But you likely have overlap (the same users may access multiple databases). You don’t count them twice. You count unique individuals or devices.
- There is no “per-instance” licensing concept for the Oracle database software itself. So whether you run one database or ten on the same machine, the license requirement is the same as long as it’s the same host. Ensure the host’s total usage (cores/users) stays within what you licensed.
- Exception – Options/Packs: If you have multiple instances and, say, one uses Partitioning and others do not, technically you’re supposed to license the Partitioning option for the whole server (all processors) regardless, since the option is installed with the Oracle binaries. In practice, if instances share Oracle software home, any option installed is considered “available” to all. Typically, you manage options at the software installation level, not per instance. Keep that in mind if mixing is used on one server.
Example: A single 4-core server (0.5 core factor) requires 2 EE Processor licenses. You can create development and test databases on that same server under those two licenses – you do not need four licenses just because you have two instances. If 50 Named Users also license you on that server, those 50 users can access any number of databases on the one licensed server. The license covers the environment as a whole, not individual DBs.
This ability to run multiple databases on one licensed server is a big reason companies opt for multi-instance or multitenant setups – it maximizes the value of the licenses they’ve purchased. Use it to consolidate where appropriate, ensuring the server is fully licensed for the load.
