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