SqlServer數(shù)據(jù)庫備份和恢復的原理

1、Sql Server數(shù)據(jù)庫備份和恢復的原理本文與您探討為什么Sql Server有完整備份、差異備份和事務日志備份三種備份方式，以及為什么數(shù)據(jù)庫 又有簡單模式、完整模式和大容量日志模式這三種恢復模式。本文內容適用于2005以上所有版本的Sql Server數(shù)據(jù)庫。單就操作過程而言，Sql Server中數(shù)據(jù)庫備份和恢復過程是相當簡單的，可以通過Management Studio的圖形界面進行操作，也可以使用幾句T-SQL語句完成。但要明白備份恢復的整個過程，定制符合系統(tǒng)需求數(shù)據(jù)庫備份方案，卻需要知曉數(shù)據(jù)庫的實現(xiàn)原理。備份和恢復是數(shù)據(jù)庫的核心功能。1數(shù)據(jù)庫原理本節(jié)簡要討論了 Sql Server

2、數(shù)據(jù)庫的存儲的物理和邏輯結構，這是備份恢復過的理論基礎。1.1為什么使用數(shù)據(jù)庫為什么要使用數(shù)據(jù)庫，而不是使用一個文件，然后自己寫一些方法來保存數(shù)據(jù)，那是因為使用數(shù)據(jù)庫我們 就不用自己去實現(xiàn)下面這些算法上非常復雜的功能：a高效一致的結構化數(shù)據(jù)存取方法，進行復雜的任意條件組合嵌套的數(shù)據(jù)查詢（關系數(shù)據(jù)庫管理系統(tǒng)甚至為實現(xiàn)這一功能專門設計了一種語言：SQL）b保障數(shù)據(jù)操作的原子性和完整性c確保在服務器斷電、網(wǎng)絡中斷、服務器崩潰、客戶端崩潰的情況下，故障恢復后數(shù)據(jù)仍然是完整的d在服務器被完全物理摧毀的情況下，快速在新的服務器上使用遠程設備上的備份將數(shù)據(jù)恢復到災難發(fā)生之 前的狀態(tài)e.隨時將數(shù)據(jù)恢復到任意時

3、刻或任意一個操作之前a主要是功能和性能bcde四條都可以歸結為完整性。數(shù)據(jù)庫系統(tǒng)的核心目標就是：在實現(xiàn)功能需求的基礎上，保證數(shù)據(jù)完整性和數(shù)據(jù)存取性1.2 Sql Server存儲的物理結構和邏輯結構1.2.1 如何實現(xiàn)完整性經(jīng)過很多理論研究和實踐，目前公認的最有效的實現(xiàn)完整性的方法是：將數(shù)據(jù)的存儲分為數(shù)據(jù)和事務日 志，在存取過程中使用鎖來控制并發(fā)訪問。數(shù)據(jù)是實時狀態(tài)。事務日志記錄了數(shù)據(jù)發(fā)生變化的過程，對于數(shù)據(jù)庫數(shù)據(jù)的任何一個改變，都被作為一條記錄寫在了事務日 志文件中。事務是指一組操作要么全部成功要么全部不執(zhí)行。任何數(shù)據(jù)更改操作在寫入到數(shù)據(jù)文件中之前，必須先將更前后的數(shù)據(jù)寫入事務日志文件中，這

4、樣當事務由于 用戶取消、數(shù)據(jù)邏輯錯誤或軟硬件故障中斷時能夠正確的回滾或前滾到正確的狀態(tài)。通過鎖控制多用戶對同一數(shù)據(jù)的并發(fā)訪問。這是事務系統(tǒng)最基本的原理，大多數(shù)關系數(shù)據(jù)庫系統(tǒng)和面向對象 NoSQL數(shù)據(jù)庫系統(tǒng)都 采用這種方法。Sql Server也不例外，每個Sql Server數(shù)據(jù)庫由數(shù)據(jù)文件（*.mdf）和事務日志文件（*.ldf）構 成。Sql Server包括了從行到表，從頁面到文件的各種粒度的鎖。1.2.2 如何實現(xiàn)高性能在計算機數(shù)據(jù)存取過程中，保障性能的算法最終都可以歸結為：索引和緩存。從實現(xiàn)層而到應用層而， Sql Server都在建立管理各種索引和各種緩存。對于需要隨機存取的數(shù)據(jù)，

