Oracle Processor Licenses: Cluster Optimization Report

IT Asset Management (Cloud)

The Oracle License Optimization on Clusters report applies to consumption of exclusively Oracle Processor licenses on:

• Computer clusters where Oracle Processor licenses may be consumed (and therefore currently excluding Kubernetes clusters); with special focus on VMware clusters, and Oracle clusters managed without core affinity, because the Oracle licensing rules for these "soft partitioning" environments allow for substantial savings through cluster optimization
• Stand-alone ESX hosts (not in a cluster)
• Other stand-alone virtual hosts.

Tip: Although Oracle Database Standard Edition uses an Oracle Processor license, it uses an atypical socket count for consumption calculations, and is therefore excluded from this report. All other editions of Oracle Database inventoried in your environment are included in the report.

VMware clusters (and some others) use "soft" partitioning, meaning that a given virtual machine (VM) can potentially migrate from host to host within a cluster, or (from vCenter 5.0 and later) migrate from one cluster to another, or even (from vCenter 6.0 and later) from one entire data center to another. Given that Oracle's standard license agreements require that every potential virtual host must be licensed (and that the list price for a single processor/two core license authorizing Oracle Database Enterprise Edition runs to US$47,500 at release time), this means that identifying risks and areas for cluster optimization is financially critical, despite it being very complex.

Tip: Although in principle Oracle Processor licenses have maximum "reach", in practice the boundary for soft partitioning is often determined by commercial negotiations. Many enterprises, even some using versions later than vCenter 5.0, manage to negotiate a boundary at the cluster level. This makes optimization of the clusters critically important for controlling the liability/spend on Oracle Processor licenses.

While this report must handle the complexity of Oracle Processor licensing (and therefore provides a great depth of information), careful reading can help you answer questions like these:

• Is our virtualization structured in an optimal way for Oracle Processor licensing?
• Are our Oracle options deployed consistently across clusters? What would be our optimum target architecture for our clusters to best manage those costs?

This report highlights ways you can optimize software locations from the "root" level, which is either the cluster, or a stand-alone virtual host. It empowers you to reduce your liability by collecting together your Oracle Database instances that have the same sets of options installed and used, and hosting their VMs on carefully-sized clusters. As you move instances (and options) from one cluster to another optimized one, re-run the report to see the changes in exposure or savings.

Formula for calculating the optimization value per license

Formula: Over_UnderSpent = (LicensesConsumed – (ISNULL(VMInstalledCores, 0) × Factor)) × PurchasePrice

(Host-level type) LicensesConsumed: 5 VMInstalledCores: 12 Factor: 0.75 PurchasePrice: $5,000 Calculation: (5 – (12 × 0.75)) × 5,000 = (5 – 9) × 5,000 = –20,000 Interpretation: The higher count for total host cores (16) results in 12 processor licenses (16 × 0.75). However, only 5 licenses are consumed, often indicating an LPAR (either dedicated or shared pools). The negative value ($–20,000) reflects savings achieved by optimizing the use of fewer physical cores.

(Host-level type)

• LicensesConsumed: 5
• VMInstalledCores: 15
• Factor: 0.75
• PurchasePrice: $5,000

Calculation:

(5 – (15 × 0.75)) × 5,000 
 = (5 – 11.25) × 5,000 
 = –31,250

Interpretation:

The total host cores count of 16 again results in 12 processor licenses (16 × 0.75). License consumption shows only 5 used, typically indicating an LPAR (dedicated or shared pools).

The negative value ($–31,250) reflects even greater savings from optimizing physical core usage.

More VM cores run Oracle Advanced Compression within the same LPAR, consuming only 5 Oracle Processor Licenses, further increasing the achieved savings.

Generating the report

Note: This report is scoped to the data that each operator is entitled to see, according to their access rights. While an administrator can see all available licenses, clusters, consumption, and optimizations, another operator who has access rights restricted to EMEA sees only those elements linked to the EMEA location, and to any of its child locations.

1. Go to the Oracle License Optimization on Clusters page (Reporting > License Reports > Oracle License Optimization on Clusters).
2. Click Run report to display the results for all known cases of software running in vCenter clusters, or on stand-alone virtual hosts, and licensed with Oracle Processor licenses.

Reading the report

The following columns (listed alphabetically) are available.

Cluster/Host name

Depending on the architecture deployed, this is either:

• The path in the virtualization hierarchy to the cluster (in the form of domain/clustername)
• The host name of the stand-alone virtual host.

Cluster names and host names are not forced to be unique, although giving them unique names is best practice. If you need to differentiate between (for example) two clusters with the same name, check the hosts and instances.

Consumed

Tip: Notice that this is the total consumption for the entire license, as shown on the Compliance tab of the license properties (and calculated as described below). This figure may well be greater than the consumption on the current cluster/host shown in this row of the report, depending on how many other installations of Oracle products on other devices are also linked to the same license.

The total points consumed for this license, derived by the required complex method:

