Duplicate Query Storm

Category: Query & Session · Also known as: Same Statement Storm

The exact same statement is running many times at once. Each copy repeats the same reads, so a small query becomes a large load.

What this finding means

The identical statement, matched by query hash, was executing in many sessions at the same moment. Each copy repeats the same work, so a statement that is cheap in isolation becomes an expensive aggregate load. The finding reports peak concurrency, the statement, and the reads summed across every copy.

Why it matters

This is the classic amplifier. On its own it is often survivable, but it multiplies the cost of every other problem: when storage slows, thirteen concurrent copies of the same read turn a latency blip into a queue. It is also one of the cheapest problems to fix, because the cause is nearly always at the application tier rather than in the database.

How WISdom detects it

Active requests in sys.dm_exec_requests are grouped by query_hash and the concurrent session count per statement is taken for the minute, with logical reads summed across the copies. The concurrency is compared to the same statement in the 15 minutes either side of this minute-of-day over four weeks, so a job that always fans out to ten sessions does not fire every night.


Collected from	sys.dm_exec_requests grouped by query_hash - count of concurrent sessions running the same statement; reads summed across copies.
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

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

Concurrency is the headline: the number of sessions running the identical text at once. Total reads is concurrency multiplied by the per-execution cost and is the number that shows the real load. A regular cadence in the timeline, the same finding every few minutes for an hour, is the signature of a poll or a retry loop rather than user demand.

What normally causes it

A retry loop with no backoff, re-firing the same call after a timeout or an error.
A scheduled poll running on a short interval across many application instances.
A missing cache at the application tier for a lookup whose data changes far more slowly than it is read.
A fan-out job that starts every worker at once instead of staggering them.

What this finding is not

Not necessarily a database problem. The statement may be entirely reasonable. The defect is usually how often the application calls it.
Not the same as Application Overload. This finding groups by statement; that one groups by program. Many sessions from one app running different statements is the other finding.
Not always harmful. A read-heavy application with a healthy cache hit ratio can run high concurrency safely. Check whether the copies are running or blocking each other before acting.

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. Fix the retry or polling loop

Many copies of one statement firing together is almost always application behaviour: a retry with no backoff, or a poll every few seconds. Fix the backoff and the storm disappears.

2. Cache the result at the app tier

If the reads are legitimate and identical, cache them so many lookups become one. Best where the data changes far more slowly than it is read.

3. Make each execution cheaper

If the storm cannot be stopped, reduce its unit cost. A covering index on the target object cuts the physical reads every copy performs.