Category: Execution Plans

Performance Tuning

Are SQL Server Functions Dragging Your Query Down?

In most coding languages, functions are often-used blocks of code that can be reused from multiple locations, leading to less code – and cleaner code. SQL Server also lets us create functions that can be used the same way. They are reusable blocks of code that can be called from multiple locations. So, if you need to format phone numbers a certain way, or parse for specific characters, you can do so using a function.

Read more about Are SQL Server Functions Dragging Your Query Down? 20 comments — Join the discussion
Performance Tuning

Comparing Estimated and Actual Execution Plans in SQL Server

Let’s say you want to have an addition built on your house. You contact a contractor, who comes to your house, looks at your lot, looks at what exists, and asks you questions about exactly what you want. He then gives you an estimate of the work – approximately how long he thinks it will take his crew, what supplies will be needed, and the cost of those supplies.

Read more about Comparing Estimated and Actual Execution Plans in SQL Server 17 comments — Join the discussion
Performance Tuning

Stabilizing Execution Plans: Plan Guides and NORECOMPUTE

Sometimes you end up in a good plan / bad plan situation: an important query runs just fine most of the time. The query is parameterized, a good execution plan gets re-used, everything is cool. But sometimes, a "bad plan" gets compiled and starts to be reused. This is "bad" parameter sniffing. "Bad plans" can come in a few…

Read more about Stabilizing Execution Plans: Plan Guides and NORECOMPUTE 16 comments — Join the discussion
Performance Tuning

Finding One Problem Query With Extended Events

It’s easy to find problem queries on your SQL Server after they’ve happened. You can open your favorite monitoring tool or look in the plan cache. Those options are great for finding things after they’ve happened, but what if you want to find problems as they happen?
Server Side Trace
You could set up a SQL Server Server Side Trace. This is an acceptable solution if you’re using SQL Server 2008 or earlier. There are a few problems with this approach.

Read more about Finding One Problem Query With Extended Events 33 comments — Join the discussion
Performance Tuning

Exploring the Magic of the Plan Cache

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.

Read more about Exploring the Magic of the Plan Cache 7 comments — Join the discussion
Performance Tuning

RECOMPILE Hints and Execution Plan Caching

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?

Read more about RECOMPILE Hints and Execution Plan Caching 35 comments — Join the discussion
Performance Tuning

Introducing the SQL Server Plan Cache (and a Better sp_Blitz®)

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…

Read more about Introducing the SQL Server Plan Cache (and a Better sp_Blitz®) 22 comments — Join the discussion