Which would you rather do, wade through the nuances of SQL Server licensing or a typical tax form? Some days, I think the latter would be a welcome respite. Let’s just put it this way, I bet Brent Ozar (BrentO on twitter) is happy that licensing wasn’t the biggest part of the MCM grade. (I don’t know this, I just presume it because people actually pass the MCM every once in a while).
Common SQL Server Licensing Myths
The people in this maze might be better off than us.
I am going to talk about some of the more common myths I’ve encountered with licensing throughout my career and consulting. Microsoft has some decent SQL Server licensing resources including some PDFs (some short and some nearing legislation size with flowcharts abound). This quick guide is a good start to look at. Which brings me to a disclaimer:
This blog post does not replace your own research and understanding of licensing guidelines from Microsoft. The thoughts presented here are my own and represent my views of Microsoft licensing guidelines and my interpretations thereof. My perspective has the potential to be wrong (I’m a husband, so I’m likely wrong, come to think of it 
) and could become outdated with future changes. Check with Microsoft and your licensing representative to make any final decisions.
On to the myths I encounter…
You Need Enterprise
Look at the edition feature matrix for your version (2008, 2008 R2, 2005) and see what you need and anticipate needing – it can save you around $15k + per CPU to go with Standard over Enterprise. I have commonly bumped into people believing that they need enterprise licenses when they don’t when it comes to things like:
- Log Shipping (Standard is fine)
- Clustering (You can have a single instance two node cluster on Standard)
- Mirroring (Some types are allowed in Standard)
In fact, this post was inspired recently when I was able to see a project at a company to roll out Enterprise Edition simply because of Log Shipping. No other enterprise features needed. This company had great pricing on Standard and I was able to save them almost $60,000 in Enterprise licenses they didn’t need. Wait. There’s more! Act now and you can save even more because another myth sounds like this:
You Need To License Your Mirrored Copy Also
In most situations (yours may be different, double check), a DR standby (For mirroring or log shipping) doesn’t need to be licensed by default. Now there are certain triggers (pardon me) that will hit you with a license cost (Being failed over to it for more than 30 days or reporting off of a snapshot of the mirror, for a couple examples) but by default, many simple options don’t. This same company had an Enterprise License purchase (single CPU) for the fail over site. Another $19,000 saved with no standard license even needed because that instance can sit there “unlicensed”.
I Can Put SSAS, SSRS and the DB Engine anywhere…
You can. And, as a best practice in busier environments I’d say you should. But you can’t do it for nothing. You can put them all on the same box and they will be licensed as though you just had one (under most circumstances). The moment you split them out (again, generally a best practice for performance) you must license each component separately. While I’ve saved some companies money, here I’ve cost some money… Sorry. I don’t like it either but it is what it is.
Multiple Instances Still Means Multiple Licenses
I hate typing this because just as soon as I do, I am sure some pointy headed boss someplace will say, let’s consolidate every instance onto one machine! Don’t do that. But this myth isn’t true – you pay by the CPU by the machine. If you have two instances on one machine each using 2 CPUs, you only need one 2 CPU license. Add another instance to it? Same thing, no new license, you pay by the machine not the instance. This is great and can really help save some license expenses at smaller shops but just do so carefully as I wrote when I first drafted this SQLServerPedia wiki article on multiple instance decision making.
SQL Server Licenses Are By Core, Like Oracle
Or at least like Oracle was last time I checked… SQL Server (today.. I don’t know of anything changing, but you never know) licenses by the socket. By the actual die that goes into the socket. Not by the core or thread. So you can have a Quad core proc with hyperthreading that looks like 8 CPUs in perfmon but you are paying for a single CPU license. This is good to know. Might make that hardware upgrade more worthwhile. Who knows how long this will last and, for all I know, maybe it is gone by the time you read this, so double check yourself.
Virtual Server Licensing Works Just Like Physical
I’m not going to say anything except to say this isn’t necessarily true. There are all sorts of scenarios and differences depending on if you are using standard or enterprise. The IRS has a hotline (800-829-1040). So does Microsoft, if you aren’t sure it may be worth a call or e-mail.
Developer Edition Works for All Developers
Well that may be true most of the time. Your developers could probably use developer edition but keep a few things in mind: 1.) Did you pay for it? Or is it just a download everyone shares? If you are covered by MSDN (For each developer who touches the instance) or some sort of enterprise agreement then you may be fine. If you paid for the product and a proper license you are fine for the intended use in the agreement. If not, you aren’t. But also – consider this: What is production going to be? If your production environment is standard, do you necessarily want the product developed and tested on developer edition, which is Enterprise Edition by features, Developer edition only be price tag and EULA?? There may be a reason (especially if you have MSDN licenses for each developer, a good investment typically) to make sure an app is developed and tested in something other than Enterprise. Consider the end goal and end edition. It would stink to see Dev and QA using Developer and relying on some enterprise feature that never failed a test only to find a deploy gone wild.
Licensing, Just Like SQL Server, Is Set-It-And-Forget-It
No. No to both. Depending on your agreement with Microsoft the day may come when they come to do a true up of your environment. They will discover your SQL instances with you and verify you are using what you purchased. If you haven’t you’ll be buying more licenses and you are in violation of laws and software agreements. You could face fines as a company or a individual, potentially. An answer? Do your own True Ups. Awhile ago I blogged about using the Microsoft Assessment and Planning Toolkit (MAP) to discover your SQL instances. The report it spits out shows you all sorts of great details (server name, edition, version, CPU count, etc). Do your own true up, no reason you can’t. Are you in line? If not fix it by adding licenses or consolidating and saving the company hard earned cash (“Hey, boss, I just want 1%…”)
Summing It Up
A simple look at a few of the more common myths I bump into around licensing. They can all be summed up with the same advice, do your homework, understand the license agreements with factual information (not someones recollection or interpretation) and always double check. Even if the information comes from a trusted vendor (you know how I feel about that), you could be breaking the law or throwing away company money. Neither are great career advancement moves.
What about you? Do you have a licensing horror story? A tip for someone else out here. Leave it in the comments or blog about it and let us know when your post goes up, I’ll be more than happy to link to any tips to help folks avoid making a mistake up front.
So I used a simple random name generator and let the bits and bytes select and they selected Jordan. Jordan is active in his local SQL Server community and always striving to learn and apply new technologies or aspects of his career, so the randomizer made a good choice on its own criteria.
