How to Check What SQL Server Licensing You Are Actually Using

SQL Server licensing can’t be proved by a query alone. Identify the installed edition and visible processors, then compare that evidence with deployment records and purchased rights.

Separate Installation From Entitlement

The engine knows its edition and build. It doesn’t know which agreement your purchasing team signed or how licenses were assigned. Start by recording the installation. Treat that result as one part of the evidence, not the final answer.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('EngineEdition') AS engine_edition;

An edition string containing a licensing label doesn’t establish compliance. It also doesn’t identify every right attached to Software Assurance or a subscription. Those come from records outside SQL Server. Keep the technical inventory and purchasing evidence together so the same installation is being discussed.

First decide which model applies. SQL Server offers per-core licensing, while Standard also has a Server plus CAL model. User access matters differently under those models. Don’t start multiplying a CPU count until you know which question that multiplication is supposed to answer.

Ask What the Guest Can See

SELECT
    cpu_count, scheduler_count, socket_count,
    cores_per_socket, hyperthread_ratio,
    virtual_machine_type_desc
FROM sys.dm_os_sys_info;

These columns describe the environment exposed to SQL Server. They are useful when reconciling a machine inventory. In a virtual machine, the guest sees the virtual topology presented to it. It doesn’t provide a trustworthy inventory of every physical processor in the underlying host.

Hyperthreading adds another reason not to equate logical processors with physical cores. A visible CPU count isn’t a universal license count. Get the physical topology from the infrastructure owner when licensing the host. Get the assigned virtual resources when licensing individual virtual environments.

The query needs the appropriate server visibility permission. On SQL Server 2022 and later, that includes VIEW SERVER PERFORMANCE STATE. An account with insufficient permissions gives you an access problem, not evidence that the server has no processors.

Check the Licensing Boundary

Under Microsoft’s current SQL Server 2025 guidance, physical per-core licensing counts physical cores with a minimum per processor. Individual virtual environment licensing counts virtual cores with a minimum per environment. The published minimum is four in each respective case. Apply the exact agreement and deployment terms.

Current virtual environment licensing also depends on Software Assurance or subscription eligibility. Mobility and virtualization benefits have their own conditions. A count copied from an older guide can miss those differences. Keep the guide’s version and your agreement date with the calculation.

Don’t substitute Windows Server licensing rules for SQL Server rules. Both products mention cores, but the details aren’t interchangeable. If another team licenses the operating system, that doesn’t mean the database engine has automatically been covered too.

Visible Schedulers Are a Different Measurement

SELECT
    status,
    COUNT(*) AS scheduler_count
FROM sys.dm_os_schedulers
GROUP BY status
ORDER BY status;

Scheduler counts help explain how SQL Server is using the resources it sees. They can reflect engine limits or configuration. They aren’t a receipt for those resources. Restricting affinity doesn’t automatically reduce a license obligation that is defined at a different boundary.

This distinction matters during consolidation. An administrator can make an instance use fewer processors while the licensed physical server remains unchanged. Record why the configuration exists. Then have the licensing owner apply the relevant terms instead of treating the configuration as a purchasing rule.

Include the Instances You Forgot

Look beyond the primary application server. Disaster recovery, reporting, test installations, and additional virtual machines need classification. Some rights cover particular passive scenarios under specific conditions. Don’t assume that every server with no current users qualifies as passive.

SELECT
    name, state_desc, is_read_only,
    recovery_model_desc
FROM sys.databases
ORDER BY database_id;

Database state helps describe the installation, but it doesn’t settle the workload’s business purpose. A read-only database can serve an operational report. A stopped application can return next week. Ask the owner what runs there, who uses it, and what the environment is meant to do.

Build a Record You Can Reconcile

Create one record per deployment with the server identity, edition, topology evidence, and workload purpose. Add the assigned licenses and the person who confirmed the interpretation. Include the host mapping for virtual machines. Without that mapping, two teams can count different boundaries while believing they agree.

Review the record when processors, hosts, or deployment roles change. Keep the old evidence so the change is explainable. I prefer a small inventory that stays current over a beautiful spreadsheet nobody trusts after the next migration.

When a case is unclear, bring the gathered evidence to your licensing specialist or Microsoft partner. Ask about the specific configuration and agreement. The queries make that conversation concrete. They should never be presented as a substitute for the terms that govern your installation.

A CPU query is not a license audit, it is evidence for one.

This post was rewritten from scratch in September 2026. The original, published on 2013-09-08, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.