Using SAM Tools for Oracle Licensing Part II — Usage (Discovery)
Usage
SAM tools often claim to simplify Oracle license management, however, using a single tool to manage your Oracle software estate’s compliance is typically unattainable and unrealistic. Still, SAM tools do have limited uses: it’s important to be aware of those and their limitations before investing in one.
In my last post, we compared the manual license management process focussing on entitlement vs using a tool and highlighted the areas where tools have limited capability. Moving onto this post, I will focus on how tools can measure (bits of) usage.
Usage — An Introduction
How does the tool know what to measure?
A significant part of any engagement we undertake is focused on entitlement — what license and license rights does a customer have. Where possible, we do this before even considering usage — entitlement dictates the approach for measuring usage.
Without understanding the entitlement and metrics, any attempt to measure usage will be guesswork and may be fruitless. You need to have a clear view of the metrics and what products are from the entitlement so that you are certain about what should be measured in the estate and what specific elements need to be counted.
Measuring Usage
To understand how a license position is calculated, the below diagram helps to show the basic elements: note that the two middle boxes are, collectively ‘usage’; see below for a detailed description.
There are two distinct stages to measuring product usage:
- Discovery: Find out what is within your estate, and which products are running on which servers and interrogate product options once the product is found. Measure the relevant elements to determine the count as per the licensed metric.
- Calculate: Apply the logic to the discovered data in order to perform the license calculations — the policies, the virtualisation and partitioning rules relevant to your contracts.
This post will focus on #1 (Discovery).
Usage Driven by Entitlement
Typically, for the vast majority of customers that will be Processor and Named User Plus– when we are talking about database or tech products — plus the associated rights, limitations contractually defined plus non-defined policies and rights including virtualisation and cloud platforms etc. This is a reasonably solid place to start but don’t assume that this is exactly what a tool promising to measure Oracle licensing is going to capture and calculate for you. There is no chance that the tools will have the ability to understand the intricacies of your contract, or what you should really be measuring within your estate for usage.
- Why measure/calculate processors when you are using another metric?
- What is your processor definition? Remember that these will have changed over time — using today’s processor metric is not equivalent to using a processor metric from 20 years ago. If your tool is automatically assuming your processor metric, then immediately, out of the box, it could be miscalculating your position.
There’s also a fundamental question here: how does the tool count license requirements for VMware, other virtualisation and cloud; there will be in-built ‘calculations’ which may be wholly inappropriate for your contract and your approach to VMware (you do have an internal policy for VMware, don’t you? If not, see this for discussion). This topic will be covered further in the next blog on how tools calculate your requirements.
Do all instances need to be counted and licensed?
There may well be instances where you don’t need to count certain usages of commercially licensable software, such as:
- The RMAN repository for Oracle Databases
- Restricted use included products (e.g. Database being included as part of IAM Suite at no extra cost)
- Where part of your estate is not in scope for your review
- Where your entitlement is for one part of your business or division
So, you don’t always want to include everything you ‘discover’ in your estate— you might want to restrict the scope or declare certain installations to be not considered for commercial license coverage, but also you need to marry this up with the scope of entitlement that you are setting as well. How can you ‘mark’ or classify your estate with meaningful notation to ensure that in future, it is clear why some of the estate is licensed and some of it is not?
There could be a big difference between the usage you find and the license requirement. There may be a number of servers where licenses are not required or are covered by things like embedded or ASFU type licenses which might not be a consideration in your overall view of the estate.
Certain elements relating to usage are *always* declarative
There will be components on every contract that will always be declarative. Capturing that declarative information in a tool is critical to accurately measure your usage.
Good examples of some of these elements defined contractually (and therefore usage rights are governed by) are:
- Territory — country of usage (there are differing opinions as to what ‘territory’ really means in the context of Oracle contracts; this is not for discussion in this blog!). It is not as ‘simple’ as just the server location: can the tool even determine this (or do you need to bring in your CMDB?).
- Business entity — business that is using or getting business benefit from the software — cannot be measured.
- Environment — often drives which metrics you apply to a particular server. Cannot be measured automatically, needs declaration.
It’s important to understand if your tool can capture (i.e. allow you to enter or feed from other sources such as your CMDB) declaratives in association with discovered data and whether you can override elements that may be measured or inferred by the tool? In the event of any ‘overridding’ of data, this should be notated with reasons, individual who made the change and rationale — along with an audit trail.
Usage in Tools
A large number of the tools advertising their Oracle license capability were existing estate discovery tools with Oracle modules ‘bolted on’. In a way, this fits well with the logic above showing “Discovery” and “Calculate”; an existing estate discovery engine should be a good base to gather the necessary information for licensing purposes.
One of the biggest challenges when deploying a tool is granting that tool appropriate access to the entire estate; often easy enough when that tool is in the estate for other purposes. However, this challenge is compounded when databases are introduced. Firstly, there’s a different set of credentials involved for databases which may require a generic powerful user or access from the operating system into the database; at this point, with sensitive information being held in databases, access can be a challenge.
It is worth noting that it is not possible to interrogate for Oracle database option usage without logging into the database with the correct privileges.
In our experience, deployment and authentication of tools for Discovery purposes is a major challenge.
The Calculate phase of usage calculations will be discussed in the next blog.
Conclusions
- How can your tool know what it needs to measure? It can’t read your contracts or understand what your metrics are — there may be built-in assumptions.
- Not all your estate will necessarily need to be included in the license count; how can these be excluded in a meaningful way?
- Some elements of usage will always be declarative — can these be captured as part of the discovery process?
- Tools for Discovery will require significant effort to configure with the right privileges.
We have only discussed technology products here — however the principles apply to applications products, with arguably harder elements to measure and certainly not in a consistent way.
For more information, watch my webinar on SAM Tools for Oracle, go to our website or contact us with any questions.
About The Author:
Paul Bullen is a Principal Oracle License Consultant and Practice Lead here at Version 1.
