Reference Guide

Dell EMC and Oracle

Database Licensing
Abstract
October 2020
Oracle database processor‑based licensing depends upon
physical processor counts, regardless of whether they are
physical or virtual platforms. This creates inherent complexities
— particularly in virtualized environments — that make it
easy for Oracle customers to unintentionally fall into costly
non‑compliance. The financial risks of getting Oracle licensing
wrong can be significant. This paper addresses and clarifies
how these rules apply to the most commonly used platforms
from Dell Technologies that run Oracle databases, including
stand‑alone servers, public cloud, SAN configurations, replicated
volumes and deployments of hyper‑converged infrastructure.

Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Table of Contents

Introduction..............................................................................................................................................................................3

Oracle database licensing.......................................................................................................................................................3

Oracle licensing metrics..........................................................................................................................................................3
Licensing documents...............................................................................................................................................................4
Server/hardware partitioning...................................................................................................................................................5
Failover data recovery.............................................................................................................................................................5
Public cloud licensing..............................................................................................................................................................6

VMware environments.............................................................................................................................................................6
Licensing.................................................................................................................................................................................6
VMware vSAN.........................................................................................................................................................................7
Certification.............................................................................................................................................................................7
Support....................................................................................................................................................................................7

Dell EMC product licensing guidance......................................................................................................................................7

Dell EMC PowerEdge servers.................................................................................................................................................7
Partitioning and licensing...............................................................................................................................................7
Server sizing guidance..................................................................................................................................................8
Storage platforms....................................................................................................................................................................8
PowerFlex (formerly VxFlex)...................................................................................................................................................8
Two‑layer.......................................................................................................................................................................9
HCI...............................................................................................................................................................................10
VxRail.................................................................................................................................................................................... 11
Storage replication................................................................................................................................................................12

Services.................................................................................................................................................................................13
LicenseFortress compliance and optimization......................................................................................................................13

Summary guidance...............................................................................................................................................................13

References............................................................................................................................................................................14
Oracle documentation...........................................................................................................................................................14
Other documentation.............................................................................................................................................................14

2 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Introduction
Underlying most systems critical to an organization’s operational success is a relational database management system
(RDBMS). While alternatives to RDBMS are emerging, the vast majority of the world’s information transactions and
interactions use RDBMS technology. Oracle produces RDBMS and line‑of‑business software that runs the core business
functions of many large organizations.

Note: For the purposes of clarity, Oracle® RDBMS software will be referred to as Oracle database software through the
rest of this document.

Why is understanding database licensing so important to most organizations? Oracle licensing policies are complex,
confusing and, if not applied correctly, very costly. Adding to this complexity, Oracle database licensing includes a wide
array of options with additional cost. Many of these options are built in to the product and are prone to unintentional use
by an unknowing administrator. This can significantly impact an organization’s operational costs by either spending too
much on database software and not optimizing the deployed databases, or facing financial penalties when an Oracle
audit or license review shows more databases in use than were licensed.

Oracle database licensing

Arriving at an accurate understanding of the Oracle licensing contract is one of the most complex exercises facing IT
professionals today. The ordering documents (order forms) contain contracts and amendments, and many of the keywords
are either defined or sometimes redefined. Oracle has a service organization called License Management Services (LMS)
that is their established authority on Oracle licensing policy. They engage customers through voluntary customer requests
and mandatory audits to measure actual usage versus the customer’s contractual entitlements. They typically work closely
with an Oracle account executive to ensure that customers are in compliance with all licensing policies.

Oracle licensing metrics

Oracle’s database licensing model is fairly standard in the software industry. Customers purchase software at an
upfront cost and pay an annual support fee, which covers patches and upgrades as well as vendor support. Oracle
requires customers to license the software regardless of business use. This includes all production and non‑production
environments, such as development, quality assurance, testing and staging, and disaster recovery.

There are two primary ways that customers license Oracle database software, which include Oracle database software
executables and binaries, Oracle Universal Installer and the OPatch utility:
• Named User Plus (NUP): Customers buy licenses based on the number of users on both human‑ and
non‑human‑operated devices, with a minimum depending on the edition or the actual number of users —
whichever is greater. (Note: NUP is only possible when the number of users can be identified and counted.)
• Processor (PROC): The processor metric is used to license all processors where Oracle database programs are
“installed and/or running.” This metric is commonly used when managing user/count populations is difficult or prohibitive.
It is the most common licensing metric for Dell Technologies commercial and enterprise customers.

