Clearing Cache for SQL Server Performance Testing

By:   |   Comments (7)   |   Related: > Testing


When conducting performance testing and tuning on a new system, most of the time a number of options are outlined to potentially correct the performance problem.  To determine the best overall solution, each option is tested and the results are recorded.  As lessons are learned options may be combine for a better end result and often as data is cached the overall query performance improves.  Unfortunately, with the data in cache testing each subsequent option may lend itself to an apples to oranges comparison.  How can I ensure during each execution of a new set of code that the data is not cached?


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.  Here is a quick code snippet to serve as an example:


Although the CHECKPOINT and  DBCC DROPCLEANBUFFERS commands seem to be the most elegant approach because they can be included in your T-SQL test scripts, you also can achieve the same results by either restarting the SQL Server instance or restarting Windows.  If you are testing via a batch file (or similar) then you could issue 'net stop mssqlserver' and 'net start mssqlserver' DOS commands.  As a side note, you also have the option to shutdown SQL Server via the T-SQL SHUTDOWN command, but would need to restart the services via either the 'net start' command or via one of the GUI tools.  Although these options are possible, they are not recommended.  These last set of commands will shut down your SQL Server instance or machine, which is probably unneeded.

A few words of caution...

It is not recommended to issue the CHECKPOINT\DBCC DROPCLEANBUFFERS, the 'net stop mssqlserver', T-SQL SHUTDOWN command or restarting Windows on production systems just for the sake of testing.  These commands could have detrimental results to your environment.  It is recommended to only issue these types of commands in testing environments with coordination among your team due to the impact to the overall SQL Server.  In addition, keep in mind that if you do issue these commands only in test environments that if multiple tests are being conducted simultaneously issuing the CHECKPOINT and DBCC DROPCLEANBUFFERS commands may skew results for other testers.

Next Steps
  • As you conduct performance testing in the future consider including the CHECKPOINT and DBCC DROPCLEANBUFFERS command in each of your scripts to ensure cached data is not benefiting later executions of your code.
  • As you test, it may be a good idea to capture the query execution results for cold and warm cache.
  • Although, time needed for a query is important, it is also a good idea to review the query plans for the code to determine the best cost among the options.
  • For related information check out the following:


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Jeremy Kadlec Jeremy Kadlec is a Co-Founder, Editor and Author at with more than 300 contributions. He is also the CTO @ Edgewood Solutions and a six-time SQL Server MVP. Jeremy brings 20+ years of SQL Server DBA and Developer experience to the community after earning a bachelor's degree from SSU and master's from UMBC.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

Monday, August 25, 2014 - 1:20:54 PM - Jeremy Kadlec Back To Top (34249)


I would suggest digging into the issue more to determine the root cause of the issue.  I would also determine the steps to duplicate the issue so you can determine the corrective actions. 

This could be a variety of issues, so I would try to pinpoint where the issue is occurring by isolating each portion of your application and eliminate possibilities.

Thank you,
Jeremy Kadlec
Community Co-Leader

Sunday, August 24, 2014 - 2:32:33 AM - ali Back To Top (34243)

Hi Guys,

I like your site verymuch!!

I have a question, please help/suggest me. 

I have a production SQL Server 2008 where there are 4 significant stored procedures running in every 15 seconds(Borwser aurot refresh) from different users(100+ users connect to site from diff locations) 

Sometimes there is no data coming from these stored procedures and application is timing out  

So we are running follwoing queries to resolve the issue in productuion server


Now we are planing to keep this as part of weekend maintenance activity, so please advise what are the parameters we have to check and what is best practices to clear cache?



Thursday, June 20, 2013 - 5:27:41 PM - Jeremy Kadlec Back To Top (25509)


I would check out these tips ( as a starting point.


Thank you,
Jeremy Kadlec
Community Co-Leader


Thursday, June 20, 2013 - 12:06:36 PM - Raj Back To Top (25506)

Hello Everyone,

I have a set of cubes in ssrs 2005 which I haven't worked before on these cubes.Now I have to check the performance,design of these cubes and suggest any changes or modifications for these cubes if they have any .I dont know where and how to start,so can anybody suggest me  anything.Thanks I really appreciate your help thanks


Thursday, April 15, 2010 - 10:49:47 AM - Repriser2010 Back To Top (5246)

Also, try to differentiate your are testing "recompile" or not.

Never "test" on production environment. "Tune" on production environment after test on QA environment.

Saturday, November 3, 2007 - 10:24:06 AM - admin Back To Top (78)


Thank you for the feedback on the tip.  In the scenario where our team used the script (CHECKPOINT and DBCC DROPCLEANBUFFERS) outlined in this tip and found value was in these testing scenarios: 

  • Change database design
  • Change indexes (clustered and non-clustered)
  • Changed partitions
  • Changed full text catalogs

Due to the significance of the changes, we wanted to be able to start each test run at the same point (all data committed with cleared cache) as all of the other tests to ensure we could observed the metrics with both cold and warm cache.

Thank you,
The Team

Tuesday, October 30, 2007 - 1:02:50 AM - Bharathy Back To Top (60)

Generally in the production environment users will access the database concurrently, so the ‘datacache' could holds the data for the repeatedly called SQLs. In the same way, if the load testing run is trying to simulate the production scenario / usage, then the explicit call to clear the data cache could simulate the worst case scenario of the application usage rather than the real time requirement.  Even for the query tuning, better execute the SQL, at least for 3 to 4 times, and get the final statistics like query execution time (elapsed time), physical reads, logical reads, sorting & etc and tune it to reduced the these values. So, clearing the ‘datacahce' is not valid for performance testing.



get free sql tips
agree to terms