Closed pablos-here closed 1 year ago
@pablos-here You didn't specify how you're running the command, but it looks like you're running with @get_locks = 1
at a time when there are a lot of locks. That's definitely slow, and there's not a whole heck of a lot to be done about it. You can see about 17 seconds being spent just reading from the TVF source.
Instead, try this combination, and look at the additional_info
column in the output for locking details.
EXEC sp_WhoIsActive
@get_task_info = 2,
@get_additional_info = 1
Hi @erikdarlingdata ,
Thank you for the quick response!
That's like Issue submission 101: include the call signature! Sorry about that.
Yes, you're correct, I am (was?) using @get_locks=1
In fact, I'm already using @get_additional_info=1
so perhaps it was redundant that I use @get_locks=1
. I'll have a look in a bit (I have a Production issue and meetings... )
Would correlating the in-line view mentioned above resolve the issue? I don't see a specific call to a TVF but I'm assuming that's what it's mapping to ...
Thx!
@pablos-here I don't believe so. The join is written intentionally as an inner hash join, and there's no way to do that with apply, by writing OUTER HASH APPLY
or anything like that.
The TVF is what SQL Server uses internally to pull data out of its magic hat -- the operator you have highlighted in your plan has "Table Valued Function" above the data source -- they can be terribly slow in many cases.
@erikdarlingdata - got it! Thank you so much for the insight. I appreciate it.
I'll kick curbside using @get_locks=1
:)
Hi,
Our Monday's tend to be very busy. When I run sp_WhoIsActive during such busy periods,it can take upwards of 30-45 seconds for a response. Otherwise, it takes a few seconds.
I used the SQL Profiler to identify the non-performant SQL[2].
While I'm still capturing additional data, one potential area caught my eye was an in-line View[1]. It seems that we're pulling all of the [sys.dm_tran_locks] which later, we narrow to the SPIDs of interest. One thought is to correlate the query to minimize the data width pull.
I don't know if it's useful but I before Production issues took my time, I was able to get some execution plans between non-performant and performant versions of the SQL. See below.
I realize that this data is incomplete but perhaps we can get things started. I'll try to narrow it down more the next busy Monday.
1 - Potential issue?
2 - Identified SQL