善用事務日誌解決 SQL Server 四大經典故障

事務日誌的核心價值

SQL Server 採用預寫日誌機制：資料修改先寫入記憶體緩存，同步記錄到事務日誌；資料檔案異步寫入。事務日誌記錄了每一筆修改的完整資訊，是資料庫恢復、高可用、一致性的基石。

故障一：伺服器意外關機導致資料損失

現象

斷電、藍屏等導致實例異常終止，記憶體中未刷新到磁碟的修改面臨丟失風險。

恢復機制

重啟實例時，SQL Server 對每個資料庫執行恢復操作：

• 前滾：重放日誌中已提交但未寫入資料檔的修改
• 回滾：撤銷日誌中未提交事務的修改

關鍵提醒

若事務日誌損壞或不可用，恢復將失敗。故障發生時首要確認日誌可用性，必要時先修復日誌再啟動實例。

故障二：備份伺服器資料同步問題

兩大基於日誌傳輸的高可用方案：

兩者均要求資料庫使用完整恢復模式或大量記錄恢復模式。

故障三：資料一致性問題（如轉賬失敗）

場景

轉賬：扣款成功、入賬失敗 → 資料不一致。

解決

應用程式捕獲異常後執行 ROLLBACK，資料庫引擎利用事務日誌撤銷已完成的扣款操作，恢復一致性。這是事務原子性的典型應用。

故障四：時間點恢復

場景

上午 11 點故障，上次完整備份是昨晚 12 點。僅靠完整備份會丟失 11 小時資料。

解決

1. 還原完整備份（恢復到昨晚 12 點）
2. 應用事務日誌備份（或尾日誌），恢復到故障前任意時間點（如上午 10:59）

前提：事務日誌完整、未截斷、採用完整恢復模式。

最佳實踐建議

• 定期備份事務日誌，並驗證可還原性
• 監控日誌空間使用率，防止日誌填滿導致資料庫掛起
• 重要系統部署日誌傳送或鏡像，實現異地災備
• 熟練掌握 RESTORE LOG ... WITH STOPAT 時間點恢復語法

總結

事務日誌不僅是恢復的「時光機」，更是高可用架構的「生命線」。DBA 應將日誌管理納入核心運維體系，做到有備無患。