Daniel Pottenger

30 October 2025

Tracking Aborted Queries and Memory Grants in Redgate Monitor

Recently, Redgate Monitor introduced the Query Executions feature for SQL Server instances, using Extended Events to capture execution details for individual queries. It allows DBAs to correlate spikes in resource contention, blocking, or slow performance with the specific queries that were running at the time.

SQL Server’s Extended Events framework is extremely powerful, and we’ve had frequent feedback from DBAs: “Use it to give us more insight into what’s going on under the covers!” With that in mind, we’ve extended the Query Executions feature to make two more common causes of poor query performance much easier to spot:

• Cancelled or aborted queries – immediately see when a query fails to complete, whether due to timeouts, user cancellation, or connection issues
• Memory grants – identify queries that are granted large amounts of memory, a frequent cause of contention and blocking

Cancelled and aborted queries

One of the biggest frustrations for DBAs and developers alike is when a query doesn’t complete as expected. Perhaps it was cancelled by the user or hit an unexpected error. Until now, spotting those problem queries in Redgate Monitor hasn’t been easy.

That changes with our latest improvements. Redgate Monitor now surfaces this additional information directly in the Query Executions view. If a query gets cancelled or fails, you’ll know about it straight away, without having to dig through logs or run extra DMV diagnostic queries manually to investigate.

This additional data comes alongside familiar metrics such as CPU time and query start time, giving you a much more complete picture of what really happened during execution.

Once Redgate Monitor is tracking individual query executions on an instance, with query executions enabled, the cancelled and aborted query data comes with no additional performance overhead, since it’s already available in the payload for the sql_statement_completed, sp_statement_completed, sql_batch_completed and rpc_completed events.

Memory grants

Memory usage is often where performance problems hide, so being able to see which queries request significant memory grants is important. Queries that request unusually large memory grants to execute can reduce concurrency and contribute to blocking and slowdowns, especially when several high-memory queries run concurrently.

Redgate Monitor can now track memory grant events in SQL Server and correlate each one to the right query execution. You can see directly in the Query Executions view any query that received a memory grant above a configurable threshold (5120 KB by default):

Collecting memory grant data does add some overhead, because Redgate Monitor must collect the data from a separate extended event (query_memory_grant_usage) than for query executions. The overhead depends on how many events your SQL Servers raise. If you notice an impact, there is a setting to raise the minimum memory grant that Redgate Monitor captures, filtering out small grants and focusing on the ones most likely to affect performance. See the Memory grants section of the Query execution documentation for more details on how to do this.

Conclusions

With these improvements, Redgate Monitor goes further than ever in helping you quickly spot common causes of SQL Server performance issues. Cancelled and aborted queries no longer slip under the radar, and memory grant tracking shines a light on one of the most common but hard-to-spot causes of performance issues.

Most importantly, you don’t need to worry about extra overhead or manual investigation. Redgate Monitor surfaces the data that matters, when it matters, and lets you fine-tune the level of detail to suit your environment. The result? Faster diagnosis, fewer blind spots, and more time to focus on solving the issues.