5、分頁是最自然的索引方法，同時能夠方便的進行緩存，實現(xiàn)高效率的隨機存 取。我們所熟悉的操作系統(tǒng)內存管理系統(tǒng)、文件管理系統(tǒng)都采用了分頁的方法。在Sql Server中，對于數(shù)據(jù)文件mdf,主要是隨機存取，因此mdf以分頁的形式進行組 織管理，每個頁面 8KBo還進一步將8個相鄰的頁組成一個擴展，方便管理，類似Windows中的簇。mdf中保存著多種類型的數(shù)據(jù)，包括表數(shù)據(jù)、索引數(shù)據(jù)和大塊數(shù)據(jù)等等。每個頁面只保存一種數(shù)據(jù)。表中的每一條記錄都保存在一個表數(shù)據(jù)頁中，記錄不能跨頁，因此任何表中記錄的最大長度是略小于 8KB（ntext之類的大塊列只計算引用的大?。┑囊粋€數(shù)值，略小是因為每個頁面需要一些空間來

6、保存頁面自身的 信息（頁頭）和記錄在頁面中的存儲位置。在Sql Server中，對于事務日志文件Idf,主要是順序存取。在正常運行時，數(shù)據(jù)庫管理 系統(tǒng)定期將日志順 序寫入到Idf文件；在恢復時，順序讀取Idf文件。因此，日志文件不需要分頁，只要由一條條順序存儲的事務 日志記錄構成即可。日志記錄也有緩存，定期寫入到Idf文件。盡管數(shù)據(jù)庫系統(tǒng)是一個允許并發(fā)訪問的系統(tǒng)，但是對事務日志的寫入是串行化的，不可以并發(fā)，任何一個 原子操作對應的事務日志記錄在事務日志文件中都有其唯一的位置，也就是唯一的事務日志記錄編號，這個編號是一直增大的，不會重復，越新的記錄編號越大，存儲位置也越靠后。以上內容總結自Sql

7、 Server的產(chǎn)品文檔Sql Server Books Online,如有興趣可以在里面了解更詳細的內 容。這些就是備份和恢復的基礎原理。2數(shù)據(jù)庫備份的實現(xiàn)如前所述，數(shù)據(jù)文件mdf保存了數(shù)據(jù)的實時狀態(tài)，事務日志文件Idf記錄了數(shù)據(jù)庫中數(shù)據(jù)變化的過程。這個時候,我們要對數(shù)據(jù)庫進行備份，自然而然就有兩個選擇：因為mdf文件中保存了數(shù)據(jù)庫中數(shù)據(jù)的實時狀態(tài)，那么我們只要把mdf文件拷貝一份就實現(xiàn)了當前時刻的數(shù)據(jù)庫備份。既然Idf文件中保存了數(shù)據(jù)庫中數(shù)據(jù)變化的整個過程，那么我們就可以把這個Idf文件備份起來，然后用這些備份的事務日志記錄重頭重建整個數(shù)據(jù)庫，而且比至第一種方法，通過事務日志記錄恢復的 方

8、法可以將數(shù)據(jù)庫恢復到任一時刻。實際上，Sql Server同時使用了這兩種方法。2.1 拷貝數(shù)據(jù)文件：數(shù)據(jù)備份籠統(tǒng)的說，數(shù)據(jù)備份很簡單，就是拷貝mdf文件。但是如果數(shù)據(jù)庫特別大，比如幾十個 G,將整個mdf文件拷貝一遍會占用大量的10資 源和磁盤空間。考慮到mdf文件內容是分頁保存的，而且數(shù)據(jù)庫中的數(shù)據(jù)在一定時間內不會全部發(fā)生變化，那么 我們不必每次備份都把整個mdf文件都拷貝。只需要在每個頁的頁頭中設一個bit位記錄一下自從上次備份以 來，這一頁是否有被修改過，那么，有了上次的備份，我們只需要把那些發(fā)生了變化的頁備份一下就可以。這就是Sql Server中的完整備份和差異備份。出于簡化設計和

