恢復模式（Recovery Models）

對于這個問題的最簡單的答案是不會：恢復模型不會影響故障恢復，只用簡單恢復模式你不會丟失事務。那數據庫恢復模型的目的是什么？

你用恢復模型你只告訴SQL Server如何處理事務日志。SQL Server提供下列3個恢復模型：

完整（FULL）
簡單（SIMPLE）
大容量日志（BULK_LOGGED）

我們來細談下。每個新建的數據庫默認是完整恢復模式（在完整數據庫備份后！）。完整恢復模式意味著你需要進行定期事務日志備份。在事務日志備份后，SQL Server可以標記VLFs（虛擬日志文件（Vitural Log Files））為不活動，在下個檢查點可以重寫它們。如果你不進行定期的事務日志備份，SQL Server不能重寫VLFs（因為它們還是活動的），這樣的話你的事務日志會增長。

增長事務日志很慢（因為需要零值初始化（Zero Initialization））并導致日志碎片（Log Fragmentation）（大量不同的VLFs）。定期日志備份的另一個好處是你可以進行所謂的時間點恢復（Point in Time Recovery），即恢復你的數據庫到指定的時間點。

如果你不在乎你的數據（我會被大家笑話的！），你可以把你的數據庫恢復模式切換為簡單。使用簡單恢復模式，你不需要麻煩自己進行日常事務日志備份，因為在檢查點（CHECKPOINT）SQL Server會標記VLFs為不活動。如果你沒有長時間運行的事務，在這個恢復模式里，你的事務日志不會增長。簡單恢復模式的一個副作用就是你不能進行時間點恢復（Point in Time Recovery）。

當你的數據庫崩潰或損壞，你只能恢復你的數據庫到你最近的完整數據庫備份，外加可用的差異備份。在這個情況下你丟失多少數據取決于你最近的完整/差異備份的情況。對于OLTP數據庫，我從不推薦簡單恢復模式。在數據倉庫的情景下倒可以使用，因為存儲的數據基本不會有啥改變。

最后SQL Server還提供你大容量日志恢復模式。在SQL Server里，當你運行特定的操作，它們可以是最小化日志（Minimally Logged）（在SQL Server里沒有無日志操作！）。如果你用的是大容量日志恢復模式。最小化日志意味著SQL Server不會寫各個事務日志記錄到事務日志，當你進行這樣操作的時候。

SQL Server只通過所謂的BCM頁（大容量修改映射頁（Bulk Changed Map Page））標記修改的區為已修改。這樣的話，當你進行最小化日志操作時，你的事務日志不會變得那么大。不好的副作用是在那期間（數據庫運行在大容量日志恢復模式）你不能進行時間點恢復。因此在這個恢復模式下，你應該盡量縮短它的時間。例如：當你在運行最小化日志操作的時候，你才把數據庫從完整恢復模式切換回大容量日志模式（運行完后切換回完整恢復模式）。

當你運行在大容量日志恢復模式里，你還是要進行事務日志備份。但它們的大小不會變小，因為SQL Server復制修改的分區（基于BCM頁）到事務日志備份——如你從下圖看到的一樣。