SQL Server如何提升數據庫備份的速度

對於一個數據庫完整備份來講，備份的速度很大程度上取決於下面兩個因素：讀磁盤數據、日誌文件的吞吐量，寫磁盤數據文件的吞吐量。

下圖是備份過程當中磁盤的變化狀況：

讀吞吐量

讀吞吐量的大小取決於磁盤讀取數據的速度，而磁盤讀取的速度又取決於數據文件在磁盤中的位置。所以，位於不一樣盤符上不一樣數據庫文件的讀取速度都不相同。

測量讀吞吐量的一個方法就是進行一次數據庫完整備份，而後使用Windows性能監控器(perfmon)來監控數據庫文件所在磁盤的Read bytes/sec 性能計數器。保存備份文件的磁盤應該在物理上區別於數據庫文件所在的磁盤，不然測量精度會不許確。固然備份同時也應該會有另一些來自系統或是其餘應用程序對磁盤的讀取操做。

注意：若是你使用完整備份來監測磁盤讀寫吞吐量的話，那麼這個測試用的備份文件應該和其餘常規備份放在一塊兒，以便恢復時使用。也就是說，若是你在測試備份文件以後又進行了常規差別備份，那麼這些差別備份就會以這個測試備份爲還原的起始點。

假設數據庫全部文件的大小都是相等的，那麼你獲取的最小測量值就是你指定數據庫在系統中最大的備份吞吐量了。

另外一個測量讀吞吐量的方法是在NUL設備上執行備份，以下：

BACKUP DATABASE AdventureWorks TO DISK = 'NUL' WITH COPY_ONLY

注意咱們使用了COPY_ONLY選項，這個選項僅僅在SQL Server 2005及以上版本中才提供。你能夠在SQL Server2000上執行相同的備份，只是要忽略這個選項，可是必定要當心。由於備份到NUL設備也會被認爲是一個有效備份，這就意味着當你執行備份到NUL設備後，你後續的全部差別備份都將不可用，除非你在執行備份到NUL設備後，再執行一次常規的數據庫完整備份。假如你執行事務日誌備份到NUL設備，那麼你將破壞日誌恢復鏈，致使後續事務日誌備份不可用。

若是你必須在SQL Server 2000上執行備份到NUL設備的話，必定要作好備災恢復的準備。

假設我如今已經測量出個人AdventureWorks讀吞吐量爲46MB/sec。這就是說，46MB/sec是最大的備份吞吐量了，也是個人磁盤能提供給SQL Server備份讀線程最快的速度了。那咱們如何提升這個速度呢？使用更快的磁盤確定是一種方法。另外的方法就是把數據庫文件分散到多個物理磁盤上，以便於在讀數據時能夠同步建立多個讀線程。減少數據庫文件的碎片級別也能夠提升吞吐量，特別是當數據庫文件有大量碎片存在時。

寫吞吐量

如今開始說說寫吞吐量。執行一個文件備份，在個人系統中，我獲得了以下的結果：

BACKUP DATABASE successfully processed 7529 pages in 3.300 seconds (18.688 MB/sec).

上面的結果代表寫吞吐量在這裏成爲了瓶頸。個人磁盤能夠提供46MB/sec的數據，可是寫速度僅爲18.688MB/sec。實際上，我把備份文件放在了同數據文件相同的磁盤上，當我把備份文件放在不一樣的物理磁盤上時，我獲得以下的結果：

BACKUP DATABASE successfully processed 7529 pages in 1.421 seconds (43.399 MB/sec).

上面的結果已經好不少了。如今讀寫速度都取決於磁盤了，總體的吞吐量已經明顯提升了。因此把備份文件放到不一樣的物理磁盤上就是一種提升寫吞吐量的方法。另外一個方法就是把備份分散成不一樣的文件。若是磁盤能夠控制它的話，那麼文件能夠位於相同的物理磁盤上。若是不能，你最好把文件分散到不一樣的物理磁盤上。使用更快的磁盤存儲備份文件是另外一個好的選擇。