9、簡化備份恢復過程的考慮，雖然Sql Server在每個完整備份后面可以進行任意次的差異備份，但是所有的差異備份都是相對于最近一次完整備份的，而不是可能存在的上一次差異備 份。很自然的，任何差異備份之前必須有一次完整備份。2.2 切割不斷變大的事務日志文件：事務日志備份事務日志文件Idf記錄了數(shù)據(jù)庫中數(shù)據(jù)變化的過程。想象一下，數(shù)據(jù)庫中表的每條記錄不停的發(fā)生變化，而 事務日志要記錄變化前和變化后的數(shù)據(jù)，如果一個數(shù)據(jù)庫的mdf文件有1G,那么它的Idf文件呢，非常有可能是幾個G 對于頻繁發(fā)生數(shù)據(jù)修改的數(shù)據(jù)庫，事務日志文件Idf的增長是非?？斓?，到最后，比如若干年后，Idf文件很有可能是mdf文件的幾

10、百倍大。問題就出來了，記錄數(shù)據(jù)變化過程的文件將占居整個系統(tǒng)的絕大多數(shù)存儲空間，但是， 卻用不到，因為我們真正頻繁訪問的是存儲當前數(shù)據(jù)的mdf文件。這個時候，就要想辦法定期的將Idf中暫時用不到的很久以前的日志記錄轉移到其它存儲設備上。這里要插一點，盡管現(xiàn)在的計算和存儲資源相對很廉價了，但是，在數(shù)據(jù)庫服務器上，計算和存儲都是相當 昂貴的資源，原因有以下幾點：現(xiàn)有關系數(shù)據(jù)系統(tǒng)多數(shù)不是分布式的，也就是單臺服務器必須足夠強大，一臺4路的服務器成本遠高于兩 臺2路的服務器，更多路的就屬于中大機了，成本更高。用于存放數(shù)據(jù)庫文件的存儲往往采用的是SLC SSD之類昂貴的高性能服務器硬盤，而備份存儲就可以使用

11、廉價的近線硬盤甚至磁帶機。數(shù)據(jù)庫系統(tǒng)的軟件授權都是按CPU甚至按核來的，因此數(shù)據(jù)庫服務器上每個CPU每個10,每個存儲的成本不只是其硬件自身，還附帶了相對硬件更加昂貴的軟件授權。因此，將數(shù)據(jù)庫服務器上大量存儲用在存放基本不用的Idf文件在成本上是不能被接受的。到這里，你會明白，對于Idf文件，備份已經(jīng)不只是為了防止服務器上Idf文件意外損壞才備份了，也是為了減 小Idf的大小。這樣，Sql Server中的事務日志備份就應運而生，而且一箭雙雕。在Sql server中，事務日志備份將Idf文件中所有已經(jīng)提交的事務的日志記錄備份出來，將其占用的Idf文 件空間置為可用。Idf本身分成很多邏輯段，

12、事務日志記錄在邏輯段間循環(huán)存放，并可以根據(jù)需要擴大或收縮Idf文件。關于Idf 的格式的詳細描述都可以在Books Online中找到。2.3 恢復模式或許你會說，過一定時間的事務日志我不要了，覆蓋就好，確實有這種需求的存在。但是同時，對于更多的 生產(chǎn)用戶，系統(tǒng)完整的歷史日志是必須的，比如金融、國防以及大多數(shù)中大企業(yè)。作為一個通用的產(chǎn)品，SqIServer考慮到了這兩個方向的需求。Sql Server提供了一種設置，稱為恢復模 式來滿足這些不同的應用需求，包括三種：簡單模式：就是不需要歷史事務日志記錄的模式，所有成功提交的事務的日志記錄都被標記為可覆蓋，該 模式下的數(shù)據(jù)庫不能進行事務日志備份，

