Change the Target Recovery Time of a Database (SQL Server) 间接-checkpoints

Change the Target Recovery Time of a Database (SQL Server)间接-checkpoints

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的数据库的在线事务可能会遭遇性能下降