8 Triggers of an Oracle Audit: And Tips to Avoid One
The day has come, and it is not good news. You have an Oracle Audit. Oracle is notorious for having a very confusing licensing policy. It is vague and one misstep could possibly have you shelling out thousands in audit fees. Even with Oracles vast array of management packs and pre-installed options that are easy to use, finding yourself out of compliance is much easier and more common than you think. And don’t fool yourself into thinking that Oracle won’t come and hunt you down. Based on a recent Flexera/IDC report, 63% of the surveyed organizations were audited by a software vendor in the past 18 to 24 months. In which 56% had to pay additional fees, many over a million dollars. Among software vendors, Oracle is consistently recognized as one of the top auditors, happily exercising their right to ensure that everyone is in the black and white no matter how grey the rule might be.
Consider the fact that 85% of the organizations surveyed are actually out of compliance with their software licensing agreement. More than likely, your company is one of the offenders. However, it is not always clear what you have done wrong. Throughout this article we will look at the most common behaviors that can trigger the dreaded Oracle audit.
Bad Behavior #1: Lack of licensing inventory
While tracking your software licensing documentation can be a tiring, and boring task, it is one of the most important. Make sure you understand exactly what is required of you and stay ahead of it. In addition to tracking the OLSAs (Oracle License and Service Agreements), you also will need access to the renewal dates, full order histories, discounting offerings and any and all other information that is relevant to your specific software investments. And don’t forget – if you are working with older OLSAs, you will also need to keep track of the product names and metrics that have changed over the years.
Fully understanding what products you have and how you are permitted to use them is based on the availability of your licensing information. For example, an ASFU (Application-Specific Full Use) license and a Full Use (FU) licenses are completely different from one another. Neglecting to track this information can lead to a great deal of uncertainty, including knowing the precedence of your contracts when conflicts may occur between an OLSA and one of the addendums.
Bad Behavior #2: Not knowing what’s installed where
Now that you know what you are permitted to do, knowing what you are actually doing is equally as important. However, we find that few organizations keep a complete inventory of the products they have implemented, not to mention which editions or versions they are. And to make matters more difficult, you can easily use options and management packs without being licensed.
How to help: Maintain an Oracle Server Worksheet: Document all Oracle software implementations in order to accurately track where licenses are in use. Include all environments (Production, Test, Development in this documentation and make note of hardware CPU allocations to allow for accurate license usage counts.
One of the biggest challenges with Oracle software in particular, is that product options and management packs are often installed with the main products and enabled by default. Especially in enterprise editions. This allows administrators to easily use these features even if they haven’t been licensed. And this can increase chances of being out of compliance exponentially.
Bad Behavior #3: Indiscriminate virtualization
Virtualization is one of the biggest gotchas in the world of Oracle licensing. It is actually so easy to fall out of compliance that if Oracle decides to audit you might as well write the check right then and there. The biggest challenge that you will face with this is that Oracle supports only hardware partitioning, not software partitioning like you get with VMWare. Because of this, you are required to license all process and cores that are accessible to the Oracle product. However; this is not what usually happens. Instead, organizations license the logical partitions, but fail to account for the underlying hardware’s physical processors. When setting up a virtual environment, you need to take into account the entire system architecture. Don’t leave anything out!
Bad Behavior #4: Indiscriminate implementations
One of the more common triggers is to install products without paying for any licensing at all. The biggest culprits of this are non-production environments. Oracle expects that you are licensing your development, testing and preproduction environments, the same as you would a production environment. This means that you must account for users, processors, editions, versions, management packs and all those built-in options.
Don’t count out all those other places you can slip up as well, such as non-human operated devices. Even though they might not require a person to run them, they still are counted like other users and must conform to Oracle licensing. Lastly, do not forget about data transfers. You still have to track and count users who trigger manual as well as users (or devices) that perform flat file transfers. Even data transferred over a multiplexing infrastructure requires users be licensed.
Bad Behavior #5: Mismanaged fault tolerance
Disaster Recover and high availability implementations can also have organizations falling out of compliance. For example, they might fail to license failover cluster nodes or servers used for mirroring and standby. This happens because most do not know that these components need to be licensed. In other cases, they might use different metrics to license different nodes.
We often see that organizations fail to take into account maintenance jobs on failover servers or forget to switch back from a secondary node to a primary one after a failover situation has been resolved. Also, forgetting to license the options and management packs on their standby servers can lead to issues, even though they’re licensed on the primary ones. Clustered environments also tend to exacerbate other violation, leading to additional headaches for your organization.
Bad Behavior #6: Metric misunderstanding
Improper counting can cause many of the issues related to metric misuse. An example would be an organization who is using the Processor metric might fail to count cores or occupied sockets or fail to round up the number of cores to the next integer for each processor. It is common to underestimate the actual number when using the NUP metric by not accounting for minimum requirements or failing to count indirect users, such as those accessing the software through daisy-chain applications. If you are working with an Oracle product, you can best believe that there is no such thing as a simple metric.
Bad Behavior #7: Misuse of License
Whether willingly or unknowingly, we find that many organizations use Oracle software in ways the licensing doesn’t permit. The best example is the Unlimited License Agreement (ULA), which is often interpreted as a software smorgasbord that grants you the right to use just about anything anywhere you want. However, a ULA has limitations on which products you can use, where you can use those products, and how long you can use them.
But don’t feel like ULAs are the only trap, there are many more you can fall into. Should your organization modify an Oracle application without upgrading the license, run multiple product editions on a single server but license only one, or fail to adhere to the required hardware restrictions when installing specific software editions, you can be caught misusing your license. And should you find yourself using Oracle products in many ways that the licensing doesn’t intend, this could end up costing you dearly should Oracle ever become aware.
Bad Behavior #8: Don’t fall victim to piracy
If you have learned anything so far, it’s that it’s easy to fall out of compliance with Oracle software licensing, especially if you’re working with many Oracle products across distributed environments. And the behaviors in this article only depict some situations you might find yourself in. Oracle makes it easy to fall into these traps, and the company is happy to reap the benefits of your misuse. Clearly, if your organization is running Oracle products, you need to be continuously monitor your entire Oracle estate across all platforms. Should you neglect anything, you could have an auditing nightmare on your hands. And this can lead to major fees for your organization.
We hope that this article helps provide perspective as to the pitfalls that can lead to being audited by Oracle. Still feel like you need outside help? Click here to be contacted by our representatives today!