Change the Target Recovery Time of a Database (SQL Server) 间接checkpoints flushcache flushcache-message
https://msdn.microsoft.com/en-us/library/hh403416.aspx
间接checkpoints在SQL Server2012开始引入
sql2012的target recovery time就是强制做checkpoint，强制人工干预
之前的recovery interval是大部分由sqlserver来决定何时做checkpoint，即使我们设置了recovery interval的值
默认target recovery time是0，并且数据库会使用自动checkpoints（自动checkpoints受recovery interval 服务器选项的控制）
如果设置target recovery time大于0会引起数据库使用间接checkpoints并建立一个数据库的recovery time的上限
当一个长时间运行的事务造成太多undo事件的时候，数据库的target recovery time上限是可以超越的
这个选项简单来讲就是强制控制SQL Server做checkpoint的间隔，比如设置为60秒，那么每60秒做一次checkpoint
ALTER DATABASE AdventureWorks2012 SET TARGET_RECOVERY_TIME = 60 SECONDS;
可以看到
recovery interval ：是实例级选项
TARGET_RECOVERY_TIME ：是数据库级选项
本来SQL Server根据数据库的一定修改量算法来进行checkpoint，现在强制按照时间间隔进行checkpoint，那么当修改量很少，并且读多写少的时候
强制checkpoint会带来磁盘物理写和磁盘的物理读，因为物理写占用了一定的IO，导致读操作受到连累，如果按照数据库的修改量算法来进行checkpoint可以
避免这种问题，修改量很少，不进行checkpoint，这时候不会影响读操作
注意
配置了间接checkpoints的数据库的在线事务可能会遭遇性能下降。间接checkpoints会确保内存中脏页的数量要低于一个阀值以便数据库还原时间在target recovery time定义的时间之内。实例级选项recovery interval刚好与数据库级选项TARGET_RECOVERY_TIME间接checkpoints相反，它使用事务数来决定恢复时间而非脏页数量。当间接checkpoints在一个数据库上开启并接收了大量的DML操作，
后台的lazywriter进程会不断刷写脏页到磁盘确保数据库设置的recovery时间在target recovery time之内。这样会造成额外的I/O活动，并造成性能瓶颈如果磁盘子系统已经超过了I/O阀值
安全
权限
需要数据库的ALTER权限
SSMS
SQL Server2012
SQL Server2008
TSQL设置语法
TARGET_RECOVERY_TIME = target_recovery_time { SECONDS | MINUTES }
示例
设置AdventureWorks2012数据库的target recovery time为60秒
ALTER DATABASE AdventureWorks2012 SET TARGET_RECOVERY_TIME = 60 SECONDS;
http://www.cnblogs.com/MYSQLZOUQI/articles/4966137.html
评估数据库修改量，有两种方法：
第一种：是记录shared buffer里面的脏页有多少，占所有buffer的多大比例；
第二种：记录用户事务的数据修改量是多少。如果用系统的脏页数量或所占比例，来评估修改量，会不太准确，用户有可能反复修改相同的页面，脏页不多，但实际修改量很大，这时候也是应该尽快进行checkpoint，减少恢复时间的。而通过记录WAL日志的产生量，可以很好的评估这个修改量
间接checkpoints的弊端
当一个长时间运行的事务造成太多undo时间的时候，数据库的target recovery time上限是可以超越的
配置了间接checkpoints的数据库的在线事务可能会遭遇性能下降
自动检查点 实例级
间接检查点 数据库级
https://blogs.msdn.microsoft.com/psssql/2012/06/01/how-it-works-when-is-the-flushcache-message-added-to-sql-server-error-log/
flushcache就是SQLSERVER的checkpoint操作，在sql2012开始可以通过打开跟踪标志（3502和3504）查看checkpoint操作的IO吞吐量
Is Long Checkpoint就是当上一个周期的checkpoint还没执行完，下一个周期的checkpoint发现上一个周期的checkpoint还没执行完，而把flushcache-message日志打印到errorlog里
表示磁盘IO不给力，还未flush完数据
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
<footer >
Tags 2008 2008 R2 Denali Engine How It Works SQL 2008 SQL 2012 SQL Denali SQL Server 2008 SQL Server 2008 R2 Troubleshooting: The DB Engine
</footer>
关于216539 bufs
FlushCache: cleaned up 216539 bufs ，一个bufs代表一个页面
刷新了216539个页面到磁盘