While there are other versions of Oracle database, most customers purchase one of two:
• Standard Edition 2 (SE2): Oracle describes this as the starter edition for smaller environments. It is limited to servers
with a maximum of two sockets. Note that, in the case of multi‑chip modules, each chip in the multi‑chip module is
counted as one “socket.” There are no processor cores/threads limits, but the SE2 database itself will not use more
than 16 threads. In case Oracle RAC (clustering) is used on SE2, each server should not have more than one socket.
Starting from Oracle 19c, RAC is not allowed anymore on SE2.
• Enterprise Edition: There are no processor limits on this edition, but customers must license all physical cores
where Oracle programs are installed/running. This is commonly used for uncountable or hard‑to‑manage user/count
populations and is the most common licensing metric in commercial and enterprise accounts. The number of required
licenses is determined by multiplying the total number of processor cores by a core processor licensing factor (found
in the Oracle Processor Core Factor Table). Extra‑cost options available only with an Enterprise Edition license include
advanced security, data mining, label security, online analytical processing (OLAP), partitioning, spatial, the programmer
interfaces for database development and the various enterprise manager packs (change management, tuning, diagnostics
and configuration management). Customers can also choose an Enterprise License Agreement (ELA) with Oracle
where the cost is fixed over a number of years and they may install Oracle on as many servers as they wish. Many
large customers will choose this to fix the cost of their database software licensing over time.

3 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
As stated before, Oracle’s Enterprise Edition processor‑based licensing metric is the most commonly used licensing
metric with enterprise and commercial customers. In the Oracle contract, a processor is defined as “all processors
where the Oracle programs are installed/running.”

We commonly see Oracle customers license the entire physical server where Oracle is installed/running, but technically,
this processor‑based licensing metric means that a customer is only required to license the processors on that server.
Extending licensing beyond these contract terms based on a server’s participation as part of a server cluster, shared
storage or enterprise network is not required to be in compliance with Oracle database licensing.

To calculate the number of processor licenses required for purchasing Oracle Enterprise Edition, take the number of cores
(regardless of socket count or other aggregation) and multiply by the processor core factor for that processor architecture.
Generally, there is no contractual obligation to license processors beyond the physical server(s) on which the Oracle
software is installed/running.

This leads to three simple but critically important considerations of processor‑based licensing for Oracle databases:
1. You must license where Oracle programs are installed. Customers must license the database where the
ORACLE_HOME and administration directories exist. Installed does not imply the database has to be open, running
or in another state. Rather, it refers to where the binaries/program files reside on a server.
2. You must license where Oracle programs are running. If an Oracle database is running on a server, licenses are
required. This is the most common state of an Oracle database as it is open and operational for the business to use.
3. 1 and 2 apply to physical and virtual platforms. We encourage customers to review their contracts and search
for the word virtualization to determine any legal differences between Oracle licensing on physical or virtual platforms.
The same licensing guidelines apply to both physical and virtual platforms.

Licensing documents
Oracle licensing documents can roughly be grouped into two categories: binding contractual documents, and non‑binding
educational and other documents.

There is one main document that determines customer rights to use Oracle within the licensing terms. This document
is the Oracle License and Service Agreement (OLSA). Older versions of the master agreement may be called the
Software License and Services Agreement (SLSA) or Oracle License Agreement (OLA), and newer versions of the
agreement may be called the Oracle Master Agreement (OMA).

The factors that determine whether a document is binding are:

1. If it is referenced in the customers’ OLSA/OMA or other master agreement
2. If it is referenced as an amendment to the contract in an ordering document

There are three contractual Oracle documents referenced in the Oracle contract:
1. Core Processor Factor Table
2. Technical Support Policies
3. Purchase or Supporting Ordering Documents

It is important customers understand their contracts. We encourage searching for reference to these Oracle documents
in the contract.

There are also five non‑contractual Oracle documents designed to bind customers into licensing guidelines that may not
be incorporated into any contract. The five Oracle non‑contractual documents include:
1. Software Investment Guide
2. Licensing Data Recovery Guide
3. Technology Hosting
4. Partitioning Policy
5. Cloud Environment Policy

Note: We encourage customers to search their Oracle contract for references to these documents. All five Oracle
documents contain in small print, “This document is for education purposes only and provides guidelines regarding
Oracle’s policies in effect…. This may not be incorporated into any contract and does not constitute a contract
or a commitment to any specific terms.” The only change is the date for each of these documents.

4 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Server/hardware partitioning
“Partitioning” or “segmenting” is when the CPUs are physically separated into individual containers where each one acts
as a separate system. While a big reason for partitioning is to limit processor licensing costs, there are other reasons,
such as isolating operating systems (OSs) on the same server and balancing workloads across applications and users.

