I need clarification on how SQLServer behaves when you execute a parameterised procedure with OPTION RECOMPILE in parallel.
Option Recompile:
"You can force SQL Server to recompile the stored procedure each time it is run. The benefit here is that the best query plan will be created each time it is run."
My question is, when executing this procedure in parallel,
will the best query plan be created for each concurrent procedure executed or will it use 1 plan?
The best query plan will be created for each concurrent procedure executed in parallel.
This plan is only used by the session and not added to the plan cache.
It would be a bug if the plans could be used between sessions as OPTION (RECOMPILE) can perform simplifications based on the parameter values that are not generally applicable to all possible parameter values.
Related
I have a question: let's say I have a procedure which contains dynamic SQL inside the definition of procedure, so when I execute the procedure for the first time, it's obvious that it compiles the procedure and stores the plan for first time.
What happens during the second run? Will the same plan be used or will the procedure go for a recompile as it contains dynamic SQL in it?
Dynamic SQL is always compiled. It may result in the same execution plan as the first run (totally dependent on parameters).
I would suggest reading this article from MS. Relevant quotes:
Recompilations: Definition
Before a query, batch, stored procedure, trigger, prepared statement, or dynamic SQL statement (henceforth, "batch") begins execution on a SQL Server, the batch gets compiled into a plan. The plan is then executed for its effects or to produce results.
and
Compiled plans are stored into a part of SQL Server's memory called plan cache . Plan cache is searched for possible plan reuse opportunities. If a plan reuse for a batch happens, its compilation costs are avoided.
A similar question has already been answered in Stack Exchange for Database Administrators. Please refer: https://dba.stackexchange.com/questions/47283/when-does-sp-executesql-refresh-the-query-plan
Does updating statistics recompile stored procedures in sql server or even after updating statistics( Auto or manual) the procedures run with the same execution plan it first compiled with?
MSDN has a lengthy article on that. To sum it up:
Therefore, plan optimality-related reasons have close association with
the statistics.
Looks like it depends on how much the statistics changed. So updating statistics may lead to a recompile but does not have to. To force removal of all cached query plans, you can run:
DBCC FREEPROCCACHE
I have a stored procedure in MS SQL Server that uses a Sybase linked server. Each time the stored procedure is executed it runs for a long time and looks like it is recompiling before execution. Any idea how to stop this recompilation?
its hard to believe that recompilation taking this much time. I suspects this procedure using some old plan to execute which is not optimized.
few points to check.
excute with recompile option. which make new query plan.
check which query inside the proc taking long time. if MDA tables installed check in mosSysStatement. or check in master..sysprocesses table while running that stored proc. it would show statement number which is currently running. it would give you fair idea which statement taking.
run update statistics on tables used by stored proc.
Thanks,
Gopal
I was wondering if you guys could help me get to the bottom of a weird problem I have recently had on SQL Server.
I have a stored procedure (lets call SPold) which is reasonably large with a lot of calculations (can't possibly do this in app as info for around 6000 users needs to come back in a one-er (I reduce this to 1000 based on Surname)). The stored procedure usually executes in a couple of seconds, and is called once every couple of minutes.
Now this morning, the stored procedure was suddenly taking 4-10 times as long to execute, causing a number of timeouts. I discovered that by making a copy of the procedure with a new name (SPnew) and executing, I would get the fast execution times again. This indicated to me that the execution plan was the problem with the original, SPold, so I decided to execute it with recompile. This would return the results a quicker (although not as fast as SPnew), but subsequent calls from users to SPold were once again slow. It was like the new plan wasn't being kept.
What I have done is to fix this is put Exec SPnew into SPold, and now calls to SPold are returning fast again.
Does anyone have any idea what is going on here? The only thing that updated overnight was the statistics, although I think that this should affect both SPold and SPnew.
Sounds like you are experiencing an incorrectly cached query plan due to parameter sniffing.
Can you post the stored procedure?
Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005
I Smell a Parameter!
In SQL Server 2005, you can use the OPTIMIZE FOR query hint for preferred values of parameters to remedy some of the problems associated with parameter sniffing:
OPTIMIZE FOR Instructs the query optimizer to use a particular value for a local
variable when the query is compiled and optimized. The value is used
only during query optimization, and not during query execution.
OPTIMIZE FOR can counteract the parameter detection behavior of the
optimizer or can be used when you create plan guides. For more
information, see Recompiling Stored Procedures and Optimizing Queries
in Deployed Applications by Using Plan Guides.
Although SQL Server 2005 does not support OPTIMIZE FOR UNKNOWN (introduced in SQL Server 2008) which
will eliminate parameter sniffing for a given parameter:
OPTION (OPTIMIZE FOR (#myParam UNKNOWN))
You can achieve the same effect in SQL Server 2005 by copying the parameter into a local variable, and then use the local variable in the query.
I've also encounterred two "strange" cases with Sql Server 2005, which might relate to your problem as well.
In the first case my procedure executed prety fast, when being run as dbo, and it was slow when being run from the application, under a different user account.
In the second case the query plan of the procedure got optimized for the parameter values with which the procedure was called for the first time, and this plan was then reused later for other parameter values as well, resulting in a slow execution.
For this second case the solution was to copy the parameter values into local variables in the procedure, and then using the variables in the queries instead of the parameters.
In a stored procedure in SQL Server, when is the actual SQL query plans generated? When the SQL is run for the first time or when the stored procedure is compiled? Any idea how expensive the generation of query plans is in comparison to Oracle?
When a query is run, SQL Server will check to see if an execution plan already exists for that query in the execution plan cache. If it finds one, it can reuse that execution plan. If it doesn't find one in the cache, it then generates a plan, puts in the cache ready for subsequent calls to reuse, and then executes the query. So it does this at the time when the query is executed.
How long a plan stays in the cache for is down to a number of factors, including:
- how often that plan is used
- how much "value" that plan offers
- memory pressure on the server
So a given query could have an execution plan generated multiple times over the course of a given period, if it's plan is not managing to stay in the cache. Also, when SQL Server restarts, the cache is cleared.
There's a good MSDN article on Execution Plan Caching and Reuse