Home Dashboard Directory Help
Search

Track waits in XEvents by PrinceLucifer


Status: 

Resolved
 as Won't Fix Help for as Won't Fix


1
0
Sign in
to vote
Type: Suggestion
ID: 783867
Opened: 4/16/2013 10:05:09 PM
Access Restriction: Public
0
Workaround(s)
view

Description

I have an always repeating Scenario and so far no way to tackle it:
A query is called repeatedly, works perfectly fine and fast most of the time, but sometimes just takes forever. (And unfortunately "forever" in my world starts at 100ms, so I can't work those things manually.) Now... It's relatively easy to catch those Long running queries with an XEvent session, but there is one Thing that is not easy to catch: An overview of what waits the query encountered during its execution. And that is exactly what I would Need in most cases...
Details
Sign in to post a comment.
Posted by Microsoft on 7/17/2013 at 9:44 AM
Hi Luci,

Thanks for the suggestion...but I'm afraid we won't be able to get to this in SQL 14 but perhaps in a future release.

Regards,
Richard Tkachuk
Program Manager, SQL Server
Posted by JRStern on 4/27/2013 at 5:20 PM
A couple of comments. We all have these scenarios, however many/most of them are caused by plan changes, not really waits - except for blocks, which are not officially "waits". And don't even get me started on being "blocked" by a lack of available cores for parallel plans, try to detect *those* stalls!

Even if somehow your local situation involves waits, there is no current record of waits by spid (other than the current state and last wait), only the aggregate count for the instance, so I'd guess it would require some serious inner plumbing enhancements in the engine to report on waits per session.
Sign in to post a workaround.