Partitioning is accomplished using either hardware or software virtualization technologies (like VMware), each with varying
degrees of flexibility around the CPU and memory resources allocation.
• Hard partitioning physically segments a server, separating it into distinct smaller systems, by using the partitioning
technology available on the server. Each separate system acts as a self‑contained server with unique CPUs, OS,
boot area, memory and network resources. Oracle’s stated guidance limits this ability. Oracle has approved a number
of hard partitioning technologies to limit licensing: technologies only available on Oracle hardware (e.g., Sun PDomains,
Solaris Zones, Oracle Trusted Partitions) and certain third‑party hardware (e.g., IBM® LPAR and micro‑partitions,
HPE® vPar and nPar).
• Soft partitioning segments the server’s CPU cores using software. An OS or hypervisor limits the number of CPUs
where an Oracle database is running. Examples include Oracle VM (OVM) and Oracle KVM, and VMware® vSphere®.
Soft partitioning is not approved by Oracle to determine or limit the number of Oracle processor licenses required
on a given server. Technically, a customer could license a subset of the cores on a single server if the soft partitioning
technology limits the number of cores that can be used (e.g., “CPU pinning” from VMware and OVM). However, any
event that causes the database to move to an unlicensed processor or server (as in the scenario where a virtualized
database is placed in a cluster with VMware High Availability [HA] or VMware Distributed Resource Scheduler [DRS])
and no rules exist to limit its movement, then the customer should license the processors on the unlicensed server
because the risk of Oracle binaries moving to an unlicensed server can be costly.

Oracle recognizes a practice in the industry to pay for server usage based on the number of CPUs that are turned on,
so‑called “capacity on demand” or “pay as you grow” models. Specifically, the customer is permitted to license only the
number of cores that are activated when the server is shipped. Oracle does not offer special licensing terms for server
usage models where the number of CPUs used can be scaled down or their usage varied, so‑called “pay per use” or “pay
per forecast” models. A customer cannot disable cores after purchase on a fully licensed server as a way to limit Oracle’s
licensing guidelines.

It should be noted that all the information above is detailed in the Oracle Partitioning Policy which is an educational
document only and is not referenced in any way in the OLSA/OMA contractual document. Customers should proceed with
caution with any partitioning strategy and ensure that the “installed and/or running” definition of Oracle database binaries
is not being violated.

Failover data recovery

Some customers may be licensed for failover data recovery as part of a business continuity or disaster recovery solution.
Failover data recovery environments are deployed in a clustered environment where multiple servers have access
to a single storage‑area network (SAN). In these cases, customers may be eligible for an exception in Oracle’s standard
processor licensing metrics which allows for one unlicensed server/node in a clustered environment sharing single
storage. This so‑called “10‑day rule” allows Oracle databases to be installed and/or running on one unlicensed failover
node up to 10 separate (not necessarily consecutive) 24‑hour periods in a calendar year. If failover periods exceed
10 separate periods, the processors on the failover node must be licensed. When the primary node fails, the failover
node acts as the primary node. Once the primary node is repaired, the customer must switch back to the primary node.

The same license metric must be used for production and failover nodes, and options must match the number of licenses
of the associated database. From the language above, it seems that this would preclude a customer using the 10‑day
rule for remote failover data recovery environments. Dell Technologies partner House of Brick has documented variations
on what is allowed for this rule at various customers: “Older OLSAs do not restrict the location of the unlicensed server.
Newer versions, however, state that the licensed and unlicensed hosts have to share storage, thus making the remote
site (failover data recovery) option impossible. There are further restrictions (such as only one designated failover server
allowed per cluster), so be sure to review the terms of your contract for the 10‑day rule.”

Oracle Data Guard is a form of replication specific to Oracle database software. It is used to maintain a standby copy
of an active database. It requires Oracle software to be running at both the primary and standby locations. Therefore, this
form of replication requires licensing of both the primary and the standby locations and the 10‑day rule would not apply.

5 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
For data recovery environments using remote mirroring or replication of the data and/or the Oracle database binaries,
only in the case where the mirrored or replicated binaries are installed and/or running on a remote node/server must those
processors be licensed.

It should be noted that all the information above is detailed in the Oracle Data Recovery Environments Policy, which
is an educational document only and is not referenced in any way in the OLSA/OMA contractual document. Customers
should proceed with caution with any failover and recovery strategy and ensure that the “installed and/or running”
definition of Oracle database binaries is not being violated.

Public cloud licensing

