Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
BROKER_TRANSMISSION_TABLE is recorded when a thread waits on the process of writing inactive transmission objects, the in-memory structures tracking message transmissions per Service Broker dialog, out to a tempdb worktable to save memory. It shares this housekeeping territory with BROKER_TO_FLUSH (the lazy flusher’s own timer) and BROKER_TRANSMISSION_WORK.
Memory-management plumbing for Broker’s bookkeeping, in short.
Is It a Problem?
No; it has not been a contention point and is safely filtered. Its amounts track how many Broker dialogs exist and go inactive, which is a workload shape rather than a fault.
The related hygiene topic worth actual attention on Broker systems is conversation leaks: dialogs that are never properly ended accumulate forever, bloating the transmission bookkeeping these waits manage. If Broker memory or tempdb usage creeps, count conversations before blaming the flusher.
Common Causes
- Normal spill of inactive transmission objects to tempdb on Broker-active instances.
- Many dialogs cycling between active and inactive.
What To Do
- Filter it from wait analysis.
- Audit conversation hygiene on real Broker workloads:
sys.conversation_endpointscounts, and make sure application code ends conversations on both sides. - Nothing to tune in the flusher itself.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered with the other Broker housekeeping waits.
Leave a Reply