你的位置:首页 > 数据库

[数据库]Change the Target Recovery Time of a Database (SQL Server) 间接


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