5 Fatal Mistakes of Oracle Licensing Rules

oracle licensing rules – 5 Fatal Mistakes

“Five Fatal Oracle License Mistakes”, alright the title is a bit dramatic, but the following 5 mistakes crop up on such a regular basis that we at Madora believe they are worth reiterating.

For those experienced with Oracle, they will know the following as classic gotchas and will keep an eye out. IT professionals and Procurement Officers new to the ways of Oracle may get caught out – so be warned. Let’s walk through some of the five common areas that often have disastrous consequences.

The Five Fatal Mistakes are:

1. Virtualising without fully understanding the implications.

The issue we see time after time is misunderstanding Oracle licensing on VMware. So why is this? It’s to do with server partitioning. Server partitioning can be very confusing; it is designed to limit the amount of processor resource available to a program; it is nothing to do with the Oracle Database Partitioning extra cost option – that is a means of partitioning data tables.

Oracle simplifies server partitioning into two groups; the methods that it refuses to recognise as valid, known as “Soft Partitioning”; and those it accepts really do subdivide servers, known as “Hard Partitioning”.

Probably the most popular server partitioning method is VMware, a very flexible form of partitioning and a great means of managing a datacentre. Guess what? It is soft partitioning for Oracle; this means that it is incredibly easy to fall foul of Oracle’s licensing rules. How your VCenter is set up, the clusters, the VMs, the storage architecture all have an impact on licensing. VMware publish guidelines on how to license Oracle, but Oracle don’t support their view; great fun when it is your turn for Oracle’s regular license audit!

Oracle’s approach to VMware has changed even further since the release of VMware Version 5.1 with its more advanced DRS/VMotion capabilities and its shared storage functionality. Seek independent help to review your architecture and any planned changes; don’t assume anything!!

5 Fatal Mistakes of Oracle Licensing

Click To Tweet

2. Disaster Recovery scenarios not licensed correctly

This can be a complex area with technologies changing all the time. We highly recommend you speak to Madora Consulting if you have any doubts as to whether you are correctly licensed for DR architectures.

In general we advise that you assume you need to be licensed fully and then check to see if your scenario falls under failover and whether the 10 day rule applies.

In terms of licensing be aware that you cannot mix metrics. In other words, if processors are used for the primary site then the backup site also needs to be licensed by processor. A common mistake is believing that Named User Plus licenses can be used for the backup site – in the hope of saving money. You are better off ring fencing the DR servers contractually and negotiating a reduced cost for this license pool.

Also make sure that the options and management packs are licensed, as these are often forgotten.

In short, scenarios where the Primary and Secondary nodes share a SAN, with the secondary node acting as a failover, only the Primary needs to be licensed. This is valid as long as the failover to the secondary lasts less than 10 days per year, which includes any testing.

Any standby or mirroring environments must be fully licensed.

See the Oracle paper on DR pricing http://www.oracle.com/us/corporate/pricing/data-recovery-licensing-070587.pdf

Watch the video for more on Disaster Recovery scenarios not licenced correctly.

3. Non production environments not licensed.

With Oracle you do need a valid license for development environments, test environments, and any pre-production environments. This whole article assumes standard terms and conditions, but you may have negotiated non standard options, so do check.

Test and development must be correctly licensed. Use of OTN licenses does not necessarily mean you are licensed correctly for Development environments. (Note -the environment used by end users for business or other operations is called a production environment.)

Oracle Technology Network licenses for development

Some developers are aware of the Oracle Technology network where licenses can be downloaded. OTN does offer a restricted license grant but this too is often misunderstood. The OTN license is really for the use of a single developer whom wishes to try out a piece of software. The license is only allowed for one user and one server. We have seen cases of whole development teams assuming that the OTN licenses give them the right to develop an application as they have not moved into production but this is not the case. See below an extract from the OTN license document:

Update 2016. The terms of the OTN license agreement has been changed. See below

“Oracle grants You a nonexclusive, nontransferable, limited license to internally use the Programs, subject to the restrictions stated in this Agreement, only for the purpose of developing, testing, prototyping, and demonstrating Your application and only as long as Your application has not been used for any data processing, business, commercial, or production purposes, and not for any other purpose. You may allow Your Contractor(s) to use the Programs, provided they are acting on Your behalf to exercise license rights granted in this Agreement and further provided that You are responsible for their compliance with this Agreement in such use. You will have a written agreement with Your Contractor(s) that strictly limits their right to use the Programs and that otherwise protects Oracle’s intellectual property rights to the same extent as this Agreement. You may make copies of the Programs to the extent reasonably necessary to exercise the license rights granted in this Agreement. You may make one copy of the Programs for backup purposes.

We know from talking to Oracle that they do monitor downloads, particularly for the more specialised products and will look for inconsistencies.Though the Sales reps could see this as a new project and be in touch.

So the good news is you are not limited to just one copy of the software per person or server. You are still subject to audit though as is made clear in the agreement. So you can download and develop and test a new idea or concept without purchasing Test / Dev licenses as long as the application is not in production or doing live work. Interesting to see that it refers to applications so my take on this that it is per application you are creating. So the fact you may be using the software elsewhere in production for another application does not limit the use of OTN licenses if you are prototyping or developing a new application.

4. Database options typically for the Enterprise Manager Packs are often installed by default but not purchased.

