（2.8）備份與還原--在大容量恢復模式下事務日誌的角色
簡介
日誌的作用是保證持久性和數據一致性，通過日誌可以實現數據的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
代碼清單1.將數據庫設置為緊急模式
與該模式有關的一個選項是REPAIR_ALLOW_DATA_LOSS，該選項依然會執行crash recovery過程，但會跳過受損的日子，從而盡可能的修復數據一致性問題，該選項會創建一個新的日誌文件，最後使得數據庫處於ONLINE狀態，使用該選項的一個簡單例子如代碼清單2所示。
ALTER DATABASE AdventureWorks2012 SET SINGLE_USER
DBCC CHECKDB(AdventureWorks2012,REPAIR_ALLOW_DATA_LOSS)
代碼清單2.使用REPAIR_ALLOW_DATA_LOSS選項
值得註意的是，作為DBA永遠是要有“備”無患，上面這些操作是在您準備工作不充分的情況下才要去考慮的。
3.數據庫處於在線狀態，日誌損壞
在這種情況下，如果SQL Server在運行時需要使用的日誌損壞（比如說回滾時），則SQL Server會將數據庫下線，並轉為SUSPECT模式。
同樣如果沒有備份的話，只能考慮使用EMERGENCY模式。
還有一種方式是，將數據庫的恢復模式改為簡單，然後手動發起一個CheckPoint來截斷日誌，最後再將數據庫改回完整恢復模式。但這種方式會破壞日誌鏈。但可能會將被損壞的日誌清除掉。
日誌在高可用性中的作用
鏡像與AlwaysOn
這兩種高可用性技術都是基於日誌來維護一個數據庫的副本。通過將日誌實時的傳送到副本，在副本上來不斷的進行REDO操作，就可以保證主體和副本數據庫之間的實時同步。
對於鏡像來說，可以同步或異步將日誌傳送的1個副本。
而對於AlwaysOn可用性組來說，就可以將日誌最多同步到2個副本+異步到2個副本（據說SQL Server 2014已經將該特性翻倍，也就是最多可以4個同步副本和最多4個異步副本，但目前還沒有發布，所以只是小道消息）。
所謂的同步概念就是主副本只有將傳送的日誌發送到輔助副本之後，由輔助副本返回ACK信息後，才能夠在本地提交，因此可能會造成明顯的延遲並影響性能。這裏還值得註意的是，主副本不是等待事務在輔助副本提交之後才能提交，而是只是需要收到輔助副本返回的收到日誌的ACK信息即可。
無論對於上面兩種高可用特性，無論是哪一種，都需要考慮監控發送隊列和REDO隊列。發送隊列過長意味著當故障轉移時，可能丟失大量數據，同時還會阻止日誌截斷。REDO隊列過長意味著當故障轉移時，RECOVERY截斷將會消耗更多的時間，從而使得故障轉移消耗的宕機時間延長。這兩種隊列的監控都可以使用性能監視器進行，如圖3所示。
圖3.監控隊列的計數器
事務日誌傳送
相比其他高可用性功能來說，事務日誌傳送功能比較簡單。本質上就是一個不斷備份、傳送、還原日誌的過程。使用事務日誌傳送對於測試日誌是否有效來說非常合適。
事務日誌傳送還有一點值得註意的地方就是，當有批量操作的時候，考慮使用大容量事務日誌模式，從而避免大量的日誌通過網絡傳輸。
事務日誌對於維護一個數據庫冗余的副本來說是最簡單的方式，雖然不能保證數據實時，但對於特定業務場景還是非常有意義的。
事務復制
與前幾種高可用性特性不同的是，事務日誌無法直接傳送事務日誌。因為發布端和訂閱端數據庫的結構可以完全不一樣，訂閱端可以僅僅訂閱一個或多個表，表中的一部分列，或是一部分數據子集。由於發布端和訂閱端的表結構和數據不一致，因此無法直接將發布端的日誌傳送到訂閱端。
因此事務復制的原理是Log Reader Agent定期讀取發布端的日誌，匯總日誌對發布內容的更改，從而將這些更改變為邏輯操作，從而使得訂閱端可以Replay這些操作來打到數據同步的目的。
這裏值得註意的是，如果Log Reader Agent還沒有掃描最新的修改，事務復制可能造成發布端的日誌無法截斷。
小結
本篇文章作為對前面四篇文章的補充，講述了日誌在災難恢復和高可用性中的原理和作用。這些原理對於設計一個好的備份計劃、高可用性計劃來說，是必不可少的。
轉自：http://www.cnblogs.com/CareySon/archive/2013/06/16/3138742.html
評論列表 回復引用 #1樓 2013-12-13 20:44 樺仔 所謂的同步概念就是主副本只有將傳送的日誌發送到輔助副本之後，由輔助副本返回ACK信息後，才能夠在本地提交，因此可能會造成明顯的延遲並影響性能。這裏還值得註意的是，主副本不是等待事務在輔助副本提交之後才能提交，而是只是需要收到輔助副本返回的收到日誌的ACK信息即可
我明白鏡像的兩個性能模式了
運行模式
l 高性能模式（異步運行）：事務不需要等待鏡像服務器將日誌寫入磁盤便可提交，這樣可最大程度地提高性能。這意味著事務不需要等待鏡像服務器將日誌寫入磁盤便可提交，而此操作允許主體服務器在事務滯後時間最小的條件下運行，但可能會丟失某些數據。
l 高安全模式（同步運行）：當會話開始時，鏡像服務器使鏡像數據庫盡快與主體數據庫同步。一旦同步了數據庫，事務將在雙方提交，這會延長事務滯後時間。 支持(0)反對(0) 回復引用 #2樓 2018-05-28 10:15 M哥 alwayson的同步也是偽同步，只是作為確保主從數據強一致性，相對來說延遲還是有的。
（2.8）備份與還原--在大容量恢復模式下事務日誌的角色