Currently, only Amazon Web Services® (AWS) EC2 and RDS, and Microsoft® Azure® are authorized by Oracle for running
Oracle databases on non‑Oracle public cloud.

For the purpose of licensing on non‑Oracle public cloud, customers are required to count their processors or virtual CPUs
(vCPUs) as follows:
• Count two vCPUs equivalent to one Oracle processor license if hyper‑threading is enabled.
• Count one vCPU equivalent to one Oracle processor license if hyper‑threading is not enabled.
• The core factor table does not apply when licensing the Oracle database for non‑Oracle clouds so customers cannot
use the hardware multipliers to limit license costs.

It should be noted that all the information above is detailed in the Oracle Software in the Cloud Policy, which is an
educational document only and is not referenced in any way in the OLSA/OMA contractual document. Customers should
proceed with caution with any public cloud strategy and ensure that the “installed and/or running” definition of Oracle
database binaries is not being violated.

VMware environments
VMware is the market leader in hardware virtualization. Its software allows organizations to reduce hardware‑related
costs and improve operational efficiencies in their IT environment by abstracting physical hardware and allowing
flexible consumption of compute, network and storage. However, customers deploying Oracle database using VMware
virtualization technology can unintentionally put themselves at risk of non‑compliance of core‑based licensing due
to the licensing complexities associated with virtual machines (VMs). Understanding these complexities is critical
to remain complaint and reduce financial and operational risk.

Licensing
Note: The following section is intended to summarize VMware’s licensing guidance on Oracle database and is not
intended to replace or change that guidance.

As stated previously, Oracle processor‑based licensing metrics involve properly accounting for physical processor
counts. Oracle does not have a separate licensing policy for virtualization deployments of Oracle database software for
on‑premises licensing. VMware vSphere enables you to consolidate multiple workloads in the form of VMs on a single
physical host. Additionally, VMware enables you to move these VMs across hosts with VMware vSphere vMotion®, DRS
and HA. For this reason, the critical consideration when running virtualized Oracle databases on VMware is controlling
what physical hosts the database is installed or running. Per VMware, when running any products with license metrics
that involve physical processor counts on vSphere, customers should ensure the following:
• VMs are running on processor cores fully licensed for Oracle.
• VM movement is restricted to hosts that are fully licensed for Oracle.
• VM execution and interhost movements are tracked so that customers are able to demonstrate compliance with
Oracle’s requirements.

6 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Customers should validate that any design limits the ability of any server node to read Oracle binaries (i.e., the
ORACLE_HOME directory) where Oracle is not required or desired to run. With this in mind, customers running
Oracle databases in a vSphere virtual infrastructure can take advantage of VMware features to manage what
physical hosts on which the Oracle database software can run, specifically:
• Affinity rules: Applied to VMs to specify the physical hosts on which the VMs can run. Many customers use affinity
rules for licensing compliance to ensure VMs only use licensed hosts. A VM migrating to a non‑licensed host will result
in a compliance gap.
• Anti‑affinity rules: Applied to VMs to keep them apart. A common method is to reserve compute, memory and storage
for production databases to ensure consistent performance and prevent VMs from using the same resources.

VMware vSAN
VMware vSAN™ pools storage from multiple servers and/or locations into a virtual SAN volume. Since there is no
Oracle licensing obligation for SAN controllers (see section: Storage platforms) even if that SAN volume contains
the Oracle binaries, vSAN does not have any direct Oracle database licensing implications.

vSAN runs within vSphere’s ESX® kernel and is considered to be a virtual SAN controller. Even though ESX or VMware
ESXi™ is running on x86 hardware, it is not capable of running Oracle database software. Oracle software in a virtual
machine disk (VMDK) does not qualify as being installed/running unless there is a guest VM attached to the VMDK that
can execute Oracle’s software. In that case, the attached host VM would need to be licensed.

For more detailed information, please see Dell Technologies partner House of Brick’s white paper on Oracle licensing:
Licensing Databases on EMC and VMware Technology.

Certification
It is important to note that Oracle does not certify any third‑party infrastructure elements below the OS. Similarly, Oracle
doesn’t certify virtual hardware platforms since those are technically below the OS as well. The exception here is that
Oracle does officially certify its own Oracle virtualization platforms. Regardless, the lack of certification of hardware —
be it virtual or physical — is not something that prevents Oracle databases from running or ultimately being supported.

