Diffusing an Oracle audit – PT III
The advice in my first post of this three-part series on audit defense covered what to do when first approached by Oracle. The second post scrutinized contracts, and in this final piece I take a deep dive into the data Oracle will want to extract from your network.
Gotcha 11 – Be in control of your data
Oracle wants to be in control of collecting data from your network and the systems attached to it. The want to know what products you have installed, on what hardware, and the extent to which you use them. They want to be in the driver’s seat. To do so, they will request you to run several scripts in your environment. The first, a CPU script, collects hardware specifications. The second, known as Oracle Review Lite, queries your network for deployment and usage of Oracle products.
Are you obligated to run these scripts? No. The terms of the standard agreement state:
Unless your contract states you are required to run the scripts that Oracle asks you to run (which I doubt), and as long as you can provide all the necessary information in a complete and accurate manner, Oracle will need to accept your data as the source of truth for validating compliance.
Gotcha 12 – Understand your data
Okay, so contractually you are under no obligation to run the Oracle scripts. But is it such a big deal? After all, Oracle wants the same as you: to have a complete and accurate picture of your deployment. So why not run them? The difficultly comes in understanding the output they create. And if left to Oracle, their interpretation might come as a nasty shock.
For example, if you have an Oracle database and use a functionality called Data Pump, eventually and probably unwittingly, you will trigger Data Pump Compression. When this function is invoked you are required to license the option “Advanced Compression” separately. So, it’s never a good idea to share data with the auditors, unless you are 100% certain of what it reveals. Don’t get me wrong, I’m not talking about hiding things, or trying to get one over on Oracle. It’s about you as a company understanding what data you share so that you can prepare and budget for any shortcomings in licensing and avoid unplanned spend.
Gotcha 13 – Maintain control of your data
IT teams are understandably wary of running third-party code, but Oracle’s scripts have little or no impact on the systems of its customers. That is not to say Oracle is likely to accept financial liability for anything going wrong.
Ask Oracle to accept financial liability (in writing) for any damages caused by their scripts, and the chances are Oracle will accept your declaration of usage instead.
Doing so will delay the audit, and put you in control of the data you share with the auditors. But beware. The auditors will scrutinize the information you share, so ensure it is complete and accurate. In practice, your SAM solution (as well as processes and people with the right knowledge) is the best way to provide you with the right level of information.
Gotcha 14 – understand Oracle with VMware
If you run Oracle database products using VMware, the physical servers that can run the Oracle software require licensing – which varies depending on which version of the hypervisor (VMware ESXi) you are running.
Figure 1: licensing requirements for various versions of ESXi
Figure 1 shows the licensing requirements for a datacenter with two vCenter server instances – A and B. Instance A contains two clusters with 16 licensable cores (total #cores x core factor), and B contains one cluster with 12 licensable cores.
Up to, and including, version 5.0, a cluster of machines running Oracle requires licensing based on the total number of cores in the cluster. These older versions of ESXi don’t enable movement of virtual machines among clusters, so there’s no need to license machines outside of the cluster running Oracle software.
In version 5.1, the functionality to move virtual machines across clusters within a vCenter server instance was introduced. This functionality enables customers to scale up and down based on increased or decreased load, or to implement zero-downtime failover. As such, a total amount of 16 licensable cores should be taken into account within this configuration.
As of version 6.0, VMware functionality allows you to move a virtual machine from one vCenter server instance to another vCenter server instance. If you have two vCenter instances both running on version 6.0 or higher (and an ESXi version 5.1 or higher), Oracle will require you to license the entire datacenter, which in the example runs to 28 cores.
Is this disputable? Can you have a different opinion? You can, but there’s only one company that tells you how to license the software, and that is Oracle. Despite the many white papers VMware publishes arguing one point or another, or whatever experts such as myself say about the matter, in the end it’s your contract with Oracle that dictates how much of your datacenter needs to be licensed.
Gotcha 15 – Understand Oracle in the cloud
It is a common misconception that moving to the cloud removes compliance issues. Not so – every vendor has different rules with which you need to comply. Here’s a real example that I’m handling today. In 2007, Oracle published its policy on licensing Oracle products in the cloud covering Amazon EC2 and RDS and Microsoft Azure.
Running an Oracle database in Amazon required the virtual cores to be licensed. Counting virtual cores is the same as counting physical ones, which is then multiplied by the core factor to determine the number of licenses needed.
After the 2007 announcement, a lot of customers started to deploy Oracle on Amazon.
On January 27, 2017, Oracle changed its policy from counting virtual cores to virtual CPUs. In almost all situations, where the old policy required you to license one Processor, today it requires two. I have a customer running their entire estate on Amazon. Based on the old policy, my customer has (or had) sufficient licenses, and made no changes to the existing contract. The policy has changed, and now Oracle is knocking on my customer’s door.
What impact this change of policy will have on my customer remains to be seen. The moral is, if you’re moving software to the cloud, licensing terms are likely to change.
If you want to know more about Oracle products, take look at Snow’s e-book: 5 Ways to Cut Spending on Oracle Databases, which describes five cost-saving initiatives for Oracle products. By applying all of these initiatives, you can save up to 30% on your Oracle database licensing costs.
If you’d like to learn more about B-lay’s services for managing Oracle Licenses visit our website