What’s the issue?
SQL Server creates one scheduler for each logical processor it can see at startup. Each scheduler is responsible for managing worker threads on its assigned CPU. When a scheduler is in the VISIBLE OFFLINE state, it has been recognized by SQL Server but is not being used to run user queries.The most common cause is licensing limits in SQL Server editions. Standard Edition is capped at 24 cores (32 cores in SQL Server 2025) or 4 sockets, whichever is lower. Web Edition (no longer available in SQL Serer 2025) is capped at 16 cores, and Express Edition is capped at 4 cores. When a SQL Server instance is installed on a host with more cores than the edition allows, the extra cores show up as VISIBLE OFFLINE schedulers.
Other causes include the affinity mask setting being configured to exclude specific CPUs, or the use of soft NUMA configurations that intentionally take certain schedulers offline.
Why is this a problem?
The most immediate issue is wasted hardware capacity. A server purchased and provisioned with 32 cores running SQL Server Standard Edition will only use 24 of them, leaving the remaining 8 cores idle from SQL Server’s perspective while still being licensed at the operating system level and consuming hardware budget.This can go unnoticed for years because the server appears to have plenty of CPU available in Windows Task Manager and other operating system level monitoring, while SQL Server itself is constrained to a smaller subset. Performance investigations may focus on tuning queries or adding memory when the real bottleneck is artificial CPU restriction.
There is also a risk of confusion during troubleshooting. Wait statistics, scheduler related queries, and CPU pressure indicators can be misleading when only some schedulers are active, and administrators unfamiliar with the licensing limits may misdiagnose the symptoms.
Just as importantly, paying for hardware that SQL Server cannot use is a direct cost issue. The licensing decision and the hardware decision should be aligned, but in practice they often are not, particularly when virtual machines are sized generously without considering edition limits.
What should you do about this?
Identify the situation by querying sys.dm_os_schedulers and counting rows where status = ‘VISIBLE OFFLINE’. Compare the total scheduler count against the host’s logical processor count and the edition limits documented by Microsoft to confirm whether licensing is the cause.If the offline schedulers are due to edition limits, the remediation depends on the workload’s actual CPU needs. If the workload genuinely needs the additional cores, upgrade to an edition that supports them (typically Enterprise Edition, which has no core limit) and the schedulers will come online after the next service restart. If the workload does not need the cores, consider downsizing the host, reducing the virtual machine’s vCPU count, or consolidating other workloads onto the unused capacity to reclaim value from the hardware.
If the offline schedulers are due to an affinity mask configuration, review whether the affinity setting is still appropriate for the current workload, since affinity is rarely needed on modern hardware and is often a leftover from older performance tuning advice. Reset affinity to the default with EXEC sp_configure ‘affinity mask’, 0; RECONFIGURE; unless there is a documented reason to retain it.