SQL DBA Blog: Home

SOS_SYNC_TASK_ENQUEUE_EVENT is recorded when a task is started synchronously: the starting thread enqueues the task on an SOS node and waits for it to actually begin running (or for the enqueue to time out). Most task starts in SQL Server are asynchronous, control returns immediately once the request is queued, so the synchronous variant is…

read more

SOS_WORK_DISPATCHER is recorded by a SQLOS worker thread that has become idle and is waiting to be handed something to do. The wait starts when the thread runs out of work and ends when the dispatcher assigns it a task. It arrived with scheduling improvements in SQL Server 2019 and is ever-present on Azure SQL…

read more

SOS_WORKER_MIGRATION appears to track a worker (thread) being moved to a different scheduler. It arrived with SQL Server 2019’s scheduling improvements, which allow a worker at the head of one scheduler’s runnable queue to migrate to another scheduler within the same NUMA node, smoothing out imbalances where one scheduler queues work while a neighbour idles.…

read more

SP_SERVER_DIAGNOSTICS_SLEEP is recorded by the background system health monitor thread while it sleeps between runs of sp_server_diagnostics, the built-in health check procedure added in SQL Server 2012 to power automatic failure detection for Availability Groups and failover clusters. The procedure runs on a fixed cadence; this wait is the gap between runs. Every instance from…

read more

SQLCLR_APPDOMAIN is recorded while CLR execution waits for an application domain to complete startup. SQL Server hosts .NET code in appdomains (one per database/owner combination, broadly), and the first CLR call after an appdomain has been created, or recreated, pays the startup cost. Sessions arriving during that startup wait here. Steady state, appdomains stay loaded…

read more

SQLCLR_ASSEMBLY is recorded while a thread waits for access to the list of loaded assemblies in an appdomain. When CLR code runs, the host tracks which assemblies are loaded per domain, and threads consulting or updating that list briefly serialise on it. It is bookkeeping inside the CLR hosting layer, adjacent to SQLCLR_APPDOMAIN in the…

read more

Four waits cover SQL Trace’s file-writing machinery, and they share one story, so this page covers the set: Since the default trace runs on practically every instance, small amounts of the family are universal. Are They a Problem? Rarely; none has been a noticeable contention point. The family scales with trace activity: the default trace’s…

read more

SQLTRACE_INCREMENTAL_FLUSH_SLEEP is recorded by a background thread sleeping between checks for SQL Trace data that needs flushing to a trace file. Because the default trace runs on practically every instance (it is the lightweight always-on trace that records events like file growths and DDL), this thread exists and sleeps everywhere, accumulating wait time around the…

read more

TERMINATE_LISTENER is recorded when a thread waits for a SQL Server Network Interface (SNI) listener to be destroyed. SNI is the protocol layer wrapping TDS packets over whatever transports are configured (TCP, named pipes, shared memory), and listeners get torn down during instance shutdown, endpoint reconfiguration, and network setting changes. A teardown marker from the…

read more