As pointed out you can utilize the Attention event in profiler with the events for capturing the T-SQL statements. It does not necessarily specifically state what the attention event is when I tested it so I guess the fact that it follows the event sequence you can estimate those queries that have an issue. I did not get a chance to full test it out with code and all.
I did however come across an exact example with Extended Events that can be used to find timeout queries, and this example is with SQL Server 2008. It is from Jonathan Kehayias: An XEvent a Day (9 of 31) – Targets Week – pair_matching
Timeout errors are client side and the error is coming from the provider (or client) being used with the database connection. SQL Server does not necessarily keep track or offer any intuitive method to track these down.
Using a trace, timeouts on SQL Server side are basically queries that have a start but no completion. Which I came across a very good video that walks through an example from Sean McCown Find query timeouts with Profiler. Now it is not rock solid evidence as Sean notes in the video there are other things that could cause a transaction to not have an ending.
A synopsis of the steps:
- Create a trace in Profiler that captures the start and completed events for Stored Procedures and TSQL
- Load that data into a table
- Query that data to find the start events and then end events.
As the example goes in the video for
SP:Starting (44) and
SP:Completed (43) once you get your trace data into a table:
WHERE EventClass = 44
WHERE EventClass = 45
I would expect this might be easier to do with Extended Events but have never tried to transfer this method over to Extended Events. I am not sure if SQL Server 2008's version of Extended Events opened up access to client level errors as 2012 and higher does. The above is just a quick and dirty method that still works.