One thing that I have to recommend to clients on a fairly regular basis is to enable Forced Parameterization. Many vendor applications send over queries that aren’t parameterized, or without strongly typed parameters, and that can make things… awkward.
Every time SQL Server gets one of those queries, it’ll come up with a “new” execution plan, cache it, and blah blah blah. That’s usually not ideal for a lot of reasons.
There are potentially less tedious ways to figure out which queries are causing problems, by looking in the plan cache or query store.
But, you know, sometimes the plan cache isn’t reliable, and sometimes Query Store isn’t turned on.
And so we have sp_HumanEvents!
One way to start getting a feel for which queries are compiling the most, along with some other details about compilation metrics and parameterization is to do this:
EXEC sp_HumanEvents @event_type = 'compilations', @seconds_sample = 30;
Newer versions of SQL Server have an event called query_parameterization_data.
Fired on compile for every query relevant for determining if forced parameterization would be useful for this database.
If you start monitoring compilations with sp_HumanEvents you’ll get details from this event back as well, as long as it’s available in your version of SQL Server.
You can find all sorts of tricky application problems with this event setup.
Thanks for reading!
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that, and need to solve database performance problems quickly.
- SQL Server Extended Event Duration Filtering Can Make Troubleshooting Frustrating
- SQL Server Community Tools: The Wrap Up And Combined Link
- SQL Server Community Tools: Capturing Which Queries Are Recompiling And Why With sp_HumanEvents
- SQL Server Community Tools: Capturing Query Performance Problems With sp_HumanEvents