1. 程式人生 > >(2.7)備份與還原--在完全恢復模式下事務日誌的角色

(2.7)備份與還原--在完全恢復模式下事務日誌的角色

ges 需要 很多 對數 for 事情 mage .com .html

簡介

生產環境下的數據是如果可以寫在資產負債表上的話,我想這個資產所占的數額一定不會小。而墨菲定律(事情如果有變壞的可能,無論這種可能性有多小,它總會發生)仿佛是給DBA量身定做的。在上篇文章介紹的簡單恢復模式下,從最近一次備份到當前的數據都會存在丟失的風險。而完整備份模式使得數據丟失的風險大大減少。本文主要介紹在完整備份模式下概念原理和日誌所處的角色。

完整(Full)恢復模式

完整恢復模式通過將對數據庫的任何修改記錄到日誌來給予數據最大程度的保護。在完整恢復模式下,日誌的作用不僅僅是保證了數據庫事務的ACID。並且還可以使數據恢復到在日誌範圍內的任何時間點。

在上一篇文章中說過,在簡單恢復模式下,日誌幾乎是不用進行管理的。每一次CheckPoint都有可能截斷日誌,從而來回收不活動的VLF以便重復利用空間。因此在簡單恢復模式下,日誌的空間使用幾乎可以不去考慮。與之相反,在完整恢復模式下,日誌作為恢復數據的重要組成部分,日誌的管理和對日誌空間使用的管理則需要重視。

在完整恢復模式下,CheckPoint不會截斷日誌。只有對日誌的備份才會將MinLSN向後推並截斷日誌。因此在一個業務量稍大的系統中,日誌的增長速度將會變得很快。

因此日誌備份的目的分為以下兩個:

  • 減少活動日誌的大小
  • 減少日誌損壞的風險

通過從MSDN中摘自的下圖可以看到:

技術分享圖片

在DB_1處做了完整備份,並且接下來兩次分別做了兩次日誌備份(Log_1和Log_2),在Log_2備份完不久服務器由於數據所在磁盤損壞。這時如果日誌文件完好,則可以通過備份尾部日誌(Tail of log)後,從DB_1開始恢復,依次恢復Log_1,Log_2,尾部日誌來將數據庫恢復到災難發生時的時間點。理論上可以使數據的損失為0。

從日誌恢復數據的原理是Redo,也就是將日誌中記載的事務再重做一遍。這個開銷和從完整或差異備份中恢復相比,要大很多。因此盡可能的減少利用日誌的恢復量。而使用完整或者差異備份來恢復更多的數據。

大容量日誌(Bulk-logged)恢復模式

大容量恢復模式在很多地方和完整恢復模式相同。但由於在完整恢復模式下,對數據庫的每一項操作都會記錄在日誌中。而對於某些大量數據的導入導出操作,無疑會在日誌中留下大量記錄。很多情況下,我們並不需要將這些信息記錄在日誌中。

而大容量日誌恢復模式作為完整恢復模式的備選方案。微軟推薦的最佳實踐是在進行大量數據操作時(比如索引的創建和rebuilt,select into操作等),暫時由完整恢復模式切換到大容量恢復模式來節省日誌。這個轉換並不會破壞日誌鏈。

本文不會深入探討這個模式,僅僅是對這個概念做簡單解釋。假設我要插入一批數據,則完整恢復模式和大容量日誌恢復模式在日誌中所記錄的信息如下:

技術分享圖片

由此可以看出,在日誌中,大容量恢復模式將這類操作變為一個原子。

日誌鏈(Log Chain)

連續的日誌備份被稱之為日誌鏈。表示日誌是連續的.這個概念可以用下圖表示:

技術分享圖片

假設上面兩個日誌備份可以簡單抽象成如上2個備份,則日誌備份1的末尾LSN必須小於等於日誌備份二的第一個LSN(通常情況下是第一個末尾LSN等於第二個日誌備份的第一個LSN,但由於存在“只備份日誌”選項只備份日誌,並不截斷日誌,所以有可能重疊)。則這兩個備份的日誌鏈是連續的。

下圖是一個生產環境下,在SSMS中查看日誌鏈連續的例子:

技術分享圖片

可以看出,第一次完整備份後,備份多次事務日誌,每一個事務日誌的開始LSN都等於上一個事務日誌的結束LSN。因此可以從第一次完整備份開始,恢復到最後一個日誌備份期間的任何時間點。

完整的日誌鏈以第一次完整備份或由簡單恢復模式轉為完整或大容量日誌模式開始,到當前的時間點結束。

而從日誌恢復數據要求從最近一次完整或差異備份到所恢復的時間點之間的日誌鏈是連續的。

恢復次序

從備份恢復數據需要經歷如下幾步驟:

1.復制數據階段:從完整備份和差異備份中將數據,索引頁和日誌復制到被恢復數據庫文件。

2.Redo(roll forward)階段:將記錄在日誌中的事務應用到從備份中復制過來的數據。使數據Roll Forward到指定的時間點.這個階段完成後,數據庫還處於不可使用階段:

如圖: 技術分享圖片

上面兩部就是Restore

3.Undo(Roll Back)階段:這也是傳說中的Recovery,將任何未提交的事務回滾。這個階段過後,數據庫處於可用狀態。任何後續備份將不能接著應用到當前數據庫。

這個概念比如:

在連續兩個日誌鏈的日誌備份,在第一個事務日誌備份中定義的事務,在第二個事務日誌備份中Commit.如果在第一個事務日誌還原後使用了Recovery選項.也就是經歷了Undo階段。則事務1在Undo階段會被回滾:

技術分享圖片

可見,日誌備份1中的T1被回滾,在日誌備份2中的Commit也就毫無意義。這也就是為什麽經歷過Undo階段後不允許再恢復後續備份。因此,微軟推薦的最佳實踐是使用NoRecovery選項不進行Undo階段。而在所有備份恢復後單獨進行Undo階段,這個操作可以通過還原日誌尾部時,指定Recovery選項進行。

總結

本文簡單介紹了在完整恢復模式下,日誌的作用以及對數據恢復的一些概念。理解完整恢復模式的概念對於減少數據丟失的風險是無可替代的。

轉自:http://www.cnblogs.com/CareySon/archive/2012/02/23/2364572.html

(2.7)備份與還原--在完全恢復模式下事務日誌的角色