1. Processors are grouped together by their points factors.
2. Within each group, the cores (available on a host, or assigned for a VM) are added up.
3. For each group, total cores x points/core (from the points table) is calculated.
4. Any fractional result in each group is rounded up.
5. The whole-number subtotals from each group are summed to get the total Consumed.

Consuming instances

A comma-separated list of the Oracle Database instances installed on devices (including VMs) that are linked to the license in this row. Each entry has three parts:

• The device name where the instance is running (most often the name of a VM)
• The number of cores assigned to the VM, or available in a free-standing device running the instance
• In parentheses, the name of the Oracle Database instance. Where there are multiple database instances running on the same device, this displays a comma-separate list of instances within the parentheses.

Examples:

vm-oem13-01 6 Cores (ORCLEM)

Here the database instance called ORCLEM is running on the VM called vm-oem13-01, where 6 cores are assigned.

vm-orcl18-03 4 Cores (CDB_ROOT, CDB_TEST, CDB_PROD), 
vm-orcl19-01 4 Cores (kleanthes_ROOT)

The license in this row is authorizing 4 database instances across 2 VMs, each of which is assigned 4 cores.

Consuming VM cores

For virtual machines where the installed software is consuming from the license in this row, this is the sum (across the cluster or the virtual host, as appropriate for Type) of the hosts' cores assigned to each of the relevant VMs.

Cost per point (currency)

The unit cost per processor point for the current license, which is the first available of:

• The Amount field on the Financial tab of the license properties.
• The Override unit price shown in the Purchases tab of the license properties
• The most recent Unit price in software purchases attached to the license
• The arbitrary default value shown in Default cost per point (currency), allowing the report to show the impacts of exposure and optimization where no real data is available.
  Remember: It is best practice to always set a realistic value in the license properties, and avoid the appearance of this default.

Default cost per point (currency)

For those licenses where no unit price is available, this displays the arbitrary default value used in calculations of 5000. This means that, in rows where this value is displayed, best practice says that you should attend to the license shown in this row, and either add purchase(s) that set the Unit price, or manually set the Override unit price on the license.

License name

The Oracle Processor license from which the devices in this row are consuming. The License name is editable in the Identification tab of the license properties.

License type

The kind of license, which determines what properties are available for the license, and how compliance is calculated for the license. For details of an individual license type, please see the appropriate entry in the glossary.

Editable in the License type field in the Identification tab of the license properties.

Note: For this report, the License type always displays Oracle Processor.

Optimization value (currency)

The savings coming from an optimal structure of the vCenter clusters within your enterprise. This figure may be:

• Positive, meaning that this is a potential saving yet to be realized, and requiring a restructuring of your vCenter clusters
• Negative, meaning that this is a saving already achieved because of appropriate configuration of your vCenter clusters.

Note: The following text explains cluster types and soft partitioning in VMware environments. If a host provides more cores than the clusters/LPAR running the VMs, it is considered optimized.

This saving is based Oracle's requirement for soft partitioning that, if any VM within a cluster has Oracle Database or any related Oracle option installed, then all ESX servers in the cluster must be fully licensed for the same software. Typically, this requires licensing every core on the stand-alone host, or the sum of all cores on all hosts in the cluster. The saving relies on restricting installation of Oracle software to tightly 'focused' clusters/LPAR that have the minimum number of virtual hosts (and cores) to provide database services to other client systems. The saving is then the difference between licensing all cores in your current cluster/host, and licensing fewer cores in a minimized and tightly bounded cluster/LPAR. Experiment by moving installations of Oracle product, and re-running the report to identify changes, especially in this Optimization value.

Purchased

Tip: Be clear that this figure is not limited to purchases made for the current cluster/host shown in this row.

The total number of license entitlements recorded for this license. This is the sum of the Entitlements from purchases and Extra entitlements values stored in the properties of the license. This is the number of license entitlements your enterprise is entitled to consume.

Shortfall/Availability

The mathematical difference between the Purchased and Consumed values for the overall license:

• A positive number means you have surplus entitlements
• A negative number means you are under-purchased, and exposed in the event of an audit
• A zero means that consumption exactly matches purchases.

Total consumed for cluster/host

The mathematical sum of all the points consumed for devices within this cluster, or for VMs on this virtual host. (In general, this is often less than the value for Consumed, which covers the entire license rather than just the cluster/host in this row.)

Total host cores

The value depends on the Type of deployed architecture described in this row:

• For a Cluster, this is the sum of all cores in all virtual hosts found within the cluster
• For a Host, this is the total number of processor cores available in the hardware.

Type

The kind of installed architecture displayed in this row, identified by its 'root' element:

• Cluster for a cluster with hosts where VMs are consuming Oracle Processor licenses
  Remember: At the time of this release, Kubernetes clusters are not managed for license consumption.
• Host, such as a stand-alone ESX host, IBM host, or other virtual host.

Value consumed for cluster/host (currency)

The monetary value of the total consumption of license points across this cluster (or for VMs on this virtual host). This is the simple multiple of Total consumed for cluster/host times the Cost per point (currency).