本系列文章一直所沒有觸及的就是有關(guān)”還原(Restore)”的話題，因?yàn)橐坏砍兜竭@個話題就會涉及大量的誤區(qū)，多到我無法通過一篇文章說完的地步。
事實(shí)上，我希望用字母表的順序?yàn)槊恳粋€誤區(qū)進(jìn)行編號，希望你看了不要昏昏欲睡。下面開始揭穿這26個誤區(qū)。

誤區(qū) #24: 26個有關(guān)還原(Restore)的誤區(qū)
都是錯誤的

24 k)還原是從損壞中恢復(fù)的最佳辦法
不是,并不完全是。這要取決于你有的備份類型。如果損壞的數(shù)據(jù)比較多，那么利用還原是一個不錯的主意，但如果損失的數(shù)據(jù)比較少并允許一些數(shù)據(jù)損失的情況下，亦或是由事務(wù)日志傳送的輔助服務(wù)器回傳一些日志的情況下，那么downtime就會少很多。最佳辦法就是在可接受的數(shù)據(jù)損失范圍內(nèi)，在盡量少的downtime修復(fù)損壞。

24 l)在開始還原之后還可以備份尾端日志
不允許，一旦你開始還原之后，就不再允許備份尾端日志。所以當(dāng)災(zāi)難發(fā)生之后，第一件事永遠(yuǎn)都是查看是否需要備份尾端日志。

24 p)RESTORE ... WITH VERIFYONLY選項(xiàng)會驗(yàn)證整個備份集
不，這個選項(xiàng)僅僅檢查備份的頭是否正確。只有使用WITH CHECKSUM才可以完整備份集的校驗(yàn)和檢查。

24 q)可以在不還原證書的情況下，還原被透明數(shù)據(jù)加密的數(shù)據(jù)庫
不能，對于透明數(shù)據(jù)加密最重要的一點(diǎn)要記住，證書丟了意味著整個數(shù)據(jù)庫就沒了。

24 r)當(dāng)還原過程完成后，還原會進(jìn)行Redo和Undo
每次還原操作后其實(shí)執(zhí)行的都是Redo操作，只有在整個還原過程完成后，才會進(jìn)行Undo。

24 s)壓縮備份集只能被還原到SQL Server 2008企業(yè)版中
不，所有的版本都能還原壓縮后的備份。從SQL Server 2008 R2開始，標(biāo)準(zhǔn)版也可以進(jìn)行壓縮備份。

24 t)將低版本的數(shù)據(jù)庫還原到高版本的實(shí)例可以跳過升級過程
不允許，在數(shù)據(jù)還原和附加的過程中是不允許跳過必須的升級和恢復(fù)過程。

24 u)在32位實(shí)例下備份的數(shù)據(jù)庫無法恢復(fù)到64位實(shí)例。反之亦然
錯誤，數(shù)據(jù)庫的內(nèi)部格式和CPU構(gòu)架無關(guān)。

24 v)只要進(jìn)行數(shù)據(jù)還原，就可以保證程序正常執(zhí)行
不對，就像高可用性中的鏡像故障轉(zhuǎn)移和事務(wù)日志傳送轉(zhuǎn)移到輔助服務(wù)器一樣，還有很多額外的步驟需要做才能保證程序正常執(zhí)行。包括輔助數(shù)據(jù)庫和正確的登錄名等。

24 w)還原受損的文件需要從多個文件組進(jìn)行還原，則必須還原相關(guān)的所有文件組
不，在SQL Server 2000中的確是這樣，但在SQL Server 2005以后的版本就完全不用了。

24 x)你可以將數(shù)據(jù)庫還原到任何最新版本的實(shí)例
不對，數(shù)據(jù)庫只能還原到比其新的一個或兩個版本.(比如SQL Server 7.0下的數(shù)據(jù)庫就不能還原到SQL Server 2008)。

24 y)恢復(fù)時間和還原時間是一樣的
不，很多因素會影響還原的時間，比如說是否有長事務(wù)需要回滾，或是即時文件初始化特性是否開啟。

24 z)在還原數(shù)據(jù)庫之前需要先Drop被還原的數(shù)據(jù)庫
不是的，如果你在還原數(shù)據(jù)庫之前Drop被還原的數(shù)據(jù)庫，那么還原過程首先需要即時文件初始化，還有，你最好保留被還原數(shù)據(jù)庫的副本以便還原失敗的情況下把損失減到最小。

最新評論