影響數(shù)據(jù)庫還原速度的因素和影響數(shù)據(jù)庫備份速度的因素相同。除此之外，假如你使用SQL Server 2005的話，你還可以啟動另外一個優(yōu)化任務來還原當前不存在的數(shù)據(jù)庫，運行環(huán)境為Windows XP，Windows 2003 Server 或更新版本。
Perform Volume Maintenance Tasks
當你還原一個新的完整數(shù)據(jù)庫是，SQL Server讀備份文件頭，然后創(chuàng)建原始數(shù)據(jù)庫中數(shù)據(jù)和日志文件需要的磁盤空間。假如SQL Server服務啟動帳戶沒有“Perform Volume Maintenance Tasks”權限的話，數(shù)據(jù)和日志文件就需要被初始化為0，也就是說，SQL Server先創(chuàng)建這些文件，然后用0來填充它們。對于一個大數(shù)據(jù)庫來說，這將花費很多時間。我記得使用SQL Server 2000從磁帶上還原一個320GB的數(shù)據(jù)庫時，總是奇怪為什么總是有30分鐘的時間，還原進程一點稱進展都沒有。
然后，假如SQL Server服務啟動帳戶有“Perform Volume Maintenance Tasks”權限的話，它就會根據(jù)大小來創(chuàng)建數(shù)據(jù)文件，跳過“填充0”這個階段。
下圖使用secpol.msc來顯示權限
![32139_1265074601RN4R[1]](http://hi.csdn.net/attachment/201002/2/32139_1265074601RN4R.png)
你可以設想一下它會節(jié)省你多少還原大型數(shù)據(jù)庫的時間。注意，事務日志文件仍然需要“填充0”，僅僅是數(shù)據(jù)文件可以跳過這一步。
注意：當然使用新權限時，要啟動SQL Server服務來使之生效
下面是一個還原20GB數(shù)據(jù)和5GB事務日志所消耗時間的對照表
| |
還原消耗時間 |
| 未使用”Perform Volume Maintenance Tasks” |
5:05 |
| 使用“Perform Volume Maintenance Tasks” |
1:01 |
消耗1:01時間是因為SQL Server仍然要把事務日志文件進行“填充0”操作，未使用”Perform Volume Maintenance Tasks”的情況下，SQL Server需要把數(shù)據(jù)文件和事務日志都進行“填充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
整個腳本如果在幾秒內(nèi)完成就證明使用了PVMT。
這里還有一點需要說明的地方。當SQL Server跳過“填充0”階段空間時，如果數(shù)據(jù)文件所占用的空間里面包括以前的數(shù)據(jù)，那么使用DBCC PAGE命令或是其他16進制編輯器就可以看到未被數(shù)據(jù)頁占據(jù)的空間內(nèi)容。這就是說，如果一個包括敏感重要內(nèi)容的數(shù)據(jù)雖然已經(jīng)被刪除了，但是如果新數(shù)據(jù)庫占用了這片空間，那么敏感數(shù)據(jù)就有可能被部分泄露出來。
注意：當PVMT處于活動狀態(tài)時，那么新建數(shù)據(jù)庫，新建數(shù)據(jù)文件，數(shù)據(jù)文件增長等情況都會使用它。詳情請看Database File Initialization [SQL2005]
綜上所述，那么我從備份文件還原一個數(shù)據(jù)庫之前是否要刪除這個數(shù)據(jù)庫呢？
下面的表格顯示了還原同一個數(shù)據(jù)不同操作的效果：
| |
還原時間 |
| 還原1GB數(shù)據(jù)庫 |
0:40 |
| 還原2GB數(shù)據(jù)庫 |
1:08 |
| 還原1GB數(shù)據(jù)庫，當前有個同名的2GB數(shù)據(jù)庫存在 |
0:29 |
| 還原2GB數(shù)據(jù)庫，當前有個同名的1GB數(shù)據(jù)庫存在 |
0:56 |
結(jié)果顯示，假如你執(zhí)行一個完整數(shù)據(jù)庫恢復且覆蓋已經(jīng)存在的同名數(shù)據(jù)庫，那么恢復速度會快于直接恢復(表中行1與行3，或行2與行4的對比)。這看起來好像是因為沒有對已經(jīng)存在的數(shù)據(jù)文件執(zhí)行“填充0”操作而節(jié)省了時間。不過這也僅僅局限于你恢復的數(shù)據(jù)庫有同名的文件。如果你使用MOVE選項來重定位數(shù)據(jù)庫文件，那么無論你事先是否已經(jīng)刪除數(shù)據(jù)庫，這都不再有什么區(qū)別了。
還原狀態(tài)同樣影響還原速度
另外一個影響還原速度的因素就是你所選擇的還原后的數(shù)據(jù)庫的狀態(tài)，前提是recovery沒有被選中。通常出于為以后升級做準備的需求，當你選擇不完全恢復數(shù)據(jù)庫時，有兩個選項可以使用NORECOVERY或是STANDBY。NORECOVERY使數(shù)據(jù)庫處于“恢復中”模式，允許你進行后續(xù)的升級，而且此時數(shù)據(jù)庫是不可讀狀態(tài)。STANDBY也使數(shù)據(jù)庫處于“恢復中”狀態(tài)，允許你進行后續(xù)升級，但是此時數(shù)據(jù)庫可讀。
當你使用STANDBY選項時，你要為回滾文件提供一個名字。這個文件包括從未提示的事務中回滾操作結(jié)果。你的未提交事務越多，這個文件越大，那么隨后還原時間越長。
下面的例子中有4個事務日志，每個大約131MB左右。除了第三個事務日志外，所有的備份都僅包括提交的事務，第三個事務日志包括32MB未提交事務，結(jié)果如下圖：
使用NORECOVERY選項還原事務日志：
![32139_1265074623e2j2[1]](http://hi.csdn.net/attachment/201002/2/32139_1265074623e2j2.png)
![32139_12650746381747[1]](http://hi.csdn.net/attachment/201002/2/32139_12650746381747.png)
總體來說，與NORECOVERY相比使用STANDBY還原事務日志會慢一些。因為當有未提交的事務時，SQL Server會花費額外的時間來創(chuàng)建回滾文件(undo file)。
還有說明的是，如果你要還原多個事務日志而且你想讓數(shù)據(jù)庫處于只讀模式，那么你應該先使用NORECOVERY選項來還原事務日志，然后當所有日志都恢復完成后，你可以把數(shù)據(jù)庫切換到STANDBY的只讀模式，如下：
RESTORE DATABASE mydb WITH STANDBY = 'g:/data/mydb/mydb_und.dat'
使用這個方法，你僅僅創(chuàng)建了回滾文件一次，避免了還原多個事務日志時創(chuàng)建多次回滾文件的過程，加速了恢復過程。
[此貼子已經(jīng)被作者于2014/7/17 17:38:52編輯過]
加好友 
發(fā)短信
Post By：2014/7/17 17:28:09
