簡介

　　最近測試伺服器進行資料歸檔，其間程式設計師發現一個問題，空間不足，我檢視原因發現日誌檔案暴漲。然後將資料庫改為簡單恢復模式，但是依然存在這個問題。經過查詢資料發現了日誌檔案在簡單模式下依然增加的原因。

Simple概念

　　Simple恢復模式也叫做”Checkpoint with truncate log“，其實這個名字更形象，在Simple模式下，SQL Server會在每次checkpoint或backup之後自動截斷log，也就是丟棄所有的閒置日誌記錄，僅保留用於例項啟動時自動發生的instance recovery所需的少量log，這樣做的好處是log檔案非常小，不需要DBA去維護、備份log，但壞處也是顯而易見的，就是一旦資料庫出現異常，需要恢復時，最多隻能恢復到上一次的備份，無法恢復到最近可用狀態，因為log丟失了。

Checkpoint

　　CheckPoint和lazyWriter一樣，都會將緩衝區內臟資料寫入到磁碟，同時在簡單恢復模式下截斷日誌；lazyWriter快取不足的時候會觸發執行，這裡我們暫且不做討論。

針對CheckPoint我請教了Careyson以後總結出以下幾個觸發其執行的原因：

1. 一些Internal CheckPoint時，比如說關閉資料庫例項等。
2. 資料庫完整備份或差異備份(日誌備份不會觸發checkpoint)。
3. 資料庫恢復模式為簡單恢復模式下當日志文件使用超過70%時。
4. CheckPoint執行的時間間隔閾值被足夠多的日誌記錄超過。
5. 手動執行CheckPoint。

場景描述：

　　Simple模式主要用於非critical的業務，比如開發庫和測試庫，那麼這次由於測試環境的磁碟緊張我們也都採用了簡單模式。但是資料歸檔發生時依然產生了大量的日誌，並且增加了磁碟佔用，這又是什麼原因那？因為我們在歸檔處理中使用了大量的insert和delete以及update操作，這樣話，短時間內產生了大量的日誌，這個時候日誌迅速增加；又因為在SQL Server中，CheckPoint是一個完整的過程，這個過程的耗時取決於髒資料的大小。一旦在很短時間內，日誌的CheckPoint沒完成的時候日誌增加超過了日誌的規定上限。則將產生更多的日誌。

　　如上所述，產生這個問題的原因就是：CheckPoint時間間隔閾值被足夠多的日誌記錄超過,觸發CheckPoint才寫入磁碟。

　　下面這個例項來自於：

 　  讓我們用一個指令碼來實際的闡明這種行為。首先在一個測試資料庫中執行一下指令碼建立一個測試表並填充一些資料。

　　測試資料庫設定：

　　1.設定為簡單的恢復模式。

　　2.日誌的大小為100M。

　　3.日誌檔案的自動增長被禁用（因為觀察日誌空間被用完的錯誤比檢查自動增長要容易）。

 　　執行以下指令碼，觀察資源競爭：

 反覆根據修改@change_size來看結果，當我將@change_size改為120甚至更大時，得到了9002的錯誤資訊，非常準確的告訴我資料庫的事務日誌已滿。

通過上面這個引用的例子，很好地再現了問題的產生機制，那麼我們怎麼處理這個情況那？

解決

　　方案1：

　　強制執行CheckPoint。但是執行後有個很不好的影響，嚴重影響了儲存過程的執行時間。由此可知這樣做很消耗效能啊。

　　方案2：

　　縮短CheckPoint時間間隔閾值。

 預設值是0，意味著由SQL Server來管理這個回覆間隔。 　　

 也可以SQL語句實現這個功能：

　　方案3：

　　增大日誌檔案大小。

總結：

　　日誌檔案是一個雙刃劍，WAL機制很好的保證了資料的一致性和維護性。但是也產生了額外的效能和維護的成本的上升。需要我們根據實際情況去處理這些不同的情景。需要注意的是在TempDB中是不會產生日誌的，除非手動執行。除此之外，並非所有的時間間隔後都會產生日誌，因為當資料很少的時候有可能不觸發Checkpoint執行。