SP taking 15 minutes, but the same query when executed returns results in 1-2 minutes

Question

So basically I have this relatively long stored procedure. The basic execution flow is that it SELECTS INTO some data into temp tables declared with he #

Answer 1

I would suggest the issue is related to the type of temp table (the # prefix). This temp table holds the data for that database session. When you run it through your app the temp table is deleted and recreated.
You might find when running in SSMS it keeps the session data and updates the table instead of creating it. Hope that helps :)

Answer 2

1) When you run the query for the first time it may take more time. One more point is if you are using any corellated sub query and if you are hardcoding the values it will be executed for only one time. When you are not hardcoding it and run it through the procedure and if you are trying to derive the value from the input value then it might take more time.

2) In rare cases it can be due to network traffic, also where we will not have consistency in the query execution time for the same input data.

Answer 3

I would guess it could possible be down to caching. If you run the stored procedure twice is it faster the second time?

To investigate further you could run them both from management studio the stored procedure and the query version with the show query plan option turned on in management studio, then compare what area is taking longer in the stored procedure then when run as a query.

Alternativly you could post the stored procedure here for people to suggest optimizations.

Answer 4

Try recompiling the sproc to ditch any stored query plan

exec sp_recompile 'YourSproc'

Then run your sproc taking care to use sensible paramters.

Also compare the actual execution plans between the two methods of executing the query.

It might also be worth recomputing any statistics.

Answer 5

This is because of parameter snipping. But how can you confirm it?

Whenever we supposed to optimize SP we look for execution plan. But in your case, you will see an optimized plan from SSMS because it's taking more time only when it called through Code.

For every SP and Function, the SQL server generates two estimated plans because of ARITHABORT option. One for SSMS and second is for the external entities(ADO Net).

ARITHABORT is by default OFF in SSMS. So if you want to check what exact query plan your SP is using when it calls from Code.

Just enable the option in SSMS and execute your SP you will see that SP will also take 12-13 minutes from SSMS. SET ARITHABORT ON EXEC YourSpName SET ARITHABORT OFF

To solve this problem you just need to update the estimate query plan.

There are a couple of ways to update the estimate query plan. 1. Update table statistics. 2. recompile SP 3. SET ARITHABORT OFF in SP so it will always use query plan created for SSMS (this option is not recommended) For more options please refer to this awesome article - http://www.sommarskog.se/query-plan-mysteries.html