Category: Wait Types

CLR_MANUAL_EVENT is recorded when a task performing CLR execution waits for a manual-reset event to be signalled. In practice it is mostly CLR worker threads standing by for work, the manual-reset sibling of CLR_AUTO_EVENT, and it appears wherever CLR integration is active, including through the engine’s internal CLR use (spatial types, hierarchyid, and friends). Idle…

CLR_AUTO_EVENT is recorded when a task running Common Language Runtime (CLR) code waits on an auto-reset event, which in practice is mostly CLR worker threads waiting for something to do. If CLR integration is enabled, and several built-in features use it internally even when you never wrote a .NET assembly, these threads exist and mostly…

Four waits cover CLR assembly loading and task startup, and this page covers them together: Together they describe .NET code arriving and getting under way inside the engine. Are They a Problem? Rarely; none has been a contention point in normal use. Assembly loading clusters at first use and after appdomain reloads, so bursts of…

CHKPT is recorded at instance startup while the background checkpoint process initialises and waits for the signal that it can start. It happens once per instance start, and that is the whole story: one wait, at boot, ever. Do not confuse it with CHECKPOINT_QUEUE (the checkpoint process idling between requests, continuous) or SLEEP_BPOOL_FLUSH (checkpoint throttling…

CHECKPOINT_QUEUE is recorded by the background checkpoint process while it sits idle, waiting for the next checkpoint request to be placed on its queue. Between checkpoints there is nothing for it to do, so the wait accumulates continuously through the instance’s life. Manual CHECKPOINT commands bypass this queue entirely, so they never touch this wait.…

CHECK_TABLES_THREAD_BARRIER is recorded when a parallel thread in a DBCC CHECKDB (or related) command waits at a barrier for its sibling threads, either while they finish initialising, or while they finish exiting after certain unexpected errors terminate the command. Every parallel DBCC run produces some of it; barriers are how the workers stay in step.…

CHECK_TABLES_INITIALIZATION is recorded when a parallel thread belonging to a DBCC CHECKDB (or CHECKTABLE/CHECKFILEGROUP) command initialises and has to wait on a mutex that another initialising thread currently holds. Parallel DBCC spins up a set of worker threads at the start of each check, and they take turns through this small critical section while setting…

BROKER_TRANSMITTER is recorded when the Service Broker transmission queue is empty and the two internal transmitter threads (the ones that send messages to remote endpoints) wait for work. Two threads waiting simultaneously gives this wait its arithmetic signature: the total grows by roughly two seconds every second while Service Broker is idle. Every instance carries…

BROKER_TRANSMISSION_WORK is one of the sparsely documented Service Broker waits; the best available understanding is that it behaves like BROKER_TRANSMITTER, threads in the message transmission machinery waiting for transmission work to become available. It sits in the same family as the transmission-object housekeeping waits. Where documentation is thin, behaviour is the guide, and its behaviour…

BROKER_RECEIVE_WAITFOR is recorded when a session has issued a WAITFOR (RECEIVE …) against a Service Broker queue and is waiting for a message to arrive. Queue readers are designed to block until there is work, so on a quiet conversation this wait can legitimately run for hours. If you use Service Broker (or features built…