SQL DBA Blog: Home

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…

read more

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…

read more

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…

read more

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.…

read more

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.…

read more

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…

read more

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…

read more

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…

read more

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…

read more

Service Broker has a cluster of internal waits around its startup, shutdown, and endpoint machinery that share one story, so this page covers them together: Are They a Problem? No. Every one of these is lifecycle or configuration machinery, active at startup, shutdown, endpoint state changes, and routing updates, and none has been a contention…

read more