https://msdn.microsoft.com/en-us/library/hh403416.aspx
默认target recovery time是0，并且数据库会使用自动checkpoints（自动checkpoints受recovery interval 服务器选项的控制）
如果设置target recovery time大于0会引起数据库使用间接-checkpoints并建立一个数据库的recovery time的上限
当一个长时间运行的事务造成太多undo时间的时候，数据库的target recovery time上限是可以超越的
注意
配置了间接-checkpoints的数据库的在线事务可能会遭遇性能下降。间接-checkpoints要确保内存中脏页的数量要低于一个阀值以便数据库还原时间在target recovery time定义的时间之内。服务器选项recovery interval更好与间接-checkpoints相反，它使用事务数能决定恢复时间而非脏页数量。当间接-checkpoints在一个数据库上开启并接收了大量的DML操作，
后台的lazywriter进程会不断刷写脏页到磁盘确保数据库设置的recovery时间在target recovery time之内。这样会造成额外的I/O活动，并一起性能瓶颈如果磁盘子系统已经超过了I/O阀值
安全
权限
需要数据库的ALTER权限
SSMS
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的数据库的在线事务可能会遭遇性能下降
Change the Target Recovery Time of a Database (SQL Server) 间接-checkpoints
原文：http://www.cnblogs.com/lyhabc/p/4966131.html