44

When comparing the execution time of two different queries, it's important to clear the cache to make sure that the execution of the first query does not alter the performance of the second.

In a Google Search, I could find these commands:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

In fact, my queries are taking a more realistic time to complete after several executions than before. However, I'm not sure this is the recommended technique.

What's the best practice?

migrated from stackoverflow.com Jan 17 '12 at 17:49

This question came from our site for professional and enthusiast programmers.

41

Personally, for a common query the 2nd and subsequent executions matter more.

Are you testing disk IO or query performance?

Assuming your query runs often and is critical, then you want to measure that under real life conditions. And you don't want to clear prod server caches each time...

If you want, you can:

  • DBCC DROPCLEANBUFFERS clears clean (unmodified) pages from the buffer pool
    Precede that with a CHECKPOINT to flush any dirty pages to disk first
  • DBCC FLUSHPROCINDB clears execution plans for that database

Also see (on DBA.SE)

  • 3
    Got an error when running DBCC FLUSHPROCINDB: An incorrect number of parameters was given to the DBCC statement. – Xin Mar 22 '17 at 1:41
  • Finally found it: DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GO from here: stackoverflow.com/questions/7962789/… – Hans Vonn Jun 25 at 20:31
13

Late answer but may be of use to other readers

DBCC DROPCLEANBUFFERS is an often used command for query testing and gauging query execution speed. This command (when run) leaves behind only the dirty pages, which is actually a small portion of data. It removes all the clean pages for an entire server.

Be advised that this command should not be run on production environment. Running this command will result in mostly empty buffer cache. Running any query after executing the DBCC DROPCLEANBUFFERS command, will use physical reads to bring back the data into the cache, which is very likely going to be a lot slower than memory.

Again, treat this command similarly to DBCC FREEPROCCACHE - it should not be run on any production server unless you absolutely know what you are doing.

This can be a useful development tool because you can run a query in a performance testing environment over and over without any changes in speed/efficiency due to caching of data in memory.

Learn more at: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

9

I was always told to use:

dbcc dropcleanbuffers;

From MSDN:

Use DBCC DROPCLEANBUFFERS to test queries with a cold buffer cache without shutting down and restarting the server.

To drop clean buffers from the buffer pool, first use CHECKPOINT to produce a cold buffer cache. This forces all dirty pages for the current database to be written to disk and cleans the buffers. After you do this, you can issue DBCC DROPCLEANBUFFERS command to remove all buffers from the buffer pool.

  • 2
    Plus: DBCC FREEPROCCACHE to clear any cached execution plans... – marc_s Nov 28 '11 at 12:40
  • 1
    Only if you want to test IO, surely... – gbn Nov 28 '11 at 12:44
3

The other answers are correct about reasons to not run DBCC FREEPROCCACHE. However, there are also a couple of reasons to do so:

  1. Consistency

If you want to compare two different queries or procedures which are attempting to do the same thing in different ways, they're likely to hit the same pages. If you naively run query #1 then query #2, the second may be much faster simply because those pages were cached by the first query. If you clear the cache before each execution, they start on an even footing.

If you do want to test hot-cache performance, be sure to run the queries several times, alternating, and discard the first couple of runs. Average the results.

  1. Worst-case performance

Say you have a query which takes one second against a hot cache but one minute against a cold cache. An optimization which makes the in-memory query 20% slower but the IO-bound query 20% faster could be a big win: during normal operations, no one will notice the extra 200 ms under normal circumstances, but if something forces a query to run against disk, taking 48 seconds instead of 60 might save a sale.

This is less of a concern on modern systems with tens of gigabytes of memory, and relatively fast SAN and SSD storage, but it still matters. If some analyst runs a massive table scan query against your OLTP database which wipes out half of your buffer cache, storage-efficient queries will get you back up to speed sooner.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.