In short – No … or at least do your best to find an alternative to running Oracle’s scripts. That’s because Oracle’s scripts extract way more information than you think – and will put you at compliance risk. Let us elaborate…
As mentioned in our previous blog post about ULAs, Oracle’s Unlimited License Agreements (ULAs) can be very beneficial for some customers. There are, however, some important pitfalls to watch out for, particularly when the ULA is coming to an end and the customer decides to certify their final usage numbers as go-forward entitlement. This is typically referred to as the ULA certification process.
In theory, a customer need only provide a certification indicating the different ULA products they are using along with the corresponding metric quantities in use. For example, a customer may have a ULA for the following products: Database Enterprise Edition, Diagnostics Pack, Tuning Pack, Internet Application Server EE. Suppose the 3 year ULA is now concluding and the customer decides to not renew the ULA. Instead, the customer will certify to Oracle the quantity of each product they are running. For example, the customer may certify the following usage:
DBEE – 100 Procs
Diagnostics Pack – 100 Procs
Tuning Pack – 100 Procs
IAS EE – 75 Procs
In theory, that’s all that the “certification” process should entail. Now, as most customers with ULAs will realize, the process of counting up of their own usage is much more complicated and time consuming than initially estimated. Further complicating this is that Oracle may simply not trust the customer’s own counting of their usage. Oracle’s License Management Services (LMS) will get involved and will seek ways to challenge the customer’s certification quantities. Additionally, LMS will offer its own “assistance” in the counting of these usage numbers. Such “assistance” may include completion of spreadsheets (“GDRs”) by the customer with server details, as well as running the dreaded Oracle “scripts” for measuring usage of the different products. This can open a new can of worms.
A customer may agree to run Oracle’s database collection script (called “ReviewLite”) to measure usage of the Database product. This script will pick up usage of Options and Packs as well. So running this script will pull measurement for Diagnostics and Tuning packs as well, in addition to DBEE. So far so good. However, the script will also pull evidence of use of any other Options and Packs – even ones that were not intended or were accidental.
Say the scripts also found usage of Compression Option – a product not originally in the ULA. The customer will be discovered to be non-compliant and on the hook for hundreds of processors for Compression Option too! The same goes for all other Options & Packs – Advanced Security, Lifecycle Management, Active Data Guard, etc. Further complicating the situation is that these Options & Packs are installed with Database installation to begin with. All it takes is for an admin or engineer to unknowingly check the wrong box or enable some innocuous feature to trigger full blown license requirement, even if it was unintended. And running Oracle’s scripts will expose these in their glorious detail.
Running Oracle’s scripts for Middleware programs may pose a similar risk. Obviously this leads us to other important questions too: What are the alternatives? Will refusal to run scripts at this stage put you at a greater audit risk? These are important discussions for future blog posts. In short, the ULA certification process benefits from expert knowledge and experience – which is what our Oracle ULA Service delivers.