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.
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 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
I would like to check the performance of my SQL query but every time I execute the same query I am getting different execution time due to cache and statistics.
I tried to use the following commands before every cycle but the problem persists:
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
I've got a simple query running against SQL Server 2005
SELECT *
FROM Table
WHERE Col = 'someval'
The first time I execute the query can take > 15 secs. Subsequent executes are back in < 1 sec.
How can I get SQL Server 2005 not to use any cached results? I've tried running
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
But this seems to have no effect on the query speed (still < 1 sec).
Here is some good explaination. check out it.
http://www.mssqltips.com/tip.asp?tip=1360
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
From the linked article:
If all of the performance testing is conducted in SQL Server the best approach may be to issue a CHECKPOINT and then issue the DBCC DROPCLEANBUFFERS command. Although the CHECKPOINT process is an automatic internal system process in SQL Server and occurs on a regular basis, it is important to issue this command to write all of the dirty pages for the current database to disk and clean the buffers. Then the DBCC DROPCLEANBUFFERS command can be executed to remove all buffers from the buffer pool.
Eight different ways to clear the plan cache
1. Remove all elements from the plan cache for the entire instance
DBCC FREEPROCCACHE;
Use this to clear the plan cache carefully. Freeing the plan cache causes, for example, a stored procedure to be recompiled instead of reused from the cache. This can cause a sudden, temporary decrease in query performance.
2. Flush the plan cache for the entire instance and suppress the regular completion message
"DBCC execution completed. If DBCC printed error messages, contact your system administrator."
DBCC FREEPROCCACHE WITH NO_INFOMSGS;
3. Flush the ad hoc and prepared plan cache for the entire instance
DBCC FREESYSTEMCACHE ('SQL Plans');
4. Flush the ad hoc and prepared plan cache for one resource pool
DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');
5. Flush the entire plan cache for one resource pool
DBCC FREEPROCCACHE ('LimitedIOPool');
6. Remove all elements from the plan cache for one database (does not work in SQL Azure)
-- Get DBID from one database name first
DECLARE #intDBID INT;
SET #intDBID = (SELECT [dbid]
FROM master.dbo.sysdatabases
WHERE name = N'AdventureWorks2014');
DBCC FLUSHPROCINDB (#intDBID);
7. Clear plan cache for the current database
USE AdventureWorks2014;
GO
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
8. Remove one query plan from the cache
USE AdventureWorks2014;
GO
-- Run a stored procedure or query
EXEC dbo.uspGetEmployeeManagers 9;
-- Find the plan handle for that query
-- OPTION (RECOMPILE) keeps this query from going into the plan cache
SELECT cp.plan_handle, cp.objtype, cp.usecounts,
DB_NAME(st.dbid) AS [DatabaseName]
FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE OBJECT_NAME (st.objectid)
LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE);
-- Remove the specific query plan from the cache using the plan handle from the above query
DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);
Source 1 2 3
Note that neither DBCC DROPCLEANBUFFERS; nor DBCC FREEPROCCACHE; is supported in SQL Azure / SQL Data Warehouse.
However, if you need to reset the plan cache in SQL Azure, you can alter one of the tables in the query (for instance, just add then remove a column), this will have the side-effect of removing the plan from the cache.
I personally do this as a way of testing query performance without having to deal with cached plans.
More details about SQL Azure Procedure Cache here
While the question is just a bit old, this might still help. I'm running into similar issues and using the option below has helped me. Not sure if this is a permanent solution, but it's fixing it for now.
OPTION (OPTIMIZE FOR UNKNOWN)
Then your query will be like this
select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)
EXEC sys.sp_configure N'max server memory (MB)', N'2147483646'
GO
RECONFIGURE WITH OVERRIDE
GO
What value you specify for the server memory is not important, as long as it differs from the current one.
Btw, the thing that causes the speedup is not the query cache, but the data cache.
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.