RESOURCE_SEMAPHORE can mean a query is waiting for execution memory. Identify the waiting requests, the grants already held and the workload that consumes them before increasing server memory or imposing a query hint. The immediate symptom is a queue; its cause may be excessive grants, underestimated work or too many legitimate requests running together.1, 2
This article uses SQL Server 2022. Diagnostic examples are source-checked but unexecuted. It does not change memory settings, capture a production execution plan or run a workload benchmark.
Execution memory is a specific resource
SQL Server uses execution-memory grants for operations such as sorts and hash processing. That workspace is distinct from a simple reading of total process memory or the amount of database data cached. A server can have substantial memory assigned to SQL Server while a particular execution-memory pool still has waiting requests.1
The useful values are requested, required, granted and used memory. Requested memory describes what the query asks for; required memory is the minimum needed to run. Granted memory is what the engine actually assigns. Current and maximum-used values describe consumption during the observed execution.2
Those values answer different questions. A large grant is not necessarily wasteful if the operation needs it. A small current-used value early in execution does not prove the grant will remain unused. A grant that looks modest alone may still become problematic when many similar requests overlap.
Microsoft describes the consequences of estimation errors: overestimation can reserve memory that other requests could use, while underestimation can lead to work spilling to disk.1 The corrective question is therefore about estimates, operators and concurrency, not simply whether to make every grant smaller.
Preserve the incident window
Record the instance, database, engine build and time interval, along with the affected operation and normal concurrency. Establish whether the symptom occurs throughout the day or during a report, maintenance task or batch overlap.
Keep application response time separate from the SQL wait. A request might first wait for a client connection and only later reach the engine. Conversely, a SQL request granted memory may still wait on locks or storage. Correlate the database evidence with the application operation rather than attributing the whole delay to one sampled wait.
Use an existing diagnostic account. The memory-grants DMV requires VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later; earlier SQL Server versions use the permission stated in the reference.2 An empty or restricted result from an underprivileged connection is not proof that no other requests are waiting.
Inspect waiters and holders with a small query
The following author-composed SELECT uses documented columns and does not request SQL text or plans. It deliberately avoids sorting and aggregation: Microsoft warns that diagnostic DMV queries using those operations can themselves consume memory during the incident.2
SELECT session_id,
request_id,
request_time,
grant_time,
requested_memory_kb,
required_memory_kb,
granted_memory_kb,
used_memory_kb,
max_used_memory_kb,
wait_time_ms,
pool_id,
resource_semaphore_id
FROM sys.dm_exec_query_memory_grants;
Only requests that need grants appear in this view. It is not a list of all queries or all SQL memory consumers. A null grant_time means memory has not yet been granted. For those rows, a missing granted-memory value must not be interpreted as a completed query that used zero memory.2
Read the waiting requests and granted requests together. A queue alone identifies demand. The holders show which active work already occupies the pool. Preserve request identity and capture time, because requests can finish between observations.
For pool-level context, Microsoft's troubleshooting guide also uses sys.dm_exec_query_resource_semaphores to compare available, granted and used execution memory with counts of grantees and waiters.1 Have the DBA inspect the relevant pool and semaphore. Do not aggregate separate pools into a reassuring global total when one constrained pool is where the affected application runs.
Classify the evidence
Use a sequence of observations, gathered through approved bounded monitoring, to distinguish these cases:
| Pattern | Explanation to test |
|---|---|
| A few large grants remain mostly unused over their relevant execution phases | Estimates or plan choices may reserve more workspace than necessary. |
| Many appropriately sized grants overlap | Concurrency or scheduling may exceed the execution-memory budget. |
| Granted requests spill and perform much more work than estimated | Cardinality, row width or plan shape may need investigation. |
| Grants stay held while the query is delayed elsewhere | Identify the lock, I/O or other wait prolonging execution. |
| No relevant live rows remain | Use retained history, and state that the active incident was not captured. |
These patterns can coexist. Reducing the memory requested by a spilling query might increase its duration, which can increase overlap with later queries. That is why the acceptance criteria must include throughput and concurrency as well as grant size.
Avoid measuring only the query that complains. It may be a small waiter behind an unrelated reporting workload. Equally, the largest grant is not automatically the best intervention target; its business purpose, execution phase and expected completion matter.
Examine the responsible plan
Select the relevant request rather than retrieving every cached plan. Record its query identity, plan and the data range it processes. SQL text and actual-plan captures can expose business values, and collecting them can add overhead. Use an approved capture scope and retention location.
In the execution evidence, inspect memory-grant information alongside row estimates and observed work. Microsoft's guide explains the plan's requested, granted and maximum-used memory fields and the relationship between sort/hash operations and workspace.1
If estimates differ materially from observed cardinality, examine statistics, predicates and parameter distribution. If the row estimate is reasonable, inspect the amount of data carried through the operator and the concurrency under which the query runs. The presence of a sort or hash does not itself establish a defective plan.
A spill should be tied to the actual operator and execution. Internal tempdb allocation is supporting context, not a complete spill diagnosis. Keep tempdb's capacity investigation separate so that a memory correction does not unexpectedly exhaust disk workspace.
Memory-grant feedback is version- and feature-dependent. The source describes related feedback events, but this article does not assume feedback has adjusted a particular query or guarantee that it will stabilise every workload.1 Inspect the actual plan evidence and installed configuration before proposing a change to feedback behaviour.
Choose a correction and a return condition
Where the evidence shows an avoidable query shape or estimate problem, prepare a scoped query, index or statistics change. Record why it should reduce the problematic workspace demand and what else the change may affect. Test representative parameter classes and concurrent requests in an authorised environment before rollout.
If legitimate requests simply overlap beyond the available budget, consider application concurrency limits or scheduling changes. That is a business-capacity decision: slower admission may be preferable to a large queue inside SQL Server, but the resulting completion window must still meet service requirements.
Do not raise SQL Server's memory allocation without checking the operating system and other consumers. Do not apply a blanket memory-grant hint to every slow query. A smaller cap can trade waiting for spills, while a larger grant can deprive neighbours. Any hint needs exact query scope, a supported version and explicit removal criteria.
For emergency intervention, identify the current target again and involve the workload owner. Ending a grant holder may roll back work and cause the application to retry. The decision must account for transaction and external side effects; no termination recipe is supplied here.
Verify at workload level
Record a baseline for waiting requests, grant distribution, spills, query duration, application failures and completed business work. The comparison window must include the overlap that triggered the incident. A single isolated query that becomes faster is not evidence that overall concurrency improved.
After an approved change, verify that the intended request uses the expected plan or concurrency policy and that the queue stays within the agreed limit. Check that other workloads and tempdb retain headroom. Preserve failures and cancellations rather than reporting only successful executions.
Keep the previous query, hint or application limit in the change record. Set a return condition before rollout, such as increased spill-related duration or failure of another critical workload. No measurements or runtime validation were performed for this article; the proposed acceptance work remains with an authorised test and change process.
Learning notes
- A query-memory queue is not a complete account of server memory health.
- Requested, granted and actually used memory have different meanings.
- A successful correction improves the concurrent workload, not just one grant number.
Acceptance checklist
- [ ] Pending, granted and used query memory are distinguished from other server-memory use.
- [ ] The plan and workload overlap responsible for pressure are evidenced.
- [ ] Approved comparison covers queueing, spills, latency and failed requests.
- [ ] Other workloads retain headroom and the prior query or concurrency configuration is recoverable.
References
- Troubleshoot slow performance or low memory issues caused by memory grants - SQL Server | Microsoft Learn. Accessed 2026-11-01.
- sys.dm_exec_query_memory_grants (Transact-SQL) - SQL Server | Microsoft Learn. Accessed 2026-11-01.