然而，讓咱們回到第一步，再看看那個總體圖。想想備份吞吐量的第一步是讀吞吐量。也就是說即便你的寫吞吐量達到150MB/sec，可是若是讀吞吐量只有46MB/sec的話，也無濟於事，你能得到的最大備份吞吐量仍是46MB/sec。

總結

首先咱們總結一下咱們都作了什麼：

咱們測量了讀吞吐量爲46MB/sec，咱們討論了以下方法來提升這個數值：

• 使用更快的磁盤。
• 把多個數據庫文件存儲在不一樣的物理磁盤上
• 減小數據庫文件碎片級別

咱們在數據庫文件所在磁盤執行了備份執行，備份吞吐務爲18MB/sec。很糟的速度，咱們知道讀吞吐量爲46MB/sec，因此咱們把目標放到了寫吞吐量上。而後，咱們把備份文件放到了與數據庫文件不一樣的物理磁盤上。備份吞吐量爲43MB/sec。速度不錯。我也還能夠提升這一數值嗎？看起來好像是不行了。可是若是咱們的寫吞吐量僅僅爲25MB/sec的話，咱們還能夠從如下幾方面來考慮：

• 使用更快的磁盤進行備份
• 把備份文件分割成多個文件（在相同或不一樣的物理磁盤上，這取決於磁盤的吞吐量）
• 使用備份壓縮工具。假如壓縮速度很是好的話，那麼就會減小寫到磁盤上的數據量，從而加大寫吞吐量。通常狀況執行這種壓縮程序都會消耗大量的CPU資源

補充說明

爲了得到最好的備份吞吐量，下面這幾點在最開始建立數據庫時就應該考慮到。實際上，下面這幾點也一樣適用於提升你數據庫的應用性能。

• 磁盤速度：使用最快的磁盤或是在預算容許的前提下進行磁盤配置來提升備份吞吐量。
• 數據庫文件：把數據庫文件分散到多個物理磁盤上，以便於SQL Server使用多個讀線程去每一個磁盤上讀取數據。對比單數據文件的數據庫存儲來說，多數據文件能夠在很短期內完成數據的讀取。
• 使用不一樣的物理磁盤：SQL Server的讀線程數量是基於你數據庫文件所在的盤符數量的。然而，假如你的盤符是相同物理磁盤上的分區，並且你的磁盤不能知足讀線程的讀取要求時，你的備份吞吐量將會不好。
• 文件碎片：建立數據時指定的數據庫的初始大小就至關於指定的數據庫減小文件碎片的指望最大值。假如數據庫文件被設置爲自動增加，且設置了一個最大增加值的話，這樣也要有助於減少碎片。
• 有計劃的存儲你的事務日誌到獨立的磁盤中：把你的事務日誌文件存儲在獨立於數據庫文件的磁盤中，甚至獨立於操做系統或是其餘常用I/O的應用程序，有助於在執行事務日誌備份時提升讀寫吞吐量。事務日誌的磁盤的I/O操做是天然相連的，而不是數據文件I/O那種隨機的操做。把事務日誌文件同數據文件放在同一個盤上的話，當數據庫忙碌時，會使事務日誌備份變慢。
• 有計劃的存儲你的備份到獨立的磁盤中：把你的備份文件存儲在獨立於數據庫文件的磁盤中，甚至獨立於操做系統或是其餘常用I/O的應用程序，有助於提升寫吞吐量。

獲取備份速度數據

你能夠從msdb..backupset表中獲取備份速度數據。backup_start_date,backup_finish_date和backup_size列提供了計算備份速度所需的全部數據細節信息。注意備份大小不是定義數據庫大小所必需的，由於SQL Server 2005不備份包括已被刪除數據的數據頁。具體細節請參見article。

下面的腳本能夠顯示出你全部數據庫的備份時間：

SELECT database_name, backup_start_date, CAST(CAST((backup_size / (DATEDIFF(ss, backup_start_date, backup_finish_date))) / (1024 * 1024) AS NUMERIC(8, 3)) AS VARCHAR(16)) + ' MB/sec' speed FROM msdb..backupset ORDER BY database_name, backup_start_date