Voted Best Answer
May 08, 2016 - 02:29 PM
You can find the licensing brief here: https://www.microsoft.com/en-ca/Licen...
In order to Manage SQL, you need to understand what usage rights are applicable based upon which version and edition you are using.
You will also need to understand the licensing metrics for ( as of April 2016) SQLServer 2014; any unlicensed versions of SQLServer need to be 'true-up' 'd ( is that a word?) based upon current version and NOT the version that happens to be 'under' licensed.
As far as the datapoints go, *in general* you need to determine the number cores and/or Procs of the device where SQLServer is running.
You also need to understand if the 'device' is virtualized (VM); if so then you need to understand the cores & procs of the hosted 'OSE' ( operating system environment)
If that hosted OSE is part of a 'data center', then you need to understand if 'high mobility' is activated ( that allows the datacenter to move the VM from one host to another for load balancing), then you need to determine the re-location rate of the VM ( some licensing parameters allow re-location eery >90 days at no extra cost)
THEN you need to understand if that data center is part of a Server Farm, and if that Server Farm expands a geography > 4 time zones or outside EU or EFTA Time zones. ( though I would consider this outside 'minimum' requirements as it is outside MOST client's operating expectations)
Then you need a method to determine if 'solo' instances of SQLServer Integration Services and SQLServer Reporting Services exist ( these two products are included with SQLServer and are 'included', but if they are installed 'independantly' then they need to be licensed as if they were SQLServer!)
Then you need a method to declare the relevant non-production states (hot-backup, cold-backup, testing, development, staging, etc) as your licensing allows you to use. Accordingly, you also need a method to declare MSDN deployments of SQLServer as well as 'OEM/bundle' usage of SQLServer ( some Microsoft products actually come with SQLServer 'included')
Then you need a method to declare and re-concile both user and device CALs, if your licensing has CAL purchases.
Then you need a method to 'transform' the historical purchases ( including Proc to Core grants that happened a few years ago, and the time-base SA 'grants' - whether included within EA or separately acquired via 'Select') into effective 'Entitlements'.
Yes, there's more beyond the 'minimum ( such as SQLServer HPC edition, and the fact that the first wave of SQLServer 2012 is hard-coded to NOT use more than 20 cores!), but the FOCUS of what type of data to collect should be driven by first understanding what applicable licenses you have accumulated over the years. For example, having 'Software Assurance' for SQLServer equates to 'all you can eat' on the time restrictions on 'high mobility' load balancing.
So, SQLServer licening needs to 'deliver' the above inventory requirements, Purchase => Entitlement transformations, and manually declared 'exemptions' ( non-production usage rights) in order to get 'into the ballpark' on SQLServer licening.
At AssetLabs, we consider SQLServer licensing to be a 'non-linear, sequence-centric' calculation where the inventory parameters are dependant upon the Entitlement 'capacities' and their sequence of how they are applied against the inventory.
In other words,
iIt's a lot like doing a 5-star soduko, where there may be more than one-way to solve it, but only one 'sequence' is the best from a time POV.
And for those of you who love Soduko, then consider SQL Licensing as Soduklo.... in braille .... on a moving bus.