Support
In September 2019 at Oracle Open World, Oracle and VMware entered into a strategic alliance, enabling customers
to run VMware Cloud Foundation™ on Oracle’s Generation 2 Cloud infrastructure (Oracle’s public cloud). As part
of the agreement, Oracle now officially supports Oracle deployments on VMware, whether part of a hybrid cloud strategy
or fully deployed in a public cloud. Oracle will support customers with active support contracts running supported versions
of Oracle products in Oracle‑supported computing environments on VMware. This announcement removes a significant
hurdle often encountered when discussing Oracle and VMware and Dell server‑based solutions with customers.

Note that Oracle supported VMware before but with some restrictions and requirements — notably having to move back
to bare metal in case of certain issues. For more info, see the full announcement here: Oracle and VMware Partner
to Support Customers’ Hybrid Cloud Strategies.

Dell EMC product licensing guidance

The following sections describe specific licensing guidelines for products where Oracle database licensing has an impact.

Dell EMC PowerEdge servers

Partitioning and licensing
In any stand‑alone PowerEdge server configurations, customers must license all cores where the database software is
installed/running. Recall that Oracle does allow for the “pay as you grow” licensing model, and since PowerEdge servers
allow the customer to disable cores in the BIOS at the time of shipment, customers may do this to limit the initial licensing
spend. However, if the customer enables additional cores in the future, they must license that number of cores and may
not disable the cores with something like Dell Processor Acceleration Technology (DPAT) as a way to limit licensing.

7 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Note: With PowerEdge servers as part of a Dell Technologies engineered system like PowerOne, PowerFlex or VxRail,
disabling cores in the BIOS setting is not supported, so the customer must fully license all cores on the servers where
Oracle database software is installed/running.

Server sizing guidance

Dell EMC PowerEdge 940 4‑socket servers are increasingly considered by customers as they look to adopt more
powerful servers to address increasingly demanding workloads. Customers should carefully evaluate whether the
workload requires the additional cores in a 4‑socket server over a 2‑socket server since they must fully license all
cores on the servers where Oracle database software is installed/running.

A general rule of thumb is that most Oracle transactional workloads require relatively low core counts with higher
processor clock speed for a higher performance/core. Certain analytic and in‑memory database workloads that require
both higher core count and larger RAM capacity (including Intel® Optane™ DC), and those may benefit from 4‑socket
servers. In all cases, the customer should carefully evaluate the licensing cost and performance for each server
to ensure compliance.

Storage platforms
For all Dell Technologies storage solutions (PowerMax, Unity, XtremIO, PowerStore T), the following licensing guidance
applies. There is no Oracle licensing obligation for SAN controllers as outlined by Oracle’s own licensing documents,
even if that SAN volume contains the Oracle binaries. To illustrate, recall the Oracle contract’s “installed and/or
running” language. For an Oracle database to be “running,” a CPU must be executing the Oracle database code.
Dell Technologies’ storage technologies are SAN controller technologies. Despite having an OS, they cannot run Oracle
database software.

To be considered “installed,” Oracle database software executables would have to be installed on that platform and that
would require:
1. A booted OS that supports running Oracle software executables
2. A mounted file system visible to the OS

Therefore, the presence of Oracle software in a SAN volume does not qualify as being installed/running unless there is a
server attached to the SAN volume that can execute Oracle’s software. In that case, the server would need to be licensed.

PowerStore X models provide the ability to run applications directly on the storage system due to the embedded VMware
ESXi hypervisor running the PowerStore X model nodes. Simultaneously, it can also be used as a standard external
storage array, providing block volume access to servers like the PowerStore T model. Customers should consider
VMware’s licensing guidance when running virtualized Oracle databases on VMware environments on this model.
Specifically, customers only need to license the processors on VMware ESXi nodes where the database software
is installed/running.

If the database moves to an unlicensed ESXi server node (as in the scenario where VM database is placed in a cluster
with VMware HA or DRS) and no rules exist to limit its movement, the customer should license the applicable ESXi server
because the risk of Oracle binaries moving to an unlicensed server can be costly. Using software like VMware host affinity
and anti‑affinity rules limits what ESXi host the databases can run and can mitigate this risk.

PowerFlex (formerly VxFlex)

PowerFlex family is a hyper‑converged infrastructure (HCI) meaning storage, network, virtualization and unified
management are tested and integrated into one unit. The central software layer for PowerFlex family is PowerFlex OS
(formerly VxFlex OS), a scale‑out block storage service that enables customers to create a scale‑out server SAN or HCI.
With this solution, any hypervisor or bare‑metal server‑based solution can access this virtual SAN. The PowerFlex family
currently include PowerFlex Ready Nodes, PowerFlex appliance and PowerFlex integrated rack.

