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.

Calculating the Optimization value

An important column in this report shows a calculated Optimization value, which may be a positive amount that you can potentially save by restructuring your clusters, or a negative amount that you have already saved. The value is derived like this:

Start with the current core count in host devices within the relevant cluster (shown in the same row as the license under Total host cores). Because of Oracle's licensing rules for "soft partitions", this is the number of cores that should be licensed to cover for possible migrations within the cluster.
Identify the total cores in an optimized infrastructure – that is, moving all Oracle Database products and options into one (or more) smaller clusters with a different count of cores overall.
Calculate the difference between these two core counts.
Multiply the core count difference by the Oracle points factor found in the points table attached to the license (in the Identification tab of the license properties, see the Points rule set and click the folder icon next to its name to open the points rule set properties; and there, select the Points rules tab and identify the applicable rule(s) and the points factor(s) defined there – keep in mind that, in values shown in this report, the appropriate points factor has been chosen for each host, so that if your cluster is not homogeneous, selecting the relevant points factors for each different kind of host can get time-consuming).
Multiply the resulting points difference by the cost per point (shown in Cost per point, or if that value is missing, see Default cost per point). The result is the potential (or realized) saving through optimizing your clusters (or other deployment infrastructure).
Tip: A 'realized' saving means that you have already updated your deployment infrastructure, and the count of cores related to these Oracle products is now different from the total cores in the currently-listed cluster. By optimizing your infrastructure, you may avoid the need to acquire more licenses. As well, if your optimized infrastructure requires significantly less license entitlements than you already own and for which you currently pay maintenance, you may decide to reduce your maintenance coverage and give up the corresponding surplus perpetual rights, in line with the Oracle licensing rules.

Here are two worked examples, assuming there is just one VMware cluster where installed software consumes from the one related license:

Step	Case for potential saving	Case for realized saving
Total cores of all hosts in cluster	80	80
Optimize installations onto	One VM with 2 cores	45 VMs with 2 cores each
Optimized core count	2	90
Total cores less optimum cores	78	-10
Oracle points factor (say)	0.5	0.5
Difference in points	39	-5
Example cost per point	US$23,750	US$23,750
Saving	US$926,250	-US$118,750

In the second case, Oracle charge for the 80 cores available in the hosts within the cluster, and their license is capped at that number of cores; but the suggested optimization allows for time-sharing the cores across VMs so that the optimized usage gives a theoretically increased core count.

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.

Go to the Oracle License Optimization on Clusters page (Reporting > License Reports > Oracle License Optimization on Clusters).
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.

Column name	Description
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: Processors are grouped together by their points factors. Within each group, the cores (available on a host, or assigned for a VM) are added up. For each group, total cores x points/core (from the points table) is calculated. Any fractional result in each group is rounded up. 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. 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 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, and licensing fewer cores in a minimized and tightly bounded cluster. 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`).

IT Asset Management (Cloud)

Current