13、只能進行完整備份和差異備份。那么，這個時候可以不要Idf 了嗎？不 可以，盡管不需要歷史的事務日志記錄，但是事務操作的完整性還是要保證的，這個時候Idf的作用主要就是實 現(xiàn)事務。很明顯的，除非數(shù)據(jù)庫執(zhí)行過的某一個事務中包含了數(shù)量巨大的操作，否則，在簡單模 式下，Idf文件會一直保持很小，因為它只要能存放得下一個事務中的所有操作的事務日志記錄就可以了。完整模式：（請不要和完整備份中的完整混淆，兩者描述的是完全不同的東西）這一模式就是前面一直在描 述的要記錄所有己提交的歷史事務日志記錄的模式，這也是大多數(shù)系統(tǒng)應用的模式。在這種模式下，Idf會隨著 數(shù)據(jù)庫的運行不斷增大。在該模式下，可以進行完整備份

14、、差異備份和事務日志備份三種備份。在故障發(fā)生時， 可能還需要進行日志尾部備份，就是將最近一次事務日志備份之后到發(fā)生故障時刻的日志備份出來，以進行恢復。大容量日志模式：這是完整模式下的一種可切換的模式。就是在完整模式下，如果要進行大量數(shù)據(jù)的批量 操作，比如插 入，可以切換到大容量日志模式，這時Idf只記錄整個批 量操作的結果，而不記錄每個操作，可以 減少不必要的Idf文件占用。當然恢復的時候，只能恢復整個批量操作，不能恢復到其中任意一個操作。應該只 在需要批量操作的時候短暫的使用這一模式。2.4 混合使用數(shù)據(jù)備份和事務日志備份概括來說：數(shù)據(jù)備份有完整備份和差異備份兩種，事務日志備份就本身一種。對

15、于恢復模式為簡單模式的數(shù)據(jù)庫，只能進行數(shù)據(jù)備份，不能進行事務日志備份，數(shù)據(jù)庫發(fā)生故障時只能 恢復到備份時刻，備份時刻到發(fā)生故障間的數(shù)據(jù)將丟失。這里要講的是完整模式，這也是數(shù)據(jù)庫主要使用的模式。理論上，有了事務日志，不需要數(shù)據(jù)備份也可以，因為我們可以從頭恢復嘛。但是有一個問題，那就是性 能問題，從事務日志恢復數(shù)據(jù)相當于把數(shù)據(jù)庫創(chuàng)建以來所有的操作重新執(zhí)行一遍，這將會消耗大量時間，對于運 行很久的數(shù)據(jù)庫，這個時間可能會以天甚至月計，這明顯是不能接受的。銀行數(shù)據(jù)庫崩潰了，花幾天去恢 復，若 不是天朝的估計得倒閉。這個時候，數(shù)據(jù)備份就有用了，對于完整備份，數(shù)據(jù)恢復就是簡單的文件拷貝，分分鐘鐘完成；對于差

16、異 備份，先進行最近一次完整備份的恢復，再執(zhí)行差異恢復，只是頁的拷貝覆蓋，也是很快的。這樣我們可以定期進行完整備份，比如每天凌晨0點執(zhí)行一次完整備份，因為完整備份畢竟拷貝了整個數(shù) 據(jù)庫，因此最好在業(yè)務不繁忙時進行，然后每6個小時進行一次差異備份，每隔20分鐘進行一次日志備份，日 志備份是很快的，因為頻繁備份使得需要備份的日志一般都不大，而且日志文件本身是順序訪問文件，己提交的 事務日志記錄都是只讀的，不會有寫操作，不涉及同步的問題，適合于頻繁備份操作。這樣，當故障發(fā)生時，如果可能，先將日志的結尾進行備份。我們就可以先恢復最近一次完整備份，再恢復最近一次差異備份，然后再將跨越差異備份以及差異備份之后的所有事務日志備份連同結尾備份依次進行恢復，將數(shù)據(jù)庫在可接受的時間內完美恢復到發(fā)生故障的時刻。 通過以上分析我們也可以得知： 數(shù)據(jù)備份中，差異備份依賴于前一次完整備份，而各個完整備份之間沒有任何依賴關系。對于事務日志備份，除了在事務日志備份之前必須有一次完整備份之外（這主要是為從簡單模式轉到完整模式的數(shù)據(jù)庫設計的），事務日志備份與數(shù)據(jù)備份完全獨立，兩者各進行各的。 每個數(shù)據(jù)備份中記錄了最后提交的事務日志記錄的編號，假設為N,在數(shù)據(jù)備份恢復完成后，接下來的事務日志備份恢復時，第