I have SQL Server 2016. There are two absolutely same stored procedures with different names, but they execute differently. First completes in 17 minutes, other in 18 second.
First was created before Index on one of elements was created, but it was recompiled and cleared all plans from the plan cache.
The result does not change.
What problem it can be and how reconfigure execution plan?
To improve performance of stored procedure must be executed script lower. It can help to recreate execution plan.
EXEC sp_recompile N'ProcedureName';
GO
DBCC FREEPROCCACHE WITH NO_INFOMSGS;
GO
EXEC sp_updatestats;
GO
Related
I had a query that was running slow (2.5 mins) on sqlserver.
I got actual execution plan, and there was a suggestion for an index. I created the index and now execution time is < 2 seconds.
Then we had to restart sql server.
Query went back to being slow (2.5 mins), again, I looked at execution plan. This time there was a suggestion for a different index!
It would appear that first execution plan index suggestion was taking into account some sort of cached index maybe?
How can I clear cache (if this is the issue) before looking at execution plan?
The symptoms suggest parameter sniffing, where the query plan was generated for the initially supplied parameter values but the plan is suboptimal for subsequent queries with different values. You can invalidate the currently cached plan for specific query by providing the plan handle to DBCC FREEPROCCACHE:
DBCC FREEPROCCACHE(plan_pandle);
There are a number of ways to avoid parameter sniffing. If the query is not executed frequently, a recompile query hint will provide the optimal plan for the parameter values supplied. Otherwise, you could specify an optimize for unknown hint or use the Query Store (depending on your SQL Server version) to force a specific plan or have SQL Server automatically identify plan regression and select a plan.
Dont clear the cache in PRODUCTION environment. It will lead to serious performance issues.
If you want to generate new plan instead of existing plan, you can go for RECOMPILE option as part of stored procedure execution to see whether new index is being considered in the new plan.
EXEC dbo.Procedure WITH RECOMPILE;
or you can regenerate the execution plan for the procedure, by using the below command. Next time, it will be using the newly generated plan.
EXEC sp_recompile `dbo.procedure`
If you want to measure performance improvement repeatedly in a test environment, you can go with below clearing approaches:
DBCC FREEPROCCACHE -- It will clear the plan cache completely
DBCC DROPCLEANBUFFERS -- It will clear the unchanged data brought from disk to memory.
More elegant approach is to write the dirty pages to disk and then issue the cleaning of unchanged data.
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
DBCC FREEPROCCACHE;
GO
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 have a stored procedure which I am trying to optimize. In order to know how much time is spent for an execution I have added at the beginning of the script:
use MyDatabase
go
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
between two execution I can see the time to run the query decreasing. I thought only cache could fasten the execution of my script, are there other mechanism in SQL Server to do the trick?
thanks,
The first time you run a stored procedure, the query plan is calculated and compiled. This typically takes 20ms, can be a bit more for a long procedure.
If you run the query once, before checkpoint; dbcc dropcleanbuffers;, the plan should be cached.
our SQL Server 2008 shows a strange behavior:
We've a SP which takes normally about 500 ms to execute. Sometimes the execution takes exactly 16 seconds. The strange thing about this is, that altering this SP then takes 16 seconds too.
The SP uses a CTE to return some data. The strange thing is, when we add a RETURN statement at the beginning of the SP, it also takes 16 seconds.
The SP uses isolation level read uncommitted. We've already tested another server with SQL Server 2008 R2 and have the same problems.
We don't know where to start searching the source of this problem. Help :)
Thanks
Torben
Update your DB's statistics and have your SP officially recompiled to see if that helps.
http://msdn.microsoft.com/en-us/library/ms173804.aspx
EXEC sp_updatestats
http://msdn.microsoft.com/en-us/library/ms181647.aspx
EXEC sp_recompile SP_Name
Also
Reboot server
Run a storage benchmark program on server (rule out hardware problem)
Disable Parameter Sniffing. This won't affect SP-Update speed, but it may help execution time.
You have a couple of options. You could set up an extended events session to capture the wait types and their durations for the execution of one call to this procedure and analyze it that way or you could look at something like sys.dm_exec_requests or sys.dm_os_waiting_tasks and look at point-in-time snapshots of the wait states. If I were to bet, I'd say that you have something like the procedure trying to grant itself permissions or something and so you're getting a schema lock. But you won't know for sure until you look.
I've looked all over for this command....what's the command to reset the SQL Server's execution plan?
For clarity..........
Executing sp_recompile will "mark" the given stored procedure for recompilation, which will occur the next time it is executed.
Using the WITH RECOMPILE option will result in a new execution plan being generated each time the given stored procedure is executed.
To clear the entire procedure cache execute
DBCC FREEPROCCACHE
For stored procedures, you use the WITH RECOMPILE option.
If you want to reset QEP for a stored procedure, you shall use sp_recompile
It's not entirely clear from your question what you're after. But in addition to the other suggestions, DBCC FREEPROCCACHE clears all cached execution plans.
sp_recompile will dump the existing query plan and recompile the procedure.
Or you can restart SQL and that will clear the entire execution plan cache.
WITH RECOMPILE is going to generate a new plan EVERY time you execute it.