本篇文章是系列文章中的第五篇，是對前一個日志系列的補充篇。如果您對日志的基本概念還沒有一個比較系統的了解，可以參看本系列之前的文章： 淺談SQL Server中的事務日志(一)----事務日志的物理和邏輯構架 淺談SQL Server中的事務日志(二)----事務日志在修

本篇文章是系列文章中的第五篇，是對前一個日志系列的補充篇。如果您對日志的基本概念還沒有一個比較系統的了解，可以參看本系列之前的文章：

淺談SQL Server中的事務日志(一)----事務日志的物理和邏輯構架

淺談SQL Server中的事務日志(二)----事務日志在修改數據時的角色

淺談SQL Server中的事務日志(三)----在簡單恢復模式下日志的角色

淺談SQL Server中的事務日志(四)----在完整恢復模式下日志的角色

簡介

日志的作用是保證持久性和數據一致性，通過日志可以實現數據的Undo與Redo，因此通過日志，SQL Server不僅僅可以實現災難恢復，還可以通過日志的Redo來實現高可用性。本篇文章主要講述日志在SQL Server中提供的幾種高可用性中的作用以及在災難恢復中的角色。

日志損壞

日志可能會由于IO子系統的故障而損壞，當出現日志損壞時，如果您對日志的原來略有了解，并能在日志損壞的情況下盡量挽救數據，那么感覺一定是非常好的：-)，下面我們來了解幾種日志損壞的情況下的恢復情況。

1.數據庫正常關閉，日志損壞。

當數據庫正常關閉時，日志損壞就不是那么重要了，因為此時數據庫中所有提交的事務對應的臟數據都已經CheckPoint到物理磁盤，因此不存在數據不一致的問題。因此，如果MDF和NDF文件完好，直接指定 FOR ATTACH_REBUILD_LOG參數后附加即可，如圖1所示。

圖1.如果數據庫正常關閉，直接附加即可

但值得注意的是，使用該方式附加數據庫會自動重建日志文件，日志文件大小為0.5MB，也就是2個VLF，自動增長為10%，因此您需要手動再來設置一下日志的大小，避免出現太多VLF的情況。

2.數據庫非正常關閉，日志損壞

在講述這種情況之前，我們首先來看數據庫所能處在的幾種狀態，一個完整的模型如圖2所示。

圖2.數據庫所能處在的狀態關系

上面的幾種狀態的具體轉換關系超出了本文的討論范圍，香港虛擬主機，但是這里我會強調兩種和日志損壞關系很大的狀態：RECOVERY_PENDING和SUSPECT狀態。

假如出現了數據庫沒有正常關閉，也就是還有數據沒有CheckPoint到磁盤，如果數據庫要啟動就必須經歷Recovery過程，如果日志損壞，則無法進行該Recovery過程，就會造成數據不一致的問題。

此時，數據庫可能處于下面兩種狀態之一：

RECOVERY_PENDING:需要運行crash recovery，但該過程由于資源等待無法開始，比如說日志完全損壞

SUSPECT：crash recovery已經開始，但無法完成

因此處理該類情況要基于您所在的業務環境是否允許數據損失，可以選擇從備份中恢復數據，或是將數據庫狀態改為EMERGENCY。EMERGENCY模式意味著數據庫跳過crash recovery階段，虛擬主機，香港虛擬主機，此時雖然可以訪問數據庫，但是會存在數據事務不一致的問題，如果僅僅是某些數據頁不一致還好，但如果是對表結構修改的事務存在，那就可能存在數據庫架構不一致的問題。如果您沒有合適的備份集，那只能通過該方式來恢復數據。將數據庫設置為EMERGENCY模式非常簡單，如代碼清單1所示。

ALTER DATABASE AdventureWorks2012 SET EMERGENCY

本文原創發布php中文網，轉載請注明出處，感謝您的尊重！

總結

以上是生活随笔為你收集整理的事物日志恢复 mysql_浅谈SQL Server中的事务日志(五)----日志在高可用和灾难恢复中的作用...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。