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