If you haven’t read the first post on Server and CAL licensing this post follows that.

Processor based licensing

Processor based licensing is very simple – you purchase a license for every processor you will have installed in the server – regardless of processor affinity settings.

So why wouldn’t everyone just go with this licensing option?  Simple - price.  A processor license is significantly more expensive than a server license, and if you are going for multiple processors – be it in a single server or across multiple servers, the price can stack up.

Benefits of processor based licensing

So when does processor licensing make sense? Firstly if you don’t know how many people will be connecting to the server, or you cannot purchase CAL’s for them, you’ll need to use a processor license.  An example of this would be if you are going to host data that will be made available on a public website.

Secondly, if you have a reasonable number of users or devices and only a single CPU license, then processor based licensing might be more cost effective than purchasing CALs and Servers.  Thus processor licensing is good in some cases for database consolidation.

Gotchas

If you are considering processor licensing, there are two key things to consider.  The first I’ve already touched on – the break-even point.  Before going ahead with any SQL licensing, consider how many users you will have connecting to the server and what the licensing costs for them will be.  A rule of thumb break-even point for pricing is around 40 CALs plus one server = one processor license. However, licensing costs varies between corporate and academic organizations for example so costs will vary.  The calculations should look like this:

Server & CAL Price = Number of CALs required + Server price

Processor Price = processor price x processors in server

Of course it’s not entirely that simple.  For example with a processor license you pay the whole price up front.  With Server and CAL licensing you can grow your license count over time, which allows you to build a cost per user model that allows the solution to scale from a business ROI perspective across the organization as users come on board. 

This is quite handy for Business Intelligence for example where initially a BI solution might service only a small proportion of the organizations users now, but grow in scale over time.

The other key gotcha with processor licensing is that if you want to migrate from SQL Server Standard to Enterprise, you pay for the entire solution cost again.  If you consider that with a Server and CAL model you get to swap servers around without having to pay for CAL changes (with caveats – see my previous post) – if you are considering version migration – or if it is a possibility in the future – factor this into your decision making process.

Next we’ll cover off some scenarios and a few guidelines.