CSS SQL Server Engineers

This is the official team Web Log for Microsoft Customer Service and Support (CSS) SQL Support. Posts are provided by the CSS SQL Escalation Services

How It Works: When is the FlushCache message added to SQL Server Error Log?

How It Works: When is the FlushCache message added to SQL Server Error Log?

Rate This
  • Comments 6

FlushCache is the SQL Server routine that performs the checkpoint operation.  The following message is output to the SQL Server error log when trace flag (3504) is enabled.

2012-05-30 02:01:56.31 spid14s     FlushCache: cleaned up 216539 bufs with 154471 writes in 69071 ms (avoided 11796 new dirty bufs) for db 6:0

2012-05-30 02:01:56.31 spid14s                 average throughput:  24.49 MB/sec, I/O saturation: 68365, context switches 80348
2012-05-30 02:01:56.31 spid14s                 last target outstanding: 1560, avgWriteLatency 15

Prior to SQL Server 2012 the trace flag had to be enabled in order to output the information to the SQL Server error log. (Trace flag was the only way to obtain the output.)

 

SQL Server 2012 adds an additional condition (is long checkpoint) to the logic. If the trace flag is enabled or the checkpoint 'TRUE == IsLong' the message is added to the SQL Server error log.

 
Is Long Checkpoint: A long checkpoint is defined as a 'FlushCache / checkpoint' operation on a database that has exceeded the configured recovery interval.
 
If your server does not have the trace flag enabled (use dbcc tracestatus(-1) to check) the message is indicating that the checkpoint process, for the indicated database, exceeded the configured recovery interval. If this is the case you should review your I/O capabilities as well as the checkpoint and recovery interval targets.
 
Not meeting the recovery interval target means that recovery from a crash could exceeded operational goals.

Bob Dorr - Principal SQL Server Escalation Engineer

Leave a Comment
  • Please add 2 and 6 and type the answer here:
  • Post
  • Certaines de mes mises a Jours restes bloquées. Merci de m'aider

  • What does this mean when the target recovery time is 0 and the trace flag is not enabled? We're seeing it regularly in one of our databases that was moved to SQL 2012 via detach/attach.

  • Does this means we have to increase frequency of checkpoint occurence? Or some other resource needs handling

  • We recently moved to 2012 on a huge 64 processor machine - super fast and we are experiencing the dreaded "SQL Server has encountered NNNN occurrence(s) of I/O requests taking longer than 15 seconds to complete on file:..."  The new Indirect checkpoints are supposed to "smooth out" I/O spikes, but is it possible for them to have a negative effect on I/O?  Some of these 833 messages are associated with the Flushcache occurence in the Errorlogs.  

  • Yes, this discribes my problem, but what do I do about it?

    SQL2

    4/24/2013 2:07 spid15s Unknown last target outstanding: 59600<c/> avgWriteLatency 0

    4/24/2013 2:07 spid15s Unknown average throughput:   1.62 MB/sec<c/> I/O saturation: 10346<c/> context switches 23568

    4/24/2013 2:07 spid15s Unknown FlushCache: cleaned up 78146 bufs with 4461 writes in 377583 ms (avoided 65646 new dirty bufs) for db 29:0

  • I've noticed this warning now on a VLD when performing ALTER TABLE statement (large table),  given I know that the database is on a SATA drive (others on SAS) I guess its too slow to keep up with the write demands.  

Page 1 of 1 (6 items)