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