PowerFlex applies the principles of server virtualization to standard x86 servers with local disks, creating high‑performance,
shareable pools of block storage. It abstracts the local storage contained within each server, including HDDs, SSDs and
all‑flash. To implement this, it uses three lightweight pieces of software to create, consume and coordinate the storage
layer in PowerFlex systems: storage data client (SDC), storage data server (SDS) and a metadata manager (MDM).

PowerFlex can be deployed in one of two ways, and each has different implications for Oracle licensing. Note: It can also be
deployed in a hybrid configuration where deployments can mix the two‑layer and HCI deployments in separate enclosures.

8 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Two‑layer
In a two‑layer (storage‑only) deployment, compute resources exist on one set of nodes, and storage resources exist
on another. PowerFlex nodes leverage PowerFlex OS to virtualize the server’s direct‑attached storage (DAS) into
a shared network‑based storage pool similar to SAN storage. This is a similar structure to traditional SAN.

The licensing of only database software applies to the compute nodes and not the storage nodes since they are incapable
of running database software without an OS. The smallest unit that can be licensed for database software will typically
be a single compute node. For the compute nodes, customers can virtualize with servers using a supported virtualization
technology like VMware, or they can use bare‑metal servers.

Figure 1 illustrates a PowerFlex two‑layer implementation that has four storage (SDS) nodes and three compute (SDC)
nodes. The storage layer uses PowerFlex to create a virtual SAN on four Red Hat® Enterprise Linux® (RHEL) nodes,
and since Oracle database software is not installed here, these nodes do not need to be licensed.

The compute nodes have been virtualized by vSphere on three nodes. In this example, three Oracle VMs are created
to virtualize the three Oracle RAC nodes and are installed on ESXi servers 1 and 2. As long as these VMs do not move,
the customer only needs to license the processors on those two nodes.

If the database moves to ESXi server 3 (as in the scenario where VM database is placed in a cluster with VMware HA
or DRS) and no rules exist to limit its movement, then the customer should license the third ESXi server because the risk
of Oracle binaries moving to an unlicensed server can be costly. Using software like VMware host affinity and anti‑affinity
rules limits what ESXi host the databases can run and can mitigate this risk.

PowerFlex: Two-layer

vCenter Storage volumes

Oracle RAC

VM1 VM2 VM3

Oracle RAC node 1 Oracle RAC node 2 Oracle RAC node 3 Vol 1 Vol 2 Vol 3 Vol 4 Vol 5

Database instance 1 RAC Database instance 2 RAC Database instance 3

Interconnect Interconnect
Protection domain
Oracle Clusterware +ASM1 Oracle Clusterware +ASM2 Oracle Clusterware +ASM3

RHEL OS RHEL OS RHEL OS Storage pool

VMware vSphere hypervisor

PowerFlex OS

ESXi 1 ESXi 2 ESXi 3

SDC SDC SDC

RHEL/SDS RHEL/SDS RHEL/SDS RHEL/SDS

Figure 1: Oracle Enterprise Edition on PowerFlex OS two‑layer

For Oracle database, Dell Technologies usually recommends the two‑layer implementation as it enables the physical
implementation of databases with software‑defined storage while limiting the risk of database moving to unlicensed
storage nodes. Customers can add additional SDS storage nodes without impacting database licensing, and it allows
independent scaling of Oracle compute and server resources as in a traditional SAN. Some other benefits include:
• Creates a flexible foundation for delivering infrastructure as a service (IaaS) at scale
• Makes it easy to deliver massive performance at extreme scale
• Supports bare metal and multiple hypervisors

9 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
HCI
PowerFlex HCI applies the principles of server virtualization to standard x86 servers’ local disks, creating high‑performance
shareable pools of block storage. In HCI, all server nodes provide and consume storage and participate in the cluster
as a server:
• Each node acts like a SAN controller, providing access to attached physical disk drives that are pooled into the total
storage for the system via PowerFlex OS.
• Each node also can be used as an independent server or, if the application is virtualized as with VMware vSphere,
an ESXi host.

Figure 2 illustrates a PowerFlex HCI implementation that has four SDS/SDC combination nodes. PowerFlex is used
to create a virtual SAN on all four nodes. The compute nodes have been virtualized by vSphere in this example on the
same four nodes. In this example, four Oracle VMs are created to virtualize the four Oracle RAC nodes and are installed
on ESXi servers 1, 2 and 3.

As long as these VMs do not move, the customer needs to license the processors on only those three nodes. If the
database moves to ESXi server 4 (as in the scenario where the VM database is placed in a cluster with VMware HA or
DRS) and no rules exist to limit its movement, then the customer should license the fourth ESXi server because the risk
of Oracle binaries moving to an unlicensed server can be costly. Using software like VMware host affinity and anti‑affinity
rules along with creating a virtual LAN (VLAN) limits what ESXi host the databases can run and can mitigate this risk.

