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的数据库的在线事务可能会遭遇性能下降
原标题:Change the Target Recovery Time of a Database (SQL Server) 间接
关键词:sql