SQL Server中的Recovery Interval

其实有很多朋友都问到过Recovery Interval，有问这个是干吗的，有问怎么调节这个值，所以今天写一篇小Blog，一劳永逸。

众所周知，SQL Server依靠Log来保证性能和数据持久性两不耽搁。那么我们来看一看SQL Server是如何处理我们的数据修改请求的。

首先我们的客户端将数据修改指令递交到SQL Server，SQL Server就会通过一系列的过程把数据从物理磁盘上读取到内存中。

数据被读取到内存中后，SQL Server会在内存中修改数据。当然大家就会想到，修改完了是不是要立即写回到磁盘上呢?如果写回去，那么势必会影响性能，如果不写，那么万一系统崩溃了修改就会丢失，这一切就像我们在用WORD写文档一样。

SQL Server没有采用这两种笨办法，SQL Server知道大多数情况下，大多数数据被访问后一段时间内都会再次被访问，因此SQL Server决定将数据保留在内存中。不过，如果这个时候系统崩溃了怎么办，又或者系统掉电了怎么办呢?SQL Server采用了一种变通的办法，它将修改操作写到了另外一个文件中去，这个文件叫做日志。

那么SQL Server就像这样，我们每修改一个数据，SQL Server都会把这个数据写到日志文件中去。如果系统崩溃了，SQL Server只要从这个日志文件中就可以知道我们执行了哪些操作，我们只要把这些操作再做一遍就可以恢复数据了。

好像我们没有讲到Recovery Interval么。

是的，就要来了。虽然上面说的办法不错，不过那些修改过的数据不能一直放在内存中。除了内存是有限的之外，还有一个重要的原因，那就是SQL Server不能仅仅依赖日志来保证数据的一致性。

SQL Server通常都会运行数个月之久而不重新启动，这可不像我们用的笔记本。那么如果它运行了三个月后突然崩溃了，天哪!难道我们要把三个月的操作重新做一遍?!当然不能这样，Recovery Interval会控制这一切!

Recovery Interval会告诉SQL Server，如果要通过日志里面的操作进行恢复不能超过多少时间。那么SQL Server就会看好这一切，当它发现日志里面的新的操作需要超过Recovery Interval的时间进行恢复的时候，SQL Server就像强制将内存那些被修改过的数据写回到磁盘里面去。

这样我们就不用重新执行那三个月的操作了，通常都是短短的5分钟，因为默认Recovery Interval是5分钟。

那么我们怎么调节这个值呢?

Recovery Interval的值越长，那么也就意味着万一我们的系统崩溃了，我们就需要更长的时间进行恢复，不过也就以为那些被修改过的数据可以在内存中停留更长的时间，也就意味着我们可以写磁盘写的更少一些。

相反，如果Recovery Interval的值约短，那么也就意味着万一我们的系统崩溃了，我们就需要恢复的时间就更短，另外一方面也就意味着我们可以写磁盘写的更频繁一些。

 下面的示例将系统恢复间歇设为 3 分钟。

USE master0
EXEC sp_configure 'recovery interval', '3'
RECONFIGURE WITH OVERRIDE