Being audited by a software vendor is never a pleasant task. At best, there is still a risk of significant disruption to business-as-usual operations while attentions are diverted meeting the reporting requirements of the vendor.
Oracle itself doesn’t exactly have the best reputation for customer friendliness at times of an audit, but there are steps you can take to minimize both the disruption and cost.
By asking yourself the questions below, you can self-identify the areas that require attention before an audit happens. This enables you to both gather data and make changes to your licensing situation in a proactive manner – which is always less disruptive and costly than simply sitting and waiting.
The questions below are each ranked 1-5 in order of how important they are (1 being the most important) in the auditing process.
1. Have you undergone a hardware consolidation or infrastructure modernization program in the last 18 months?
This is a priority 1 question, as we all know that new servers and infrastructure have more cores and faster processors. Also, it generally means extra configuration including DR options. Oracle will want to know what your new platform is, how it is architected and if that will require additional licensing. Either you need to give them this information proactively or an audit is coming.
2. Are you using virtualization software such as VMware in your Oracle data centers?
Also a priority 1 question to investigate. If you are now using any virtualization technologies that were not previously in your Oracle environment, it will almost certainly lead to additional licensing needs. If you didn’t purchase more licenses already, then Oracle is going to come asking about your new platform. If there is a gap (and there likely is) then you will be responsible for full price purchases of all database and options.
3. Do you have any Oracle based Disaster Recovery environments?
Another priority 1; this is a sure thing if you haven’t had one before. You may believe that you are covered from the ‘10 day rule’ but in most cases that does not work. Also, you will be responsible for the database and options that you are using in production. Make sure you know your environment before Oracle looks into this.
4. Have you made any acquisitions, divestments or been involved in any mergers since your last purchase of Oracle products?
This is also a priority 1 in almost all cases, especially if you currently have a ULA as it most certainly will effect that agreement unless you have provisions already built in. Anytime the organization size changes will be a good reason for review in Oracle’s eyes.
5. Do you have any old license metrics? – check your support renewals and contracts to see if you are using old UPU metrics for Oracle Database
This is unlikely to automatically prompt an audit, but it is important to understand whether you are still employing older licensing metrics such as concurrent use. Oracle will want to move you off those metrics and an audit may just be an easy way to move you. As such, this is a priority 2 question you should ask yourself.
6. Do you provide a chargeable service for customers that is powered by applications underpinned by Oracle products?
This is a priority 3 unless you do not have an agreement covering you for third party access, especially if you are making money off of the platform (in which case it quickly becomes a priority 1!). This is considered proprietary hosting and is no longer something Oracle will easily allow. If you do not have a proprietary hosted agreement and this scenario applies to you, you will certainly be audited. Furthermore, make sure that you are properly licensed for all your development it is licensable and you are not covered under OPN. Check you have the correct license type. E.g. standard contracts are for internal use only. Hosting or embedded licenses are different. So your contracts, even a ULA may not cover some of your customer facing applications. We are seeing more of this so will be writing a future article on this topic. Let us know if of interest.
7. Do you have multiple production clones, staging areas and other test/development environment?
If you’ve been using clones and staging areas for some time, you should already be on top of this and thus it should only be a priority 4. However, it you are new to using production clones, then it is important to check that you are operating within the appropriate licensing rules and not risking a large overspend.
8. Do you use a third party outsourcer to manage your IT or that provides remote Database Administration services?
I would rate this a priority 3. Although there could be challenges, it would be very hard for Oracle to get all the information they require and very easy for the outsource provider to change the environment in question. It’s something Oracle is likely to ask about but probably not a huge threat. However, in many cases you are responsible for the platform that you are using at a third party or with Oracle On –Demand; if they make changes that impact licensing you need to be aware.
9. Does your organization use Named User Licenses (NUPS)?
This is another priority 5. This is a common metric and in most cases completely organizations are using it appropriately. It is not a significant risk unless you are managing an environment that is open to the web and only have NUPs.
10. Do you have multiplexing scenarios?
This last question is something of a coin flip. Depending on your scenario this could be major reason for audit or it could be a non-issue. The main consideration is always have the knowledge about your license environment and its implications to hand. Being able to provide a quick and accurate answer will allow you to be prepared no matter what comes. The conclusion is quite simple. The more information you have available at any time, the more likely you are to be able to either put off an Oracle audit altogether, or at least minimize the cost and disruption of a licensing review.
For a free guide on managing Oracle database licenses, download Snow's free white paper.