The plan cache holds a lot of secrets about what’s going on inside SQL Server. In the First Responder Kit we shared one of our plan cache scripts to find the top resource consuming queries. That query works well, but over time we’ve added some additional functionality to the query. I figured it was time to share the new query that we’re using to analyze SQL Server performance.
When you identify that parameter sniffing is a problem, you need to test whether implementing 'recompile' hints will help plan quality. (Not sure what parameter sniffing is? Learn from this blog post or this 50 minute free video.) You must decide: what hint or command do you use, and where do you put it? What trade-offs are you making when it comes to being able to performance tune your SQL Server in the future?
SQL Server needs to have a reasonably correct estimate of how many rows your query is going to handle. If it doesn't, things can go terribly, terribly wrong. Most often, the problem is that SQL Server under estimates its work. In this case, the query optimizer thinks it has just a little bit of work…
When you send your beautifully hand-crafted organic T-SQL statement to SQL Server, the database engine takes a moment to appreciate the poetry of your work. Before it turns your request into results, it has to build an execution plan. SQL Server considers: Which tables it needs to join together What subqueries it needs to execute…
There's beauty everywhere - even in SQL Server. I was just staring at this plan when I was struck by its beauty: Oh, sure, it's ugly, and I recoiled in horror at first, but when you get over that reaction, there's an amazing amount of stuff there. Someone - probably many someones - poured every…
At #SQLbits, Simon Sabin (Twitter) talked about car crash queries: queries that suddenly have bad performance out of nowhere, yet if you copy/paste them into SQL Server Management Studio, they run quickly. The culprit is often parameter sniffing: the engine looks at the query and builds a plan, but if the parameters in the WHERE clause (or joins or whatever) change that plan may not work right anymore.
My gauge of an amazing book is simple: if I've got a question, and I reach for the book BEFORE I search the web, then it's an amazing book. Several times in the last two weeks, I reached for this book first.
StackOverflow users often ask, "I've got this query that runs slow - can you help?" Here's a few tips to get better, faster answers, including getting the execution plan and relevant Perfmon data.