PowerFlex: HCI

vCenter

Oracle RAC

VM1 VM2 VM3 VM4

Oracle RAC node 1 Oracle RAC node 2 Oracle RAC node 3 Oracle RAC node 4

Database instance 1 RAC Database instance 2 RAC Database instance 3 RAC Database instance 4

Oracle Clusterware +ASM1 Interconnect Oracle Clusterware +ASM2 Interconnect Oracle Clusterware +ASM3 Interconnect Oracle Clusterware +ASM4

RHEL OS RHEL OS RHEL OS RHEL OS

Protection domain

Shared VMFS datastore

Storage pool

PowerFlex OS

VMware vSphere hypervisor

ESXi 1 ESXi 2 ESXi 3 ESXi 4

SDS/SDC SDS/SDC SDS/SDC SDS/SDC

Figure 2: Oracle Enterprise Edition on PowerFlex OS HCI

PowerFlex HCI can be a cost‑effective and efficient means of implementing Oracle for those customers whose workloads
are not CPU‑constrained. Because the both storage and compute share the same node, customers should ensure
licensing considerations are carefully considered. Other benefits include:
• Manageability: Set up, manage and provision storage easily
• Lower TCO: Deploy storage using inexpensive local server storage such as DAS all‑flash

10 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
VxRail
VxRail is a fully integrated, preconfigured and tested HCI appliance powered by VMware vSAN technology for
software‑defined storage. Managed through the VMware vCenter Server® interface, VxRail provides a familiar
vSphere experience that enables streamlined deployment and extended use of existing IT tools and processes.
VMs running Oracle software use the compute power of the ESXi servers in the vSAN/VxRail cluster, just as with
a classic vSphere cluster.

In this sample VxRail scenario, the servers share storage across all four nodes by way of vSAN (Figure 3). The compute
nodes have been virtualized by vSphere on the same four nodes. Two Oracle VMs are created to virtualize the two
Oracle RAC nodes and are installed on ESXi servers 1 and 2. As long as these VMs do not move, the customer needs
to license the processors on only those two nodes. If the database moves to ESXi server 3 or 4 (as in the scenario where
VM database is placed in a cluster with VMware HA or DRS) and no rules exist to limit its movement, then the customer
should license the third and fourth ESXi server because the risk of Oracle binaries moving to an unlicensed server
can be costly.

Customers can use software tools like VMware host affinity and anti‑affinity rules, along with creating a VLAN to segment
and confine where the Oracle database software is running. Auditing tools, such as VMware vRealize® Log Insight™ can
ensure that Oracle cannot or has not migrated across the cluster to an unlicensed host.

VxRail

vCenter

Oracle RAC

VM1 VM2 VM3 VM4

Oracle RAC node 1 Oracle RAC node 2 Application node 1 Application node 2

Database instance 1 RAC Database instance 2 RHEL OS RHEL OS

Oracle Clusterware +ASM1 Interconnect Oracle Clusterware +ASM2

RHEL OS RHEL OS

Protection domain

Shared VMFS datastore

Storage pool

VMware VSAN

VMware vSphere hypervisor

ESXi 1 ESXi 2 ESXi 3 ESXi 4

SDS/SDC SDS/SDC SDS/SDC SDS/SDC

Figure 3: Oracle Enterprise Edition on VxRail

11 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Storage replication
As has been established, the mere presence of Oracle software in a SAN volume (or VMware VMDK) does not qualify
it as being “installed and/or running” unless a server or guest is attached that could run it. In that case, the server
(or host where the VM resides) is what must be licensed.

When SAN volumes are replicated, the replica is not typically available at the remote site until it is presented to a physical
or virtual host. As such, replicated volumes cannot contain “installed” software by Oracle’s definition (see Figure 4). Also,
replicating any form of customer data, including Oracle data files and/or archived redo, does not constitute licensable
activity. If the customer were to mount those binaries and run them at the secondary location, they would become
“installed” and then be subject to Oracle’s licensing metrics.

Storage replication

Production

Oracle node

Database instance

Oracle Clusterware +ASM

RHEL OS

Host

All replicated files are not mounted

and cannot be seen by a host.

Storage replication
Vol 1 Vol 2 Vol 3 Vol 4 Vol 5 Vol 1 Vol 2 Vol 3 Vol 4 Vol 5

PowerMax PowerMax

