Oracle Licensing Rules – Five Fatal Mistakes Part 2

Oracle Licensing Rules – Five Fatal Mistakes Part 2.

Following on from the first 5 Fatal Mistakes of Oracle Licensing, we have had lots of great feedback on some other ‘fatal’ mistakes.  Thank you to Piaras Macdonnel, Johnnyq72 and @limesoftwareuk. We have complied a list of five further gotchas which those new to Oracle licensing need to be aware:

1. Over deploying products not covered by a ULA.

When a Unlimited Licence Agreement (ULA) is set up and agreed with Oracle it will only cover certain products, perhaps Database Enterprise Edition and several options. Often there is a misconception that you have a completely unlimited contract and can install anything. However, if it isn’t in the list then it isn’t covered and so any deployment will incur costs if an audit or review is carried out. Also, bear in mind you need to keep track of any deployment of the products within the ULA, ready for the declaration at the end of the term (often 3 years). If you are not in a position to correctly declare the usage, it may be very expensive!

2. Standby/mirror not on same metric as the primary.

Named User Plus is often used in a situation where there are small numbers of users as a lower cost alternative to processors. Unfortunately, it isn’t a way of saving costs for your standby servers, as they need to be licensed by the same metric as the primary server, which will be processor if the users can’t be counted.

3. Using an ASFU system for another application.

Third party suppliers or ISVs will sometimes provide Oracle Database licences to underpin their application. However, they can only be used for that specific application on any one server, so if you need to run more than one application on a server then you need Full Use licences. It may be more cost effective to buy separate servers rather than Full Use licences, so you need to check this more carefully before deciding.

4. You can’t run DBSE on a server only licensed for DBEE as they are separate products.

Occasionally there is a need to run different applications on different editions of the database and unfortunately, you can’t buy Enterprise Edition and expect to be able to also run Standard Edition using the same licences for the server. It may be cheaper to move applications around to take advantage of licences and space on other servers. Otherwise, you need to buy licences for both editions for the server.

5. Running command lines directly via SQL* can indicate usage of chargeable Enterprise options.

DBAs are often more comfortable executing commands via the SQL* interface as it is typically quicker. Some commands however can in effect be using Enterprise Options which you may have installed as part of the default installations. Running these commands can flag a usage of those options if Oracle run scripts during an audit. There are a number of useful packs which form part of enterprise manager, such as diagnostics and tuning packs and are almost taken for granted by the DBA community as being part of the core Database. However, they are extra cost options and the financial exposure can escalate if you have a large server estate. It isn’t always obvious whether specific commands and SQL code triggers these extra cost options and even some third party tools will trigger the requirements, so always check carefully before you deploy.

The above 5 gotchas along with Part 1 are some of the Oracle licensing mistakes Madora come across, there are of course many more.  Please do share your most costly mistake with us (you may wish to remain anonymous!).

(3) comments

Add Your Reply