淺談SQL Server中的交易記錄(四)—-在完整復原模式下日誌的角色

    本篇文章是系列文章中的第四篇，也是最後一篇，本篇文章需要前三篇的文章知識作為基礎，前三篇的文章地址如下:

    淺談SQL Server中的交易記錄(一)----交易記錄的物理和邏輯構架

    淺談SQL Server中的交易記錄(二)----交易記錄在修改資料時的角色

    淺談SQL Server中的交易記錄(三)----在簡單復原模式下日誌的角色

 

簡介

    生產環境下的資料是如果可以寫在資產負債表上的話，我想這個資產所佔的數額一定不會小。而墨菲定律（事情如果有變壞的可能，無論這種可能性有多小，它總會發生）彷彿是給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選項進行。

 

總結

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