<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sys.messages on SQL Server Scripts</title><link>https://www.sqlserver70.com/tags/sys.messages/</link><description>Recent content in Sys.messages on SQL Server Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>SQLServer70.com</copyright><lastBuildDate>Sat, 17 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.sqlserver70.com/tags/sys.messages/index.xml" rel="self" type="application/rss+xml"/><item><title>Catch Memory Grant Waits via sys.dm_exec_query_memory_grants</title><link>https://www.sqlserver70.com/post/catch-memory-grant-waits-sys-dm-exec-query-memory-grants/</link><pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/catch-memory-grant-waits-sys-dm-exec-query-memory-grants/</guid><description>
&lt;p&gt;Finding the one query stuck behind a &lt;code&gt;RESOURCE_SEMAPHORE&lt;/code&gt; wait starts with a plain fact most dashboards gloss over: a query waiting on a memory grant isn't failing yet — it's queued, holding a worker thread while SQL Server decides who gets the next slice of execution memory. If that wait outlasts the query's own timeout clock, it gives up and errors out instead of finishing, having done no real work at all. Reading the queue before the clock runs out is the difference between tuning a slow query and explaining a timeout nobody saw coming.&lt;/p&gt;</description></item></channel></rss>