SQL Server如何提高資料庫還原的速度

影響資料庫還原速度的因素和影響Database Backup速度的因素相同。除此之外，假如你使用SQL Server 2005的話，你還可以啟動另外一個最佳化任務來還原當前不存在的資料庫，運行環境為Windows XP，Windows 2003 Server 或更新版本。

Perform Volume Maintenance Tasks

當你還原一個新的完整資料庫是，SQL Server讀備份檔案頭，然後建立未經處理資料庫中資料和記錄檔需要的磁碟空間。假如SQL Server服務啟動帳戶沒有“Perform Volume Maintenance Tasks”許可權的話，資料和記錄檔就需要被初始化為0，也就是說，SQL Server先建立這些檔案，然後用0來填充它們。對於一個大資料庫來說，這將花費很多時間。我記得使用SQL Server 2000從磁帶上還原一個320GB的資料庫時，總是奇怪為什麼總是有30分鐘的時間，還原進程一點稱進展都沒有。

然後，假如SQL Server服務啟動帳戶有“Perform Volume Maintenance Tasks”許可權的話，它就會根據大小來建立資料檔案，跳過“填充0”這個階段。

使用secpol.msc來顯示許可權

你可以設想一下它會節省你多少還原大型資料庫的時間。注意，交易記錄檔仍然需要“填充0”，僅僅是資料檔案可以跳過這一步。

注意：當然使用新許可權時，要啟動SQL Server服務來使之生效

下面是一個還原20GB資料和5GB交易記錄所消耗時間的對照表

	還原消耗時間
未使用”Perform Volume Maintenance Tasks”	5:05
使用“Perform Volume Maintenance Tasks”	1:01

消耗1:01時間是因為SQL Server仍然要把交易記錄檔進行“填充0”操作，未使用”Perform Volume Maintenance Tasks”的情況下，SQL Server需要把資料檔案和交易記錄都進行“填充0”的操作，所以還原時間顯示變長了。

你可以用下面這個指令碼來快速確定當前是否使用了PVMT(Perform Volume Maintenance Tasks)。

CREATE DATABASE test_InstantInit ON
PRIMARY (name = 'test_InstantInit', filename = 'k:/temp/test_InstantInit.mdf', size = 1GB)
LOG ON (name = 'test_InstantInit_log', filename = 'k:/temp/test_InstantInit.ldf', size = 1MB)
DROP DATABASE test_InstantInit

整個指令碼如果在幾秒內完成就證明使用了PVMT。

這裡還有一點需要說明的地方。當SQL Server跳過“填充0”階段空間時，如果資料檔案所佔用的空間裡麵包括以前的資料，那麼使用DBCC PAGE命令或是其他16進位編輯器就可以看到未被資料頁佔據的空間內容。這就是說，如果一個包括敏感重要內容的資料雖然已經被刪除了，但是如果新資料庫佔用了這片空間，那麼敏感性資料就有可能被部分泄露出來。

注意：當PVMT處於活動狀態時，那麼建立資料庫，建立資料檔案，資料檔案增長等情況都會使用它。詳情請看Database File Initialization [SQL2005]

綜上所述，那麼我從備份檔案還原一個資料庫之前是否要刪除這個資料庫呢？

下面的表格顯示了還原同一個資料不同操作的效果：

	還原時間
還原1GB資料庫	0:40
還原2GB資料庫	1:08
還原1GB資料庫，當前有個同名的2GB資料庫存在	0:29
還原2GB資料庫，當前有個同名的1GB資料庫存在	0:56

結果顯示，假如你執行一個完整資料庫恢複且覆蓋已經存在的同名資料庫，那麼恢複速度會快於直接恢複(表中行1與行3，或行2與行4的對比)。這看起來好像是因為沒有對已經存在的資料檔案執行“填充0”操作而節省了時間。不過這也僅僅局限於你恢複的資料庫有同名的檔案。如果你使用MOVE選項來重定位元據庫檔案，那麼無論你事先是否已經刪除資料庫，這都不再有什麼區別了。

還原狀態同樣影響還原速度

另外一個影響還原速度的因素就是你所選擇的還原後的資料庫的狀態，前提是recovery沒有被選中。通常出於為以後升級做準備的需求，當你選擇不完全恢複資料庫時，有兩個選項可以使用NORECOVERY或是STANDBY。NORECOVERY使資料庫處於“恢複中”模式，允許你進行後續的升級，而且此時資料庫是不可讀狀態。STANDBY也使資料庫處於“恢複中”狀態，允許你進行後續升級，但是此時資料庫可讀。

當你使用STANDBY選項時，你要為復原檔案提供一個名字。這個檔案包括從未提示的事務中復原操作結果。你的未提交事務越多，這個檔案越大，那麼隨後還原時間越長。

下面的例子中有4個交易記錄，每個大約131MB左右。除了第三個交易記錄外，所有的備份都僅包括提交的事務，第三個交易記錄包括32MB未提交事務，結果如：

使用NORECOVERY選項還原交易記錄：

使用STANDBY選項還原交易記錄：

總體來說，與NORECOVERY相比使用STANDBY還原交易記錄會慢一些。因為當有未提交的事務時，SQL Server會花費額外的時間來建立復原檔案(undo file)。

還有說明的是，如果你要還原多個交易記錄而且你想讓資料庫處於唯讀模式，那麼你應該先使用NORECOVERY選項來還原交易記錄，然後當所有日誌都恢複完成後，你可以把資料庫切換到STANDBY的唯讀模式，如下：

RESTORE DATABASE mydb WITH STANDBY = 'g:/data/mydb/mydb_und.dat'

使用這個方法，你僅僅建立了復原檔案一次，避免了還原多個交易記錄時建立多次復原檔案的過程，加速了恢複過程。

 

本文翻譯自sqlbackuprestore，更多精彩內容請瀏覽http://www.sqlbackuprestore.com