當系統出現故障時，只要存在數據日志那麼就可以利用它來恢復數據解決數據庫故障。作為SQL Server數據庫管理員，了解數據日志文件的作用，以及如何利用它來解決一些數據庫的常見故障，這非常重要。既然事務日志這麼重要，那麼他到底可以用來做什麼事情呢?口說無憑，筆者這裡就跟大家說說事務日志到底可以用來解決什麼故障。
故障一：服務器意外關閉造成的損失
俗話說，天又不測風雲。數據庫服務器如果因為突然斷電或者其他一些原因意外當機時，再重新啟動服務器後會出現一些數據的損失。這主要是因為數據庫中的數據發生更改後，並不會在第一時間就把數據寫入到硬盤中。為了提高數據庫的運行效率，往往是先把數據寫入到數據高速緩存中;同時把更改的情況寫入到事務日志中。等到一定的情況數據庫系統才會把數據寫入到硬盤文件中。
此時，如果數據庫服務器系統突然發生故障，數據庫系統就有可能還沒有把緩存中的修改後的數據寫入到硬盤中，即數據文件內有未完成事務所做的修改。如果確實有這種情況，則當啟動SQL Server實例時，如果沒有事務日志或者事務日志損壞時，修改後的數據就無法恢復過來了。但是，如果當事務日志可用的話，則當實例啟動時，系統會丟每個數據庫執行恢復操作。前滾日至中記錄的、可能尚未寫入數據文件的每個修改。在事務日志中找到的每個未完成的事務都將回滾，以確保數據庫數據的完整性。
所以當數據庫服務器意外故障時，數據庫管理員最好能夠確認一下事務日志是否可用。如果事務日志已經損壞，那麼就需要先恢復事務日志然後再重新啟動數據庫實例。否則的話，數據庫實例在重新啟動時不能夠正常恢復數據。這一點在遇到服務器突發行的故障時一定要注意。否則的話，很可能破壞數據庫數據的完整性。
故障二：解決備份數據庫的數據同步問題
有時候出於數據庫高可用性的目的，需要在生產服務器之外的地方再部署一台數據庫服務器。當生產服務器出現故障不可用時，則可以馬上啟用這個備用的服務器。故就需要保證生產服務器與備用服務器之間數據的同步。那麼SQL Server數據庫是通過什麼技術來達到這個生產服務器與備份服務器之間的數據同步的呢?簡單的說，就是通過這個事務日志的復制來實現數據同步的。具體的來說，SQL Server數據庫提供了兩種解決方案，分別為數據鏡像與日志傳送。這兩個方案都是在事務日志復制的基礎上來實現的。
在日志傳送方案中，生產服務器將生產數據庫的活動事務日志發送到一個或多個目標服務器。每個輔助服務器將該日志還原為其本地的輔助數據庫，從而實現備用服務器與生產服務器之間數據的一致性。使用日志傳送，您可以自動將“主服務器”實例上“主數據庫”內的事務日志備份發送到單獨“輔助服務器”實例上的一個或多個“輔助數據庫”。事務日志備份分別應用於每個輔助數據庫。可選的第三個服務器實例(稱為“監shi服務器”)記錄備份和還原操作的歷史記錄及狀態，還可以在無法按計劃執行這些操作時引發警報。日志傳送配置中的主服務器是作為生產服務器的 SQL Server 數據庫引擎實例。主數據庫是主服務器上希望備份到其他服務器的數據庫。通過數據庫進行的所有日志傳送配置管理都是在主數據庫中執行的。另外需要注意的是，如果采用日志傳送方案對於生產服務器的工作模式有限制。生產數據庫必須使用完整恢復模式或大容量日志恢復模式。如果將數據庫切換為簡單恢復模式會導致日志傳送停止工作。
一台備用服務器可以包含多台不同生產服務器中數據庫的備份副本。例如，某個集團公司可能有三台數據庫服務器，每台服務器都運行關鍵數據庫系統。在這種情況下，可以只使用一台輔助服務器，而不必使用三台單獨的輔助服務器。三個主系統上的備份都可以加載到這個備份系統中，從而減少所需的資源數量並節省開支，也可以數據庫管理員的工作量。
另外也可以通過數據庫鏡像方案中來解決生產服務器與備用服務器之間的數據同步問題。生產數據庫的每次更新都在獨立的、完整的備份數據庫中立即重新生成。主體服務器實例立即將每個日志記錄發送到鏡像服務器實例，鏡像服務器實例將傳入的日志記錄應用於鏡像數據庫，從而將其繼續前滾。“數據庫鏡像”是用於提高數據庫可用性的首選軟件解決方案。鏡像基於每個數據庫實現，並且只適用於使用完整恢復模式的數據庫。簡單恢復模式和大容量日志恢復模式不支持數據庫鏡像。因此，所有大容量操作始終被完整地記入日志。數據庫鏡像可使用任意支持的數據庫兼容級別。在“數據庫鏡像模式”中，主體服務器和鏡像服務器作為伙伴進行通信和協作。兩個伙伴在會話中扮演互補的角色：主體角色(生產服務器)和鏡像角色(備份服務器)。在任何給定的時間，都是一個伙伴扮演生產服務器角色，另一個伙伴扮演備用服務器角色。如果生產服務器角色出現故障時，則備份服務器角色馬上會頂替出現故障的生產服務器角色，轉變為生產服務器角色。從而實現數據庫的高可用性。
數據庫鏡像方案有兩種鏡像運行模式。一種是“高安全性模式”，它支持同步操作。在高安全性模式下，當會話開始時，鏡像服務器將使鏡像數據庫盡快與主體數據庫同步，一旦同步了數據庫，事務將在伙伴雙方處提交，這會延長事務滯後時間。第二種運行模式，即高性能模式，它與第一種模式的主要差異就在於異步運行。鏡像服務器嘗試與主體服務器發送的日志記錄保持同步。鏡像數據庫可能稍微滯後於主體數據庫。但是，數據庫之間的時間間隔通常很小。但是，如果主體服務器的工作負荷過高或鏡像服務器系統的負荷過高，則時間間隔會增大。在高性能模式中，主體服務器向鏡像服務器發送日志記錄之後，會立即再向客戶端發送一條確認消息。它不會等待鏡像服務器的確認。這意味著事務不需要等待鏡像服務器將日志寫入磁盤便可提交。此異步操作允許主體服務器在事務滯後時間最小的條件下運行，但可能會丟失某些數據。具體采用哪種模式，則需要數據庫管理員根據企業對待數據損失的態度與工作負荷等來確定。
可見現在可用的備份服務器與生產服務器之間的數據同步解決方案都是基於事務日志來實現的。
