影響數據庫還原速度的因素和影響數據庫備份速度的因素相同。除此之外，假如你使用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'
使用這個方法，你僅僅創建了回滾文件一次，避免了還原多個事務日志時創建多次回滾文件的過程，加速了恢復過程。
