Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In SQL Server 2008 I created a Sql Server Agent Alert last week to monitor deadlock events. The Alert calls a job with no schedule sending the xml deadlock graph token obtained through WMI SELECT * FROM DEADLOCK_GRAPH. The job calls a SP that stores the graph and an email is sent.

I have been monitoring the Sql Server Waits and have found that after I implemented the alert described above, the wait categories for BROKER_TASK_STOP and SQLTRACE_WAIT_ENTRIES have sky rocked. Those values went from not even being on the radar to contributing 42.59% and 5.11% of total waits respectively.

Should I be concerned? I read somewhere that high BROKER_TASK_STOP's may not be of real concern.

share|improve this question
up vote 1 down vote accepted

These two wait types are excluded from Paul Randal's wait stats analysis query, and he is far more of an authority than me.

I would not be concerned about these, and exclude them from your analysis.

share|improve this answer

These are both 'friendly' waits and nothingbtonworry about from a performance perspective. They mean that threads are sitting there waiting for work to be assigned. You should filterboutw these and other friendly waits from your wait stats queries. Many have blogged about which waits to exclude, including SQLRockStart, here -

share|improve this answer
Thanks for the info! – lrb Oct 9 '12 at 17:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.