Figure 4: SAN/Storage volume replication

For a VMware‑virtualized environment, a solution like Dell Technologies RecoverPoint for VMs is a form of replication.
It replicates VMDK files associated with a VM from one vSphere data store to another. While being replicated, VMDK
files are not available to be used by VMs at the secondary location. For that reason, even if they contain licensed binaries,
replicated disks cannot be considered to contain “installed” software by Oracle. As in SAN replication, if the customer
mounts those binaries and runs them at the secondary location, they become “installed” and then subject to Oracle’s
licensing metrics.

12 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
Services
For most of our customers who have a processor‑based licensing agreement, the complexities and financial risks
posed by getting the licensing wrong — whether in a VMware‑virtualized Oracle database environment or not — can
be significant. Dell Technologies offers a number of services both directly and through our partners that can help the
customer manage that risk.

LicenseFortress compliance and optimization

Adding services from Dell Technologies partner LicenseFortress is an excellent defense against Oracle’s licensing and
auditing practices. LicenseFortress helps customers achieve the greatest savings and restores confidence in the proper
way to license Oracle on Dell Technologies products and solutions.

LicenseFortress performs Oracle software audits, aids in licensing negotiations with Oracle and provides monitoring
solutions to prevent license compliance issues. In addition, LicenseFortress provides a financial guarantee with their
service at the highest level. If they tell the customer they are in compliance and the customer is audited and it is deemed
by a court of law that LicenseFortress provided bad advice, they pay for any additional Oracle licenses that were needed.

The specific offering is called LicenseFortress Compliance and Optimization Review. The solution provides robust review
of customer OLSA(s) automatically catalogued through LicenseFortress. Discovery is used to create an Effective License
Position (ELP). The final report (COR Report) details products and/or features that are the root of compliance issues
or could be better optimized.

LicenseFortress Compliance and Optimization Review is currently an OEM solution bundle that can be sold directly
or indirectly by Dell Technologies. Contact [email protected] for more details on how to engage this service.

Summary guidance
Oracle database licensing can be confusing, particularly in virtualized environments where there is changing infrastructure
and scaling. Above and beyond Oracle’s processor metrics, there are also software options within the Oracle database
product that can incur additional licensing costs.

While Dell Technologies can offer guidance on compliance issues, there could be occasions where you’ll need to assist
your customer in understanding their licensing obligations. Here are a few guidelines to help your customer prepare:
• Be prepared by knowing the contract. The previous section details documents that are and are not referenced
in Oracle contracts. Listen for any mention of these documents. Question whether they are referenced in existing
contracts. Evaluate whether if the discussion applies to how your customer’s business has licensed the database.
• Know who to talk to. It’s best for the customer to have a strong understanding of their contract before engaging Oracle
on any questions about database licensing. For all contractual‑licensing discussions, the single source of truth will be
Oracle LMS. Other Oracle professionals, including account executives and customer support representatives, might
sound official and even use “legalese” but are not the final authority on customer licensing obligations.
• Get assistance. There are Dell Technologies partners, such as LicenseFortress, that specialize in partnering with
customers in licensing discussions and audits. These Oracle licensing experts understand the entire process of
negotiations, can inform customers what to expect from Oracle and will advocate on your behalf so your business
receives the best outcome.

13 | Dell EMC and Oracle Database Licensing

© 2020 Dell Inc. or its subsidiaries.
References

Oracle documentation
• Oracle Database Licensing Policy
• Oracle Partitioning Policy
• Oracle Software in the Cloud Policy
• Oracle Processor Core Factor Table
• Oracle Data Recovery Environments Policy
• Oracle License Management Services

Other documentation
• VMware: Understanding Oracle Certification, Support and Licensing for VMware Environments
• House of Brick: Licensing Databases on EMC and VMware Technology
• LicenseFortress: Subscriptions and services

Learn more Contact a Dell  View more

about Dell solutions Technologies Expert resources

© 2020 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks
of their respective owners. Reference Number: H18539

Oracle® is a registered trademark of Oracle and/or its affiliates. VMware® products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware®
is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. IBM® is a registered trademark of International Business Machines
Corporation in the United States, other countries, or both. HPE® is a registered trademark of Hewlett Packard Enterprise Development LP and/or its affiliates. Amazon Web
Services® is a trademark of Amazon Services LLC and/or its affiliates. Microsoft® and Azure® are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries. Intel® and Optane™ are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Red Hat® is a registered
trademark of Red Hat, Inc. in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Dell Technologies believes the information in this document is accurate as of its publication date. The information is subject to change without notice.