

In this post, I just talked about observing recompile overhead with Query Store. Want to Learn More about Query Store and Recompile?

YAY! For all my queries that were run with RECOMPILE hints, I can see information about how many times they were run, execution stats, their query text and plan, and even information about compilation.Īnd yes, I have the execution plans, too – the “CAST(qsp.query_plan AS XML) AS mah_query_plan” totally works. You can add qrs.runtime_stats_interval_id to the query to see that. That means that if I’ve had query store on for a while and have multiple intervals, I may get multiple rows for the same query. Note: I’ve kept it simple here and am looking at all rows in sys.query_store_runtime_stats. WHERE qsqt.query_sql_text like '%recompile%' JOIN sys.query_store_runtime_stats qrs on qsp.plan_id = qrs.plan_id JOIN sys.query_store_plan qsp on qsq.query_id =qsp.query_id JOIN sys.query_store_query_text qsqt on qsq.query_text_id =qsqt.query_text_id If you script out the TSQL for that, it looks like this:ĬAST(qsp.query_plan AS XML) AS mah_query_plan I choose “Read Write” as my new operation mode so that it starts collecting query info and writing it to disk: To enable query store, I click on the database properties, and there’s a QueryStore tab to enable the feature. One of my first questions about Query Store was whether recompile hints would have the same limitations as in the execution plan cache, and how easy it might be to see compile duration and information. The new SQL Server 2016 feature, Query Store may help alleviate at least some of these issues. Some queries take a long time to compile (sometimes up to many seconds), and figuring out that this is happening can be extremely tricky when RECOMPILE hints are in place.We’ve had some alarming bugs where recompile hints can cause incorrect results.This limits the information SQL Server keeps in its execution plan cache and related statistics in sys.dm_exec_query_stats and sys.dm_exec_procedure_stats.This can drive up CPU usage for frequently run queries.Then run the below code.Recompile hints have been tough to love in SQL Server for a long time. Sometimes it’s very tempting to use these hints to tell the optimizer to generate a fresh execution plan for a query, but there can be downsides. Select event SP:CacheInsert ,SP:Recompile and Start profiler. With large data, the performance improvement can be significant. If we measure the query performance after that, the time will most likely be reduced for performing the search. Now let’s see what it logs when you pass table name as parameter to sp_recompile. The purpose of this option is to make SQL Server recompile the query upon each execution. SP:Recompile is logged when a sp get recompiled.Īlso when you pass table or view name as an argument to sp_recompile, MSDN documenation says “all the stored procedures or triggers that reference the table or view will be recompiled the next time that they are run.” SP:CacheInsert is logged when a sp plan get inserted to plan cache. In a SQL Server Profiler collection, the event SP:CacheInsert is logged instead of the event SP:Recompile.” It does this by dropping the existing plan from the procedure cache forcing a new plan to be created the next time that the procedure or trigger is run. MSDN documentation says SP_Recompile “Causes stored procedures and triggers to be recompiled the next time that they are run. I opted to go with SP_Recompile where I will pass table name as parameter and this is meeting my requirement. There are many options to recompile stored procedure. It would trigger recompile only when the row. The query does not need to be compiled for every execution unlike OPTION (RECOMPILE). (1) It uses the same row count threshold as other tables. This trace flag differs from OPTION (RECOMPILE) in two main aspects.

Last week I was working on an assignment where I need to recompile all stored procedure where ever it is refereeing to a certain table. The trace flag 2453 allows the benefit of query recompile without OPTION (RECOMPILE).
