Licensing Logic: Licensing SQL Server, Everything You Need to Know!

An illustration depicting how containers work, with a picture of Bit the Raccoon on the right.

Part of the Microsoft Licensing Logic series from the Microsoft Licensing team.

Just when you think Microsoft licensing is straightforward and you’ve got a pretty good grasp on it, along comes SQL Server which has historically been the exception to the licensing rules. However, with SQL Server 2012 we did a great deal of simplification so it’s easy to understand the basics. You’re going to approach licensing differently depending on whether you’re deploying SQL Server in a physical or virtual environment.

 

SQL Server Licensing in a physical environment.

SQL Server is available is three main editions; Standard, Business Intelligence and Enterprise. The Enterprise edition is licensed per core (no CALs required), Business Intelligence is licensed per server and client access licence (CALs) and the Standard edition can be licensed using either method. This is summarised below and hasn’t changed with the April 1st release of SQL Server 2014.

Various editions of SQL Server 2012

Before I present a little flowchart which might make your decision easier, let me clarify a few things about per-core licensing. We are talking per-core here and not per-physical processor, unlike Windows Server 2012. Currently SQL Server 2012, SQL Server 2014 and BizTalk Server 2013 are the only products licensed per-core.

To find out the appropriate number of cores you need to licence, simply count the number of cores in each physical processor in the physical server. Software partitioning doesn’t reduce the number of cores you need to licence. Once you have that you need to remember three things:

  1. You need a minimum of four core licences per processor. So if you have a dual-core, dual-processor machine you would need to count that server as a dual, four-core processor and purchase licences for eight cores, despite only having four cores in total.
  2. SQL Serve core licences are sold in packs of two: each SKU covers two processors. So in our example above we would purchase four SQL Core licence SKUs to cover eight cores.
  3. Certain AMD processors need to have a multiplication factor of 0.75 applied to the core count. See this link for the processors in question and what to do.

For server and CAL, SQL Server works in the same way as any other Microsoft server + CAL product. Licence the server(s), determine the number of unique users and/or devices accessing the SQL Server and purchase the appropriate number and type of CALs. SQL 2014 CALs will allow access to all previous versions of SQL Server. Also you don’t require a separate CAL for every SQL Server; a SQL Server 2014 CAL allows access to all the SQL Servers within the organisation.

A simple way of determining the edition and licensing of SQL Server 2012 and SQL Server 2014 is below.

A flow chart to determine which edition of SQL Server 2012 to use

 

SQL Server Licensing in a virtual environment.

Regular readers of the licensing blog will be saying “I bet this has something to do with Software Assurance (SA)”. Well, you’re partly correct. I’m going to assume you’re running Windows Server 2012 Datacenter edition on these boxes just for simplicity and I haven’t included details of the OS running in the Virtual Operating System Environment (VOSE). Licensing Windows Server has been covered in a previous blog.

For SQL Server Standard and Business Intelligence editions you can licence individual virtual machines (VMs) using the server + CAL model. Simply purchase one server license for each VM running SQL Server software, regardless of the number of virtual processors allocated to the VM. Then purchase the appropriate number of CALs.

For example, a customer who wants to deploy the Business Intelligence edition running in six VOSEs, each allocated with four virtual cores, would need to assign six SQL Server 2014 Business Intelligence server licences to that server, plus the CALs to allow access.

For SQL Server Standard and Enterprise editions you can licence individual VMs using the per-core model. Similar to physical OSEs, all virtual cores supporting virtual OSEs that are running instances of SQL Server 2014 must be licensed. Customers must purchase a core license for each virtual core (aka virtual processor, virtual CPU, virtual thread) allocated to the VOSE. Again, you are subject to the four core minimum, this time per VOSE. For licencing purposes, a virtual core maps to a hardware thread. When licensing individual VMs, core factors (i.e. the AMD processor 0.75 factor) do not apply.

Two examples are shown below (figure 1 and figure 2) for clarification.

A diagram showing SQL Server core licences required for a single VOSE on a dual, four-core processor server.Figure 1: (above) SQL Server core licences required for a single VOSE on a dual, four-core processor server.

A diagram showing SQL Server core licences required for two VOSEs on a dual, four-core processor server.Figure 2: (above) SQL Server core licences required for two VOSEs on a dual, four-core processor server.

 

With the SQL Server 2014 Enterprise edition (note: not Standard edition), if you licence all the physical cores on the server, you can run an unlimited number of instances of SQL Server, physically or virtually as long as the number of OSEs with SQL doesn’t exceed the number of licensed cores. For example, a four processor server with four cores per processor provides sixteen physical cores. If you licence all sixteen cores, you can run SQL Server in up to sixteen VOSEs (or the physical OS and 15 VOSEs), regardless of the number of virtual cores allocated to each VM. What if you want to run more than 16 VOSEs in this case? Well, you are permitted to assign additional core licenses to the server; this is known as licence stacking.

Here’s where Software Assurance comes into play. Licence all the physical cores with SQL Server 2014 Enterprise Edition and software assurance and your licence rights are expanded to allow any number of instances of the software to run in any number of OSEs (physical or virtual). This SA benefit enables customers to deploy an unlimited number of VMs to handle dynamic workloads and fully utilize hardware computing capacity. As with most SA benefits, this licence right ends if SA coverage on the SQL core licences expires.

Licensing for maximum virtualization can be an ideal solution if you’re looking to deploy SQL Server private-cloud scenarios with high VM density, Hyper-threading is being used so you’re looking at a lot of virtual cores to licence, or you’re using dynamic provisioning and de-provisioning of VM resources and you don’t want the headache of worrying about adjusting the licence count. As you can see in figure 3 (below) this can be very cost-effective.

A diagram showing Options to licence SQL Server Enterprise in a virtual environment.Figure 3: (above) Options to licence SQL Server Enterprise in a virtual environment. In the top example you would need 8 core licences + SA for unlimited virtualisation whereas in the bottom example you would need 10 core licences and still be limited in the number of SQL VMs you could run.

What’s new in Licensing for SQL Server 2014?

Just two subtle changes: one for high availability scenarios and the other for multiplexing with SQL Server Business Intelligence edition.

The rights to install and run a passive fail-over SQL Server have now moved to be a Software Assurance Benefit. This is a licence right for SQL 2012 and earlier with the license terms listed as an exception under each SQL edition to which it applies. With SQL 2014 the fail-over servers terms will move to the Software Assurance Benefits section and thus only apply to SQL covered with SA.

The second update is for Business Intelligence Edition. We’re relaxing the multiplexing policy so it no longer requires a CAL for users or devices that access the BI server