淺談SQL Server中的事務日志(五)----日志在高可用和災難恢復中的作用

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

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

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

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

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

簡介

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

日志損壞

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

1.數(shù)據(jù)庫正常關閉，日志損壞。

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

圖1.如果數(shù)據(jù)庫正常關閉，直接附加即可

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

2.數(shù)據(jù)庫非正常關閉，日志損壞

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

    圖2.數(shù)據(jù)庫所能處在的狀態(tài)關系

    上面的幾種狀態(tài)的具體轉換關系超出了本文的討論范圍，但是這里我會強調兩種和日志損壞關系很大的狀態(tài)：RECOVERY_PENDING和SUSPECT狀態(tài)。

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

    此時，數(shù)據(jù)庫可能處于下面兩種狀態(tài)之一：

• RECOVERY_PENDING:需要運行crash recovery，但該過程由于資源等待無法開始，比如說日志完全損壞
• SUSPECT：crash recovery已經(jīng)開始，但無法完成

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

ALTER DATABASE AdventureWorks2012 SET EMERGENCY

代碼清單1.將數(shù)據(jù)庫設置為緊急模式

    與該模式有關的一個選項是REPAIR_ALLOW_DATA_LOSS，該選項依然會執(zhí)行crash recovery過程，但會跳過受損的日子，從而盡可能的修復數(shù)據(jù)一致性問題，該選項會創(chuàng)建一個新的日志文件，最后使得數(shù)據(jù)庫處于ONLINE狀態(tài)，使用該選項的一個簡單例子如代碼清單2所示。

ALTER DATABASE AdventureWorks2012 SET SINGLE_USER

DBCC CHECKDB(AdventureWorks2012,REPAIR_ALLOW_DATA_LOSS)

代碼清單2.使用REPAIR_ALLOW_DATA_LOSS選項

    值得注意的是，作為DBA永遠是要有“備”無患，上面這些操作是在您準備工作不充分的情況下才要去考慮的。

3.數(shù)據(jù)庫處于在線狀態(tài)，日志損壞

    在這種情況下，如果SQL Server在運行時需要使用的日志損壞（比如說回滾時），則SQL Server會將數(shù)據(jù)庫下線，并轉為SUSPECT模式。

    同樣如果沒有備份的話，只能考慮使用EMERGENCY模式。

    還有一種方式是，將數(shù)據(jù)庫的恢復模式改為簡單，然后手動發(fā)起一個CheckPoint來截斷日志，最后再將數(shù)據(jù)庫改回完整恢復模式。但這種方式會破壞日志鏈。但可能會將被損壞的日志清除掉。

日志在高可用性中的作用

鏡像與AlwaysOn

    這兩種高可用性技術都是基于日志來維護一個數(shù)據(jù)庫的副本。通過將日志實時的傳送到副本，在副本上來不斷的進行REDO操作，就可以保證主體和副本數(shù)據(jù)庫之間的實時同步。

    對于鏡像來說，可以同步或異步將日志傳送的1個副本。

    而對于AlwaysOn可用性組來說，就可以將日志最多同步到2個副本+異步到2個副本（據(jù)說SQL Server 2014已經(jīng)將該特性翻倍，也就是最多可以4個同步副本和最多4個異步副本，但目前還沒有發(fā)布，所以只是小道消息）。

    所謂的同步概念就是主副本只有將傳送的日志發(fā)送到輔助副本之后，由輔助副本返回ACK信息后，才能夠在本地提交，因此可能會造成明顯的延遲并影響性能。這里還值得注意的是，主副本不是等待事務在輔助副本提交之后才能提交，而是只是需要收到輔助副本返回的收到日志的ACK信息即可。

    無論對于上面兩種高可用特性，無論是哪一種，都需要考慮監(jiān)控發(fā)送隊列和REDO隊列。發(fā)送隊列過長意味著當故障轉移時，可能丟失大量數(shù)據(jù)，同時還會阻止日志截斷。REDO隊列過長意味著當故障轉移時，RECOVERY截斷將會消耗更多的時間，從而使得故障轉移消耗的宕機時間延長。這兩種隊列的監(jiān)控都可以使用性能監(jiān)視器進行，如圖3所示。

圖3.監(jiān)控隊列的計數(shù)器

事務日志傳送

    相比其他高可用性功能來說，事務日志傳送功能比較簡單。本質上就是一個不斷備份、傳送、還原日志的過程。使用事務日志傳送對于測試日志是否有效來說非常合適。

    事務日志傳送還有一點值得注意的地方就是，當有批量操作的時候，考慮使用大容量事務日志模式，從而避免大量的日志通過網(wǎng)絡傳輸。

    事務日志對于維護一個數(shù)據(jù)庫冗余的副本來說是最簡單的方式，雖然不能保證數(shù)據(jù)實時，但對于特定業(yè)務場景還是非常有意義的。

事務復制

    與前幾種高可用性特性不同的是，事務日志無法直接傳送事務日志。因為發(fā)布端和訂閱端數(shù)據(jù)庫的結構可以完全不一樣，訂閱端可以僅僅訂閱一個或多個表，表中的一部分列，或是一部分數(shù)據(jù)子集。由于發(fā)布端和訂閱端的表結構和數(shù)據(jù)不一致，因此無法直接將發(fā)布端的日志傳送到訂閱端。

    因此事務復制的原理是Log Reader Agent定期讀取發(fā)布端的日志，匯總日志對發(fā)布內容的更改，從而將這些更改變?yōu)檫壿嫴僮鳎瑥亩沟糜嗛喍丝梢訰eplay這些操作來打到數(shù)據(jù)同步的目的。

    這里值得注意的是，如果Log Reader Agent還沒有掃描最新的修改，事務復制可能造成發(fā)布端的日志無法截斷。

小結

    本篇文章作為對前面四篇文章的補充，講述了日志在災難恢復和高可用性中的原理和作用。這些原理對于設計一個好的備份計劃、高可用性計劃來說，是必不可少的。