Collect both DBM active sessions and blocking sessions which are sleeping #14054
Conversation
ghost
added
the
justiniso
changed the title
|
Label |
| @@ -68,7 +73,8 @@ | |||
| INNER JOIN sys.dm_exec_requests req | |||
| ON c.connection_id = req.connection_id | |||
| CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) qt | |||
| WHERE sess.session_id != @@spid AND sess.status != 'sleeping' | |||
| WHERE sess.session_id != @@spid | |||
| AND (sess.status != 'sleeping' OR sess.session_id IN (SELECT blocking_session_id FROM cteBlocking) OR isnull(req.blocking_session_id, 0) <> 0) | |||
There was a problem hiding this comment.
I think if we looked in the active transactions table this might be a tad bit faster (would be a smaller DMV table)
if a thing is blocking, in a sleeping state I believe it should always show up there
There was a problem hiding this comment.
But would it be possible to have a blocking session not in a transaction? Not sure those would be functionally equivalent.
But I do believe in the idea that we should collect all processes with an active transaction; that seems like a better improvement overall.
There was a problem hiding this comment.
But I do believe in the idea that we should collect all processes with an active transaction; that seems like a better improvement overall.
It would make sense to collect long lasting transactions, especially for inactive sessions - that's usually suspicious, regardless of whether the session is currently blocking anyone. We could implement it as a separate metric.
But would it be possible to have a blocking session not in a transaction?
Yes, in the isolation level where the reader is blocking writers. That's the default setting in on-prem SQL Server.
The new query wit cte looks suspiciously fat, especially if we decide to increase the sampling frequency one day. I addressed the issue of idle blocker for Oracle (https://docs.google.com/document/d/1NjAwb_Mui0FGmyxf5k54AZO-_TVoH6Sm4Vef9SIHvhg/edit?pli=1) and proposed an alternative approach - to extract the information from previous samples, if we captured it once it was active. Haven't checked yet if that's feasible.
There was a problem hiding this comment.
A subquery to capture idle blockers could slow down the query and might be an impediment for increasing the sampling frequency. If we assume that in most samples we won't find any blockers a better approach could be: while scanning the result set of only active sessions build a set containing blockers spids. In the end, execute a second query to collect only the most basic information on idle blockers - as they aren't executing anything we could probably omit all the joins. On the downside, this would generate an additional round trip to the database in the case some blockers are found, but I think this is a good trade off, as we're optimizing for the most frequent scenario where there aren't any idle blockers.
justiniso
force-pushed
the
justindd/sqlserver-collect-all-blocking-query-activity
branch
from
23aebdd
to
2c49b63
Compare
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
justiniso
force-pushed
the
justindd/sqlserver-collect-all-blocking-query-activity
branch
from
4d25f64
to
ba9a8b3
Compare
Co-authored-by: Justin <[email protected]>
|
Example of idle blocking session |
lu-zhengda
deleted the
justindd/sqlserver-collect-all-blocking-query-activity
branch
What does this PR do?
This query update handles cases where the root blocker is a sleeping process (and thus is not collected) resulting in missing data from the UI.
Performance of the current query:
Performance of the new query:
TK
Motivation
Additional Notes
Review checklist (to be filled by reviewers)
changelog/andintegration/labels attachedqa/skip-qalabel.