簡介
SQL Server數據庫有三種恢復模式：簡單恢復模式、完整恢復模式和大容量日誌恢復模式
Simple 簡單恢復模式,
Simple模式的舊稱叫”Checkpoint with truncate log“，其實這個名字更形象，在Simple模式下，SQL Server會在每次checkpoint或backup之後自動截斷log，也就是丟棄所有的inactive log records，僅保留用於實例啓動時自動發生的instance recovery所需的少量log，這樣做的好處是log文件非常小，不需要DBA去維護、備份log，但壞處也是顯而易見的，就是一旦數據庫出現異常，需要恢復時，最多隻能恢復到上一次的備份，無法恢復到最近可用狀態，因爲log丟失了。 Simple模式主要用於非critical的業務，比如開發庫和測試庫，但是道富這邊的SQL Server（即使是生產庫）大都採用Simple模式，是因爲這邊的SQL Server大都用於非critical的業務（critical的數據庫大都採用Oracle和DB2)，可以忍受少於1天的數據丟失(我們的job每天都會定時備份全庫）。
如果需要壓縮數據庫日誌（Shrink語句），將數據庫模式切換到簡單恢復模式後壓縮率纔是最高的，如果你的數據庫在完整恢復模式或大容量日誌回覆模式下采用日誌壓縮，壓縮後的日誌大小並不會很理想。
Full 完整恢復模式,
和Simple模式相反，Full模式的舊稱叫”Checkpoint without truncate log“，也就是SQL Server不主動截斷log，只有備份log之後，纔可以截斷log，否則log文件會一直增大，直到撐爆硬盤，因此需要部署一個job定時備份log。Full的好處是可以做point-in-time恢復，最大限度的保證數據不丟失，一般用於critical的業務環境裏。缺點就是DBA需要維護log，增加人員成本（其實也就是多了定時備份log這項工作而已）。
Bulk-logged 大容量日誌恢復
Bulk-logged模式和full模式類似，唯一的不同是針對以下Bulk操作，會產生儘量少的log： 1) Bulk load operations (bcp and BULK INSERT). 2) SELECT INTO. 3) Create/drop/rebuild index 衆所周知，通常bulk操作會產生大量的log，對SQL Server的性能有較大影響，bulk-logged模式的作用就在於降低這種性能影響，並防止log文件過分增長，但是它的問題是無法point-in-time恢復到包含bulk-logged record的這段時間。 Bulk-logged模式的最佳實踐方案是在做bulk操作之前切換到bulk-logged，在bulk操作結束之後馬上切換回full模式。