幾個星期前一個網友問我，設置數據庫恢復模式為簡單是否是個好的做法，還有這個做法有什么缺點？
我不能特別強調，但對於OLTP工作負荷（典型讀寫操作）的數據庫，使用簡單恢復模式真的不是好主意。而且設置數據庫模式為簡單真的……（自己想象省略號是啥）。但我不想在這篇文章里說明這個事實，我只想向你展示下，在OLTP數據庫運行簡單恢復模式，有什么副作用。
你的備份/還原策略——簡單恢復模式
當我進行SQL Server體檢時，或者當我進行現場客戶咨詢時，有時我會看到生產OLTP數據庫在簡單恢復模式里運行，我被徹底打敗了！你在和你的生活和工作開玩笑！
當我和DBA們談論這個問題時，他們大多說，設置數據庫為簡單恢復模式是因為它們有自增長的事務日志問題。很多人他們還不知道可以通過定期日志文件備份來保持事務日志大小可控。這也是默認完整恢復模式的重要前提：定期事務日志備份！
在簡單恢復模式里，你不需要任何事務日志備份（也不可能備份），因為SQL Server自己為你管理事務日志， 且定期覆蓋它。作為副作用，你不需要事務日志備份，你的事務日志不會增長。
但缺點是什么？你不能進行事務日志備份！定期事務日志備份是任何OLTP數據庫的最重要的一部分——不管你使用的是哪個關系數據庫（RDBMS）！當你在簡單恢復模式里運行你的數據庫，你只能進行完整和差異數據庫備份。沒別的！
但現在假設你的最后完成或差異比分是幾天前（甚至幾個星期前），現在因為一些問題（用戶誤操作，損壞的數據庫等等）。你必須還原你的數據庫。哈！你的數據丟失會很大，因為自上一次備份后的數據會直接丟失！
但當你進行定期事務日志備份（你使用完整恢復模式），在你要還原數據庫的時候，情況就完全不一樣。因為當你還原上一次完整和差異備份，你也可以還原所有各個隨后發生的事務日志備份。這就是說你會盡可能丟失更少的數據，因為你已經進行了定期和頻繁的事務日志備份。
多少頻率？這取決於你打算丟失多少數據。這也是你所謂的恢復點目標（Recovery Point Objective (RPO)）。這主要取決於你的業務需求。我見過每小時，每15分鍾，甚至每分鍾備份事務日志的用戶。而且事務日志還在繼續進行：一個接一個的備份。這真的取決於你的RPO，還有你投入的資金。數據永不丟失（每個業務都想這樣）是機會不可能的，而且非常昂貴……
你的高可用性（HA）選項——沒有！
當你在簡單恢復模式里運行你的數據庫，你的高可用性選項也非常有限。幾乎當下SQL Server每個HA技術（AlwaysOn 可用性組，數據庫鏡像，事務日志傳遞）都依賴於事務日志和定期事務日志備份。如果你想使用可用性組或數據庫鏡像，你的數據庫要運行在完整恢復模式。其他模式不支持，技術上也是不可能的。
如果你想使用事務日志傳遞（還是個很好的技術！）你要在大容量日志模式里運行你的數據庫。如果你使用簡單，你不能使用事務日志傳遞。下次你想修改你的數據庫恢復模式是就要考慮下它的副作用。
小結
說實話：如果你有生產OLTP數據庫，並且你在乎你的數據，你必須使用完整恢復模式。沒有什么取決於……的建議。設置數據庫為簡單並不是好的主意。因此下次你想修改數據庫恢復模式時，認真考慮下這些事情。
原文鏈接
http://www.sqlpassion.at/archive/2016/11/14/why-the-recovery-model-simple-is-a-really-bad-idea/