Zoomed Image
USA
800 691 9120
UK
01225 704844

SQL Server Licensing

Software Asset Management Guide
Concepts

SQL Server Licensing

SQL Server is licensed per host (physical server or VM), not per instance. Two instances running on a host share the same per-core entitlement.

How SQL Server Per-Core Licensing Works

For SQL Server Standard and Enterprise editions on a physical server, you license all the physical cores on the server. Once licensed, you can run any number of instances on that hardware without buying additional licenses.

For SQL Server on a virtual machine, you license all the virtual cores allocated to the VM. Multiple instances within the same VM share the licensed cores.

Scenario Cores To License
Physical 8-core server, one SQL Standard instance 8
Physical 8-core server, two SQL Standard instances 8 (same hardware, same license covers both instances)
Physical 16-core server, one SQL Enterprise instance 16
4-vCPU VM, one SQL Standard instance 4 (subject to CORE4 minimum, see below)
4-vCPU VM, three SQL Standard instances 4 (same VM, same license covers all instances)

The unit of consumption is the host (or VM).

How xAssets Models This

In the asset register, a SQL Server installation is represented as:

  • The host asset — the physical or virtual server, with its CPU and core count
  • One or more SQL instance assets — child records linked to the host via AssetDependency of type SQL Instance, used for visibility and inventory purposes

The instance records are inventory metadata. They tell you which SQL versions and editions are running on which host. The licensing calculation operates at the host level: one consumption per host that has SQL Server installed, sized to the host's core count.

This means:

  • A host with two SQL Standard instances generates one consumption sized to the host's cores
  • The instance records help you answer "which servers run SQL 2017 Standard?" but do not multiply consumption

CORE4 — The 4-Core Minimum

SQL Server licenses sold through Microsoft Volume Licensing have a 4-core minimum per server, which xAssets models with the CORE4 license type. A 2-core VM running SQL Standard needs 4 cores of license, not 2 — the minimum kicks in.

Set the license type to CORE4 (not plain CORE) when you have purchased through Volume Licensing or Microsoft Partner channels. The engine applies the floor automatically.

The same pattern exists for CORE8 (e.g., Windows Server Datacenter) and CORE16.

Free Editions

SQL Server Developer and Express editions are typically classified as Free in the recognition database. They generate consumptions but not grants and do not appear in compliance numbers.

When investigating SQL footprint, distinguish paid editions (Standard, Enterprise, Web) from free editions (Developer, Express). The catalog should list each edition as a separate product so the position reflects only paid editions.

Discovering SQL Instances

SQL instances are picked up by Network Discovery's SQL Server probe. The probe queries the host for SQL Browser data and registry entries and creates the instance child assets.

If you have SQL hosts that are not showing instance children:

  1. Confirm SQL Browser is running on the host (or its registry entries are accessible).
  2. Check the asset's discovery log for SQL probe results.
  3. Verify the host's discovery agent has credentials with permission to read the SQL registry keys.

The License Dashboard → Sql Server menu has dedicated dashboards for SQL-specific compliance views.

In the Licensing Position

SQL Server compliance is sensitive to:

  • Correct host core counts. A host whose CPU was upgraded but whose CPUCores value was not refreshed will under-report.
  • CORE4 vs CORE selection. Volume-licensed environments need CORE4 for Standard/Enterprise; retail or hosted environments may use CORE depending on the contract.
  • Mixed editions. Hosts running multiple editions (e.g., Standard and Developer) need each consumption metered against the correct edition's catalog entry.

Always recalculate after a hardware refresh or discovery rerun in a SQL-heavy environment, and verify the host core counts match reality.

High Availability, Clustering, and Disaster Recovery

SQL Server licensing for HA and DR scenarios is one of the most common audit triggers. The contractual rules from Microsoft are nuanced and depend on whether you have Software Assurance:

Scenario Microsoft Rule (with SA) Microsoft Rule (without SA)
Active / passive cluster Passive node free for failover Both nodes need licensing
Active / active (load-balanced) cluster Both nodes need licensing Both nodes need licensing
DR cold standby Free for the SA term Needs licensing
DR warm or hot standby Free for the SA term Needs licensing
Mirror / log shipping target Same as the appropriate scenario above Same as the appropriate scenario above

xAssets discovers each cluster node as its own asset with its own SQL instance children. The engine treats each one as a consumption that needs covering. The engine does not automatically apply the SA passive-node exemption — it counts every instance it sees as needing capacity.

If you have HA/DR scenarios with SA, the practical options are:

  1. Set the passive node's SQL instance status to Out of Service when not actively running. The engine stops counting it but you keep the asset record for inventory.
  2. Direct-assign a license with zero true cost to the passive node to suppress the deficit, with notes explaining the SA exemption.
  3. Filter passive nodes out of the compliance position by tagging them and adjusting the report query.

None is fully automated — SA passive-node licensing is a contractual interpretation rather than a metered fact. Document the approach you take so the audit trail is defensible.

For DR scenarios, the same logic applies but on a longer timescale: a cold-standby DR instance that runs only for testing and actual failover events should not consume an active license, but xAssets will count it as installed unless you take it out of service or otherwise mark it.