Table of Contents
Oracle licensing pitfalls are numerous and quite easy to fall for. This is because licensing itself is notoriously complex.
From genuine accidents around enabling Enterprise features whilst on a Standard license, to falling foul of Oracle’s disapproval of virtualisation – it’s very simple to inadvertently become non-compliant without realising.
With this in mind, it’s prudent to perform a Oracle License Review as part of a proactive approach to Software Asset Management (SAM). This review of your estate delivers guidance for your business and helps ensure that all areas of your Oracle estate remain in order. And with Oracle Audits typically occurring as often as every 2-3 years, it pays to be proactive.
Failing to remain compliant can be fatal for some organisations. Non-compliance fines are known to reach well into the millions of pounds, often for genuinely honest mistakes.
Here are seven of the most common Oracle licensing pitfalls our database experts have witnessed over the years. Remember that your Oracle Master Agreement (OMA) may have particular designations on these topics. If in doubt, always check your OMA.
1) Failing to Renew Licenses Post-Hardware Refresh
Any changes to your hardware or staff numbers is a classic trigger for Oracle to request an audit.
This isn’t a coincidence.
Typically, a business undergoes a hardware refresh in order to add servers, processors, and/or cores in order to increase productivity. After all, the needs of the business drive the needs of the database. And growth-minded organisations often need newer, more powerful architecture in order to fulfill these requirements.
But each addition, no matter how large or small, requires licensing and Oracle knows that not all businesses do this This is why an audit often follows any major changes to hardware.
Xynomix Tips
Oracle Standard Edition is usually licensed by processor, which Oracle defines as a socket. If you run multi-chip processors, then each chip is counted as an occupied socket.
Oracle Enterprise Edition is calculated by the following formula:
‘# of cores x core factor = # of Processor licenses required’
*Note: this rule changes when dealing with Oracle cloud (more information)
2) Enabling VMware (& other virtualisation tools)
VMware, or soft partitioning in any form, is deeply frowned upon by Oracle.
This means that if you soft-partition any of your estate, each partition must be licensed – with zero room for negotiation. If there is potential for an area of your database to use Oracle’s services, you’ll be billed for it.
An analogy we often use to explain the concept is the idea of the ‘Oracle car park’.
In the Oracle car park (ie. your estate) you can park anywhere. Flexibility is one of Oracle’s major strengths. So, out of the box, your database’s features and capabilities are theoretically limitless.
However because you can park anywhere – as the analogy goes – you must pay for every single parking space. Or, in this case, the total number processors or cores your estate includes, irrespective of whether they are currently used for Oracle’s services.
Enabling VMware complicates this further because by creating additional partitions, you’re opening your organisation up to further licensing requirements. Each individual processor of your VMware partitions must be then licensed.
This is why virtualisation can easily be one of the most costly Oracle licensing pitfalls in this list.
And because an Oracle audit is a case of when, rather than if, a business found to be using VMware licensed incorrectly (even historically), can see costs skyrocket easily into millions of pounds.
3) Failure to Declare Mergers & Subsidiaries
Contractual non-compliance is another of many potential Oracle licensing pitfalls.
If you’ve recently acquired or merged with another organisation, licensing can get particularly complicated.
Even with the best intentions, license reassignment – if not properly tracked – can get out of hand, leading to immediate non-compliance with an Oracle audit. Oracle typically seeks to carry out an audit of organisations that have recently been part of a merger or acquisition for this reason.
And whether both businesses are operating as part of the same company or not, you’ll likely need to conduct an Oracle License Review of your estate to clarify which Oracle products are in use by your organisation.
If you’re running Oracle and are in the process of either a merger or acquisition, it’s essential that you get in touch with an independent Oracle consultancy firm such as Xynomix to avoid any unnecessary compliance fines.
You also need to consider your subsidiary companies. Are they included in your license agreement with Oracle?
If not, you could face a multi-million pound fine the next time Oracle audits your business.
We recently worked on a case with Forth Ports, in which Oracle handed them a £2.5m fine following an audit.
Forth Ports, the registered company, was fully licensed for Oracle services.
However, the legal text in their license agreement failed to mention ‘Forth Ports and subsidiaries’. The simple omission of those two words in the license agreement resulted in non-compliance.
There was a positive result on this occasion after Xynomix negotiated with Oracle. However, not all cases end like this.
4) Accidentally Enabling Enterprise Edition Features
Oracle databases often come with Enterprise Edition options and packs pre-installed. This can lead to confusion for users on Oracle Standard Edition.
Any accidental usage of Enterprise Edition features, including (but not limited to) Oracle Data Guard, Real Application Clustering (previously available on Standard Edition), or Oracle Diagnostics Pack, is recorded in a view called DBA_FEATURE_USAGE_STATISTICS.
This view, accessible by both your organisation and Oracle, actively monitors your license usage, so if any Enterprise Edition features are inadvertently activated, Oracle will bring this up (including accidental or historical usage) at your next audit.
Whilst Enterprise Edition features are automatically installed as standard, they can be uninstalled to avoid users accidentally activating Enterprise options, features, or packs.
5) Improperly Licensed Backup and Disaster Recovery Servers
Oracle categorises backup and disaster recovery in the following three categories; Backup, Failover, and Mirroring (or synchronising).
There are licensing nuances to these options which are not immediately obvious.
Backup Environment Testing
Simply making a backup copy of your database, commonly using RMAN (Recovery Manager), is covered by standard Oracle licensing terms*.
However, according to Oracle, ‘For the purpose of testing physical copies of backups, your license for the Oracle Database includes the right to run the database on an unlicensed computer for up to four times, not exceeding 2 days per testing, in any given calendar year.’
Exceeding these four days, or spending more than the allotted two days at a time testing your backup, means that the test environment must be fully licensed. This is a common misunderstanding which catches out a lot of users so if you use this form of backup, try to plan ahead of any testing.
* Always check your Oracle Master Agreement for any specific or bespoke arrangements.
Failover Environment
The 10-day rule allows a user ‘the right to run the licensed program(s) on an unlicensed spare computer in a failover environment for up to a total of ten separate 24-hour periods in any given calendar year’.
This means that if one of your active licensed machines goes down, it can be replaced by a single passive failover environment for a period of up to ten 24-hour periods.
It is worth emphasising that only one passive, unlicensed environment can be used. Plus, if your failover environment is used for less than 24 hours, it still counts as one of your ten 24-hour periods.
It is not 240 hours’ worth of failover, which is where the confusion often occurs.
Disaster Recovery - Mirroring Data Between Two Environments
Mirrored environments are a great disaster recovery option due to their regular syncing with one another. It results in far less loss of data, should a disaster strike.
However, due to the nature of mirrored disaster recovery replicating a live environment, both environments are therefore considered to be active.
This means that if you choose to replicate your data to another environment through mirroring, both environments must be licensed and, crucially, licensed identically. You cannot partially license your mirrored environment – Oracle does not deem it to be any less active.
For more information on Oracle licensing for data recovery environments, check out Oracle’s guidelines: https://www.oracle.com/us/corporate/pricing/data-recovery-licensing-070587.pdf [Accurate as of 28th July, 2020]
6) Misuse of Oracle Technology Network (OTN) License
Oracle’s OTN license, which is separate from the Oracle Master Agreement (OMA) and Oracle License and Services Agreement (OLSA), grants a single user – on a single server – development rights for applications on a non-commercial basis.
This is outlined in further detail below:
Subject to the full terms of the OTN License Agreement, this limited license allows the user to develop applications using the licensed products as long as such applications have not been used for any data processing, business, commercial, or production purposes.
Customers may not use Oracle Database, as licensed under the OTN License Agreement, in connection with any classroom activity, internal data processing operations, or any other commercial or production use purposes.
More details Oracle Database Licensing
Once an application is pushed into testing or production environments, it must be properly licensed.
Where some businesses fall down is by allowing development rights for more than one user. Others get caught out pushing the application into testing or production without the appropriate licensing.
7) Confusion over ASFU Licensing
The final of our Oracle licensing pitfalls concerns Oracle ASFU.
An Oracle ASFU License (application-specific full use) is a restricted-use license.
This means that if you opt for an ASFU license on your database, no other applications or Oracle services can be used on that particular device. It is a license obtained exclusively for that particular application.
Sometimes businesses incorrectly assume that if a device is novated with an ASFU license, it means that they can therefore use Oracle solutions on it. This can be a costly mistake.
ASFU licenses are obtained slightly differently in comparison to other Oracle licenses. Instead of going through Oracle, you must obtain a license from the application vendor. This is because the application vendor is responsible for ensuring compliance.
This does not diminish your own responsibility however, and if Oracle approaches your application vendor to audit your licensing, you could face a significant audit fine.
In order to avoid this particular licensing pitfall, it is essential that all end-users in your organisation are made aware of any ASFU license agreements.
Overview of Oracle Licensing Pitfalls
If you’re unsure about what you can or cannot do on your existing Oracle licensing, your organisation’s Oracle Master Agreement (OMA) is always the first document to consult.
However, if there is even a hint of uncertainty, it’s best to have an Oracle License Review of your estate. It’s an invaluable means of optimising your licensing and serves as guidance for compliance, helping your organisation prepare for any future Oracle license audit.
An Oracle License Review from Xynomix is a simple process, delivering a fully-detailed report of your estate which includes areas of risk and remedial actions.
To discuss Oracle licensing in more detail, contact our experts at
[email protected] or via 0345 222 9600.
Contact Xynomix
Xynomix has unrivalled experience across the full range of Oracle and Microsoft SQL server database environments and are, therefore, perfectly positioned to offer independent enterprise-grade support to keep your critical systems up and performing perfectly. Get in touch now on 0345 222 9600 or via [email protected]
