Resource-Heavy Query
Category: Query & Session · Also known as: Top Session
One session ran a single statement that used far more CPU, reads or writes than anything else this minute. Points you at the one query doing the damage.
What this finding means
Section titled “What this finding means”One session ran a single statement that consumed far more CPU, logical reads, or writes than anything else active in that minute. This is a concentration finding, not a volume finding: the server may be perfectly busy overall, but one request is taking a disproportionate share of it. WISdom identifies the session, the database, and the statement text so the work starts at the query rather than at the server.
Why it matters
Section titled “Why it matters”This is usually the single highest-leverage thing to fix on the instance. One statement doing millions of logical reads sets the floor for everything else: it evicts other sessions’ pages from the buffer pool, it occupies a scheduler, and on a licensed server it is consuming capacity you are paying for. Tuning it typically moves several other findings at once.
How WISdom detects it
Section titled “How WISdom detects it”Active sessions are ranked by their resource counters in sys.dm_exec_requests (cpu_time, logical_reads, reads, writes), joined to sys.dm_exec_sessions for the session context, with statement text resolved through sql_handle and query_hash. The winner is compared against the same statement in the 15 minutes either side of this minute-of-day across the previous four weeks, so a nightly batch job is measured against other nights rather than against midday.
| Collected from | sys.dm_exec_requests (cpu_time, logical_reads, reads, writes by session_id) + sys.dm_exec_sessions; statement text via sql_handle / query_hash. |
| Compared with | Same statement during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks |
| Related screen | Query Analysis |
How it is scored
Section titled “How it is scored”This rule fires only when the condition is met. It contributes an incident score of 2 when the finding is present, 3 when it exceeds its four-week maximum, and 4 when it has never been seen before.
How to read the numbers
Section titled “How to read the numbers”Top resource is the winning counter and its value, so a session at 2.1 minutes of CPU is a CPU story while one at 900k reads is a storage story. Executions separates one expensive run from many cheap ones. vs history is the field that decides urgency: a statement 40% above its own four-week normal is drifting, and one marked first seen has no baseline at all, which usually means new code or a changed plan.
What normally causes it
Section titled “What normally causes it”- An access path that reads far more than it returns, typically a scan where a covering index would seek, or a predicate that is not sargable.
- A parameter value far outside the norm reusing a plan built for a different data shape.
- Missing or stale statistics producing a row estimate that is wrong by orders of magnitude.
- A genuinely large operation, an ETL load or a report, that is correctly placed but badly timed.
What this finding is not
Section titled “What this finding is not”- Not automatically the cause of a slowdown. This finding says one session dominated the resource mix, not that users were affected. Check the server health indicators before treating it as an incident.
- Not the same as Duplicate Query Storm. This is one session running one expensive statement. If the same text appears across many sessions, that finding is the accurate one and the fix is different.
- Not a verdict on the developer. A statement can be well written and still dominate because the data volume grew past what its index supports.
What are some possible resolutions?
Section titled “What are some possible resolutions?”The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.
1. Tune how the statement reads the data
Section titled “1. Tune how the statement reads the data”Open the statement and look at its access path. A scan on a large table, a spill to tempdb, or a missing index is the usual cause, and a covering index normally turns that scan into a seek.
2. Call it less often
Section titled “2. Call it less often”If the statement itself is reasonable but runs constantly, the cheaper win is at the app tier. Cache the result or widen the polling interval so the same work happens fewer times.
3. Cap what it can consume
Section titled “3. Cap what it can consume”If the code cannot change, use Resource Governor to bound this workload so it stops crowding out everything else. Containment, not a fix.