關於SQL事務日誌備份與恢復的奧祕
1、事務日誌備份只能與完全恢復模型和大容量日誌記錄恢復模型一起使用。在簡單模型下，事務日誌有可能被破壞，所以事務日誌備份可能不連續，不連續的事務日誌備份沒有意義，因爲基於日誌的恢復要求日誌是連續的。
2、一般情況下，事務日誌備份比數據庫備份使用的資源少。因此可以比數據庫備份更經常地創建事務日誌備份。經常備份將減少丟失數據的危險。
3、連續的事務日誌備份是備份和恢復事務日誌的基本要求。要將數據庫恢復到故障點，必須滿足3個條件。
1．正確的完整數據庫備份
這個很好理解，而且DBA一般都會做。
2．連續的事務日誌備份序列
除非存儲設備出現故障，否則這個問題也很好解決。
3．正確備份最後一個日誌備份和故障點之間的日誌
我們必須將這一段特殊的日誌（最後日誌備份完成時刻～故障點發生時刻）備份下來，從而使從完整數據庫備份時刻到故障點時刻的所有日誌備份序列是完整的！
連續的：事務日誌備份的LSN首尾連接，後一個日誌備份的FirstLSN等於前一個日誌備份的LastLSN。
不連續的：不連續的日誌備份就是指在產生的日誌備份序列中，出現了前後首尾不能續接的情況。這種情況主要發生在DBA不斷切換數據庫的恢復模型，比如從簡單恢復模型切換到完全恢復模型，或者從完全恢復模型切換到大容量日誌記錄模型，這都是DBA的大忌！
假如你的日誌備份出現下列情況。那麼，這樣的日誌序列LSN首尾不能銜接，無法連接起來執行恢復操作！DBA一定要千方百計確保當前日誌和日誌備份序列的安全，同時還要保證日誌序列的完整，判斷是否完整的方法就是執行restore headeronly語句。
4、因此，要想完成故障點的恢復，就必須完成尾日誌的備份. 當前日誌文件保存的內容包括了最後一個成功的日誌備份到當前故障點所有的事務。