This one still crops up either because the DBAs have installed the options as this is the default on installations or because the DBAs assume that the options have been purchased. The reality is that most DBAs really do need the testing, tuning and diagnostic packs. They are almost a prerequisite to managing Oracle estates. Most of us would almost regard them as part of the core database. Unfortunately they are still chargeable options so must be purchased.

Some confusion still exists as the Oracle Enterprise Manager (OEM) Database Control and Grid control are provided free of charge. But they need the chargeable packs to really add value and these need licenses to cover the applications that are being monitored.

See an extract from Chapter 10 of the Oracle® Enterprise Manager Licensing Information (found on the home page of the OEM documentation) specifically states;

“The base installation of Enterprise Manager Cloud Control 12c includes several features free of charge with the purchase of any Oracle software license or Support contract”.

It is not unusual for small to mid-sized groups to legally install a Cloud Control free of charge on a spare server in their area. As indicated, a basic install, with no frills, is included with any supported license.

A very common pitfall for organisations facing difficulties with their Oracle license management comes from not having the right options granted and management packs installed for their needs. When the Oracle Enterprise Database Edition server is installed, by default all the enterprise options are installed too and it is important to know what you are actually using and whether you need it.

There are two aspects to this, firstly you need to know what databases are installed and what editions they are i.e. standard or enterprise. Secondly, you need to know whether any management packs have been “accepted” or options “granted”, to use Oracle’s terminology. Interpreting this incorrectly can significantly affect licensing costs from anywhere between US$163,000 and US$800,000 per processor, because options and management packs require additional licensing and should not be present if not needed as this rapidly adds to the total cost.

5. License Minimums not understood, so Named User Plus licenses not counted correctly.

A number of products have a minimum number of licenses that must be purchased, fairly standard software practice in the industry. However, there is added complexity with Oracle with some metrics such as Named User Plus. The mistake many people make is assuming that the number of Named User Plus licenses relates directly to the total number of the users of the system in use, unfortunately, that is not always the case. For the Oracle Database Enterprise Edition there is a minimum of 25 Named User Plus per licensable processor. So even with NUPS you still need to understand two things; what a licensable processor is and how many do you have. This presents extra work and understanding on your part. From a compliance point of view you must own the larger of either the total number of users or the license minimums.

The key points here are that a user is counted (at source) regardless of whether they actively use the Oracle programs and that non human devices are also counted. If you are using transactional processing monitoring software or using application/web servers then be sure to measure the users at the front end. For example, 1,000 users accessing a web application that connects to a back end database via an application server needs to count 1,000 users, even if the user is an anonymous system user between the application server and database. User minimums still need to be counted as well, so check the relevant user minimums table for the product in question. For Database Enterprise Edition you need the larger of either – processor count x 25 NUPS or User/devices. A licensed Named User Plus may access the Oracle technology on any instance (Production, Test, Development) or server throughout the organisation as long as the user minimums are met.

Named User Plus licenses are decreasing in usage as Processor license metrics are increasingly easier to manage and make more sense when it is difficult to measure users.

Example 1

Let’s say you have a non production environment used for staging and patch testing before roll out to the live financials systems, the application runs on Oracle Enterprise Edition. The non production environment is used by x 1 DBA, x 1 Financials Functional Consultant and x 1 Financials Developer. The common mistake is to assume that only x 3 Named User Licenses are required. Assuming you have no special contract terms then the license minimums kick in. So firstly we need to know the server(s) that the non production runs on. Let’s say you have two servers each with 8 cores (ask your infrastructure Manager to tell you the total number of cores per server). If you ask for the number of processors you may get the wrong answer, i.e one processor can have 8 cores, so you may use the processor count, which would be incorrect. It is licensable processors which we need and that is dependent on the core count. Think of cores as Olympic rowers sharing the same boat, it’s the number of rowers that impacts speed. We have a total of 16 cores and to determine the total number of licensable processors multiply the core count by the core multiplier.

See our downloadable guide to useful oracle links to get the URL for the table.

The core multiplier is dependent on the Chip manufacturer. If your Chip manufacturer is Intel then simply multiply the core count by 0.5. So 16 x 0.5 = 8 Licensable Processors.

Now each processor needs a minimum of 25 Named User Plus licenses. So we are looking at 25 x 8 = 200 Named User Plus Licenses. As this is the greater of the number of users/devices then this is the number required to be correctly licensed.

Yes indeed! 200 Named Users required not 3! This is the gift that just keeps giving for Oracle. Don’t get caught out.

Example 2

Let’s look at the production environment for the live Financials systems. The application runs on Oracle Enterprise Edition on 2 servers with a total 16 cores. The environment is used by x 1 DBA, x 1 Financials Functional Consultant and x 1 Financials Developer with a total of 300 employees for Payroll.

You know from the previous example that the minimums are 200 Named Users for the non-production environment. The minimums for the production environment is also 200 Named users. To licence just the production environment we would need 300 as it is the larger of the users vs minimums. Oracle therefore, no surprise here, requires 300 Named User licenses. However, we need to licence the entire estate and the total user minimums across all servers whether production or non-production need to be counted. The total users minimums is 200+200 for both environments. Now although a Named User gives the right to access any server, the user minimums for the entire Oracle estate still apply. So for the production and non-production environments, 200+200 = 400 named Users would be required not 300.

See a more detailed article we wrote on User Minimums for more of an explanation.

The above are the most common costly mistakes Madora come across all the time. So beware as these are the things Oracle Licence Management Services look for in any review, whether, Soft or real.