From fc0d9548c5fff621adbe957d4093b52c9781be24 Mon Sep 17 00:00:00 2001 From: Nigel Lahey Date: Sun, 31 Aug 2025 13:34:20 +0000 Subject: [PATCH] Add 'Troubleshooting Variable Memory Grants in SQL Server' --- Troubleshooting-Variable-Memory-Grants-in-SQL-Server.md | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 Troubleshooting-Variable-Memory-Grants-in-SQL-Server.md diff --git a/Troubleshooting-Variable-Memory-Grants-in-SQL-Server.md b/Troubleshooting-Variable-Memory-Grants-in-SQL-Server.md new file mode 100644 index 0000000..d2726fb --- /dev/null +++ b/Troubleshooting-Variable-Memory-Grants-in-SQL-Server.md @@ -0,0 +1,3 @@ +
One of many more perplexing issues to troubleshoot in SQL Server could be those related to memory grants. Some queries want extra memory than others to execute, based mostly on what operations need to be performed (e.g. type, hash). SQL Server’s optimizer estimates how a lot memory is needed, and the question should receive the memory grant in order to start out executing. It holds that grant at some stage in question execution - which means if the optimizer overestimates memory you may run into concurrency points. If it underestimates memory, then you can see spills in tempdb. SEMAPHORE waits. There are a number of methods to attack this challenge, and considered one of my new favourite strategies is to make use of Query Retailer. We are going to use a replica of WideWorldImporters that I inflated using the DataLoadSimulation.DailyProcessToCreateHistory saved procedure. The Gross sales.Orders desk has about 4.6 million rows, and the Sales.OrderLines table has about 9.2 million rows. We will restore the backup and allow Question Retailer, and clear out any old Query Retailer information so we don't alter any metrics for this demo.
+ +
Store CLEAR \ No newline at end of file