In the battle of the sexes, there is only one winner. I call her Deb.
This should go some way to explaining the difference in approach between the two DBAs in the following story.
For many years now, licensing of Oracle Database software has been an arcane and confusing business. Whilst this is often an area that falls to the humble DBA to admninister, most DBAs aren’t lawyers. Sometimes, keeping on top of the licensing requirements takes a back-seat to the day-to-day technical challenges.
What follows is a cautionary tale on the potential ramifications of finding out that you are under-licensed…around the same time that Oracle also discover this unfortunate fact.
Before I go on, it’s time for the obligatory…
The information about licensing here should NOT be taken as definitive. This is just stuff that I’ve found out and conclusions I’ve drawn. I’m not a lawyer. I’m also not clairvoyant. Oracle’s licensing is a moving target and it’s quite likely that it will move quite a bit in the near future as technology marches ever onward and things become clouded by…well…The Cloud.
You want How Much ?!
An Innocent Question
DBA Dan , was having a busy day as usual. He worked for a small company – less than 100 employees all told and was single-handedly managing multiple Oracle Databases on various servers.
The significance of the missive that arrived in his inbox that morning would not become apparent for some time.
The e-mail was from the Oracle Technology Deployment Declaration Program.
It asked, politely, that Dan fill out the attached spreadsheet detailing what Oracle Products, including version numbers and editions were running on which servers.
This information was required to be provided within 5 working days.
“Great”, thought Dan, “something else to add onto the pile of things to do”.
In a quiet moment later that week, Dan duly filled in the spreadsheet.
He reflected later, that he should really have re-checked the Company’s licenses before pressing the send button. At the time he’d just assumed that when the databases had been set up originally ( before his time at the company), the appropriate licenses would have been acquired. After all, that would have been handled by the DBA at the time, wouldn’t it ?
Blood in the Water
A couple of weeks later, another unsolicited e-mail dropped into Dan’s inbox. This was from a company called Fairly Unscrupulous Databases Ltd (FUD), an Oracle Partner.
They advised that they had been instructed by Oracle to conduct an audit of the Company’s Oracle license usage. There was also some mention of a “system health-check”.
In order to complete this, Dan was asked to run the attached software on all of the servers running Oracle Products.
The attached software turned out to be Oracle’s Remote Diagnostic Agent – a suite of Perl scripts primarily used by Oracle Support for gathering information to help in call resolution.
Dan did as he was asked. He even ran it on the Company’s Disaster Recovery Servers although he was sure that Standby databases didn’t require a separate license. I mean, everyone knows that, right ?
Dan didn’t really pay that much attention to the output of the RDA. If he had, he would have noticed that this tool looks at a number of key areas on the server, as well as the database.
These include :
- Oracle Configuration Manager
- Certain Windows Registry Keys and Windows Services ( or unix equivalents)
- Enterprise Manager
- Server hardware (including CPUs)
- The v$license view
- Database Feature Usage Statistics
The output dispatch back to FUD, Dan thought no more of it…until…
The Health Check-which leg don’t you need ?
The health check report that FUD sent back contained 50-odd pages of stuff that Dan already knew. Anodyne was the word that sprang to mind.
Tucked away at the very end of this exercise in the blindingly obvious was the killer blow.
In summary, FUD thought that the Company’s Oracle Databases were perfectly healthy. Unfortunately, Oracle’s bank balance was not quite as healthy as it could have been, so a contribution to swell the coffers would be appreciated.
In other words, the Company had been found to be in breach of it’s license and the shortfall, backdated of course, would need to be made good.
Crunching the Numbers
The next few days were quite crowded for Dan.
First, he was given the unique opportunity to explain to a not-entirely-happy CEO just why Oracle had invoiced the Company for the thick end of one million pounds for the unpaid licenses – a sum greater than the company’s annual turnover and which would almost certainly mean insolvency.
He then learned that some frantic meetings between the CEO and those nice people from FUD had resulted in a compromise by which Oracle agreed to waive the license bill in exchange for the Company correctly licensing it’s databases, stopping the “use” of the Packs, and buying some rather expensive Oracle Software, the practical use for which was not immediately apparent.
In the end, the Company survived, Oracle and FUD presented an invoice that – only just – added up to six figures ( but still rather more than the £10K or so the company usually paid for Oracle licenses annually)…and Dan had a rather short conversation with the CEO. The gist of this was that Dan would be given the unlimited time to look into his prospects for alternative employment.
Dan left with the distinct impression that any reference provided for him by the CEO would not add up to much more than four letters.
Predator or Pragmatist
Cynics might regard Oracle’s actions in this (fictional) scenario to be little more than using scare tactics to extort money from it’s hard-pressed smaller customers.
A less judgemental view would be that Oracle is simply fulfilling it’s duty to it’s shareholders and claiming that to which it is legally entitled.
Either way, the profound effect of these events on both our poor DBA and the Company itself, render this something of a moot point.
The Wonderful World of License Documentation
Forewarned is forearmed
Contrast the tale of woe that is the story of Desparate Dan, to that of Deb, the working royal.
Deb works as a DBA in a company remarkably similar to the one that Dan left in such a hurry.
After starting at the Company, one of the first things she does is to find out what databases are running where and in what configuration.
On the MAIN_APP server, she has a single 11g Standard Edition One database which is used for the Company’s in-house application. The server has two physical CPUs.
On the TEST_APP server, she has Development, Test and UAT databases. These are also Standard Edition One. The server has two physical CPUs
On the SPIDERMAN server, she has a 10g Standard Edition database that back-ends the company’s public-facing web application. The server has one physical CPU
On DR_MAIN_APP in the Disaster Recovery Office, she has a standby database for the MAIN_APP database. The server has one physical CPU.
The Company currently holds a 100 Named User Plus license for Standard Edition One.
Having spent most of her career to date working on Enterprise Edition ( she is a Princess after all), she’s reasonably au fait with the ins and outs of Oracle Licensing. However, she also knows that assumption is usually the calling card of Mr Cock-Up ( a bloke, naturally).
Therefore, she decides to do some research.
To begin with Deb looks at the definitions for the two main license metrics for Oracle databases – Named User Plus and Per Processor.
Named User Plus
Deb notices that, if you purchase one of Oracle’s database products using the Named User Plus license metric, the minimum order allowed by Oracle is 5 licenses.
She also knows that a default installation of Oracle creates at least 14 database schemas. Therefore, it can be deduced that working out the number of Named Users is not as simple as doing :
SELECT COUNT(*) FROM dba_users;
According to the documentation found on this page on the Oracle Store site …
Named User Plus / Named User: is defined as an individual authorized by you to use the programs which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time.
All of the remaining provisions of this definition apply only with respect to Named User Plus licenses, and not to Named User licenses.
A non human operated device will be counted as a named user plus in addition to all individuals authorized to use the programs, if such devices can access the programs.
If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end.
Automated batching of data from computer to computer is permitted.
You are responsible for ensuring that the named user plus per processor minimums are maintained for the programs contained in the user minimum table in the licensing rules section; the minimums table provides for the minimum number of named users plus required and all actual users must be licensed.
The fact that the definition covers “programs which are installed on a single server or multiple servers…” is quite interesting.
In Deb’s case, the test databases on TEST_APP are all copies of the database on MAIN_APP.
Therefore, all of the databases on both of these servers have the same set of users.
So, if we have an individual user called Mike, who connects as user MIKE to all of the databases across the MAIN_APP and TEST_APP servers, this would constitute 1 named user.
Similarly, as Deb is the DBA, she is the only person who will connect as SYS and SYSTEM, as well as using her own account – DEB.
DEB, SYS, and SYSTEM across all of the databases on the two servers will constitute one named user under the Named User Plus license definition.
This point is also relevant when we come to consider the Disaster Recovery site a little later on.
Of some concern however is the bit about multiplexing. Essentially, as the web database is publicly available and there is no way to control the number of users who may access the database, it looks like Deb is going to need to cover this database using Per Processor licenses.
Per Processor – the Standard Edition Twist
Having spent most of her career working with Enterprise Edition databases, Deb is familiar with the concept of the CPU core multiplier which is used to calculate the number of EE licenses required for a server. However, trawling through the oracle site, she notices this.
When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to a socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.
So, Standard Edition and Standard Edition One per processor licenses are per physical CPU, not per core.
Oracle Database Editions
At present there are three licensable editions of the Oracle Database :
- Standard Edtion One
- Standard Edition
- Enterprise Edition
You can find the various different features available for each in the Oracle documentation. The feature list for 11gR2 can be found here.
Standard Edition and Standard Edition One
For smaller sites, it’s worth noting that Standard Edtion One and Standard Edition are almost identical.
The main differentiator between the two is that the cheaper Standard Edition One may run on a maximum of two physical CPUs where as Standard Edition may run on a maximum of four.
Standard Edition does come with a couple of extras – Oracle RAC and Automated Workload Management.
This is something that may well be worth considering when evaluating which license is required, irrespective of the License Metric required.
Editions and Metrics – the main points
Generally speaking then, the following applies for license metrics :
- If you have a known user community ( e.g. an internal company application) then Named User Plus licensing is an option you may want to consider.
- If you’re database is publicly accessible ( usually the backend for a website) then you’re probably limited to the Per Processor metric.
- Standby databases must be licensed separately using the same metric as the main database…but may be covered by existing Named User Plus Licenses.
- Unlike Enterprise Edition, the Per Processor license for both Standard Edition and Standard Edition One applies per physical CPU rather than per CPU core.
The main differences between Standard Edition One and Standard Edition are :
- Standard Edition One is cheaper
- Standard Edition One is limited to a maximum of two physical CPUs.
- Standard Edition may run on up to four physical CPUs.
- Standard Edition comes with Oracle RAC and Automated Workload Management.
Standby Database Licensing – Myth and Reality
There is a widely held belief that Standby Databases do not require a license. Howerver, looking at Oracle’s Licensing Data Recovery Environments documentation…
Standby: One or more copies of the primary database are maintained on a separate server(s) at all times. The sites in a standby configuration may be dispersed geographically and are connected by Oracle Net Services. As the primary database is modified, log information generated by the changes are sent to the standby database(s) and subsequently applied to the standby database. If the primary database fails, a standby database can be activated to be the new primary database. In this environment, the primary and the standby databases must be fully licensed. Additionally, the same metric must be used when licensing the databases in a standby environment. If any Option or Management Pack (except RAC) is licensed on the primary server, then it must also be licensed on the Standby server. If RAC is on the primary server but not on the standby server, then licensing it is not required.
So, if the primary database is licensed per processor then the Standby needs it’s own per processor licenses. However if, as in Deb’s case, the Primary is licensed by Named User Plus the situation is a bit different.
Obviously, the standby database is an exact copy of the primary.
Remember, the Named User Plus license covers a single user across multiple servers.
Here the DR_MAIN_APP server, where the Standby database is located, is just another server.
Therefore, no additional Named User Plus licenses are required to cover the Standby database.
Oracle keeps track of what features are being used on the database.
The quickest way to see this information is to issue the following query :
SELECT output FROM TABLE( DBMS_FEATURE_USAGE_REPORT.DISPLAY_TEXT);
The output is not entirely helpful in terms of which features are standard for which database edition. However, it does give you the crux of the information that would be used in any license audit.
A Happy Ending
Having reported her findings to the CEO, Deb persuades the company to shell out for a single Standard Edition One processor license to cover the SPIDERMAN server.
When Oracle come calling to check-up on licenses, she can fill in her spreadsheet, confident in the knowledge that the company is now fully covered in terms of Oracle licenses and there is unlikely to be any follow-up.
The CEO, who had a nasty experience with Oracle licensing at a previous company, is happy that the cost of an additional license is more than offset by the potential cost of a full license audit.
The Moral of the Story
If you’re starting a new job as a DBA , especially if you are the DBA, licensing needs to be a priority, right up there with Disaster Recovery.
Make sure you know what you’re licensed for and what database editions and features you’re running.
Also make sure you know details like the number of CPUs on the database servers themselves.
The sooner any license short-fall is identified, the sooner it can be addressed. In the long-term, the consequences of not doing so can be pretty severe.
Tags: DBMS_FEATURE_USAGE_REPORT, License Metric, Named User Plus, Oracle Database Licensing, Oracle Technology Deployment Declaration Program, Per Processor License, Standard Edition, Standard Edition One, Standby Database