General Question on sp_recompile

Question

For couple of scenarios, not many a times but few we have seen doing sp_recompile on a stored proc improving the performance.

Being a DBA i understand few of caveats involved when doing sp_recompile and why it would have worked in improving with performance.

There has been a constant debate within our management to provide Application/DEV DBA's the access to do sp recompile when they see performance issues like above. Just so that less of DBA involvement is there and APP devs can run on their during perf issues

I am very hesitant as i think it can bring some unwanted behaviors where it can sometime even worsen performance of other procs.

I am looking for general guidance and experience from your experts why this can be a bad idea under possible different circumstances or when it can be ideal. Your inputs might help me design and may be explain the approach in different way.

FYI- Above is being thought not across just one app but across few other as automation when seeing issues like parameter sniffing.

Answer 1

One thing that gets lost about sp_recompile is that it works on objects beyond stored procedures. From the docs:

The qualified or unqualified name of a stored procedure, trigger, table, view, or user-defined function in the current database

If anyone gets a weird idea in their head, they could end up impacting more than just one procedure:

If object is the name of a table or view, all the stored procedures, triggers, or user-defined functions that reference the table or view will be recompiled the next time that they are run.

If developers already have the ability to use other flavors of recompile hints, it may be better to let them use those when appropriate, but also educate them on the difference in scope of what gets recompiled, and how they handle parameters:

For instances running at least SQL Server 2008 build 2746 (Service Pack 1 with Cumulative Update 5), using OPTION (RECOMPILE) has another significant advantage over WITH RECOMPILE: Only OPTION (RECOMPILE) enables the Parameter Embedding Optimization.

In general, WITH RECOMPILE should be avoided -- it's a very heavy handed approach. I'm in favor of targeting recompile hints either to temporarily solve a problem, or when the other potential solutions to a problem are unattractive.

Answer 2

From my observation, a lot of inexperienced developers inevitably seem to stumble on sp_recompile, OPTION (RECOMPILE), DBCC FREEPROCCACHE, etc and unfortunately abuse them after they find it magically temporarily fixed the issue they were facing in the moment, so your feelings to be hesitant are justified.

I will say this from the opposite perspective though, depending on the environment, its not the end of the world when in panic mode to force recompilation of an individual query plan when done carefully on a specific procedure or query. Carefully meaning the developer should only do it to the object of which the problematic query plan belongs to, and not spam the "recompilation button" to nuke everything, and the developer should concretely identify that the performance issue they are facing is due to a bad execution plan (such as due to parameter sniffing ) before doing so. Therefore there should be some upfront training and maybe selectivity on which non-DBA developers are allowed to "push the magic button". I've seen cases where inexperienced developers scheduled jobs to run DBCC FREEPROCCACHE hourly unbeknownst to them they were causing a lot more performance problems by nuking the cached query plans instead of solving their issues.

By laying down some guidelines as above, you minimize the chances for introducing more problems than your solving (e.g. causing an even worse execution plan to be cached).

I would also recommend that forcing the developer to maintain a running list of the procedures / queries where these type of performance issues occur, so that an actual fix can be applied by a qualified developer / DBA when possible.

Answer 3

I want to tell a story, maybe it will help someone.

In my experiences; My customer had has a query that includes 8-10 tables and hundred of columns. The query runs hundred times in a minute, on some special day which is the discount day, the query runs thousand times. There was a parameter sniffing problem from time to time and when it happened they get a timeout and their website couldn't open and it is not acceptable.

That time I go into the server and find the bad plan and drop it after that everything is normal.

BTW, I rewrite a query but they can not change the query in near future.

So, I decided to add OPTION (RECOMPILE) hint with the plan guide and it works but we forget something.

The special day has come and the query runs a thousand times in a minute. So, the CPU stuck at 100%. Because every run of the query, SQL Server uses more CPU for creating a new query plan.

I agree with Erik and J.D., I think if you use this hint you have to be very careful and wide-angle think.

End of the story: That time I dropped the plan guide and hunting bad plan all day long. They changed the query with my version. Now it is better.