SQL Server中的交易記錄管理(4/9)：簡單復原模式裡的日誌管理

標籤：

當一切正常時，沒有必要特別留意什麼是交易記錄，它是如何工作的。你只要確保每個資料庫都有正確的備份。當出現問題時，交易記錄的理解對於採取修正操作是重要的，尤其在需要緊急恢複資料庫到指定點時。這系列文章會告訴你每個DBA應該知道的具體細節。

這個標題近乎是用詞不當，因為很大程度上，運行在簡單模式裡不需要日誌管理。在簡單模式裡，交易記錄的唯一目的是在資料庫恢複操作期間，保證事務的ACID屬性，還有強制資料庫的一致性和事務的持久性。交易記錄不能被備份，不能用來資料庫恢複，也不能用作日誌傳輸。

在簡單模式裡工作

所有事務還是被記錄，儘管特定大容量操作是最小化日誌；實際上，記錄層級和大容量日誌裡的應用非常類似。日誌的活動部分還是照常維護，因此任何時候資料庫在簡單模式裡啟動後，恢複進程會進入，資料檔案會用交易記錄內容調和。

但是，在簡單模式裡，所有的虛擬記錄檔（VLF）被標記為如第2篇裡的不活動（可恢複），在週期性資料庫檢查點期間會自動截斷。這就是說，當檢查點發生時，檔案裡任何最高LSN小於最低LSN的VLF都會被截斷，結果在事務檔案裡的空間會定期和經常重用。

簡單復原模式裡的資料庫總會是自動截斷模式。如第3篇裡描述的，所有的使用者資料庫，在第一次完整備份進行前，實際上是自動截斷模式。

檢查點多少時間發生一次？

為了恢複資料庫到恢複區間（recovery interval）伺服器配置選項指定時間裡，基於需要處理的日誌記錄數，SQL Server引擎決定多少時間進行一次檢查點。如果你的資料庫是唯讀，檢查點之間的時間可能會很長。但是，在業務上頻繁更新的系統，檢查點會近每一分鐘發生一次。點擊https://msdn.microsoft.com/zh-cn/library/ms189573.aspx查看詳細介紹。

正如上一篇文章討論的，完整復原模式裡，交易記錄維護“不活動的曆史或關閉的事務”，連同活動/開啟的事務。這個”曆史“可以在記錄備份裡捕獲，用來還原資料庫到先前的一個時間點。但是，在簡單模式裡，這個曆史不存在因此日誌不能用來還原資料庫到先前的一個時間點。事實上，在簡單復原模式裡，你甚至不能進行交易記錄備份，如下代碼所示範。

1  USE master;2   ALTER DATABASE TestDB3   SET RECOVERY SIMPLE;4   BACKUP Log TestDB5     TO DISK =‘C:\BACKUP\TestDB_log.bak‘6     GO

這表示你的備份計劃只能在完整和差異備份計劃裡執行。

簡單模式的支援與反對

簡單模式的缺點，肯定是你遺失資料的機率會很高，因為你只能恢複資料庫到最近的完整或差異備份。剛才提到過，如果遺失資料是以分鐘衡量，不是以小時衡量，不要使用簡單模式。

但是，如果你啟動並執行是開發或測試資料庫，或者甚至是一個唯讀生產資料庫，那麼使用簡單模式可能是一個可行的，甚至是一個明智的選擇，這會大大減輕資料庫上的維護負擔。備份的儲存空間會更少，後續的恢複操作會更簡單。此外，因為交易記錄是自動截斷的，你很少有日誌增長失控的風險，引起9002錯誤。

儘管簡單模式明顯減輕了交易記錄管理的負擔，這樣認為是錯誤的。如果你使用這個模式，你會完全忘記日誌維護。交易記錄在資料庫的日常操作中還是扮演著重要角色，你還是需要正確調整交易記錄的大小和增長，根據資料庫受到的事務本質和頻率。不是因為日誌是自動截斷的，這不表示健壯和長時間啟動並執行事務不會導致日誌快速增長，如果你沒有正確調整大小，還是會給你帶來麻煩——這個會在第7篇-第8篇詳細介紹。

SQL Server中的交易記錄管理(4/9)：簡單復原模式裡的日誌管理