SQL Server誤區(qū)30日談 第24天 26個(gè)有關(guān)還原(Restore)的誤區(qū)
2020-07-25 13:10:44
供稿：網(wǎng)友
本系列文章一直所沒(méi)有觸及的就是有關(guān)”還原(Restore)”的話題，因?yàn)橐坏砍兜竭@個(gè)話題就會(huì)涉及大量的誤區(qū)，多到我無(wú)法通過(guò)一篇文章說(shuō)完的地步。
事實(shí)上，我希望用字母表的順序?yàn)槊恳粋€(gè)誤區(qū)進(jìn)行編號(hào)，希望你看了不要昏昏欲睡。下面開(kāi)始揭穿這26個(gè)誤區(qū)。
誤區(qū) #24: 26個(gè)有關(guān)還原(Restore)的誤區(qū)
都是錯(cuò)誤的
24 a)可以通過(guò)WITH STOPAT參數(shù)在完整備份和差異備份的基礎(chǔ)上還原到特定時(shí)間點(diǎn)
當(dāng)然不能。雖然這個(gè)語(yǔ)法看上去貌似能的樣子，但這個(gè)語(yǔ)法的最佳實(shí)踐是你在進(jìn)行日志還原到特定時(shí)間點(diǎn)時(shí)帶上，這樣你的還原就不會(huì)超過(guò)這個(gè)時(shí)間點(diǎn)（譯者注：比如說(shuō)還原的第一個(gè)日志備份中不包含這個(gè)時(shí)間點(diǎn)，但你帶上這個(gè)參數(shù)則這個(gè)日志備份會(huì)被全部還原，直到你還原到包含時(shí)間點(diǎn)的日志備份而不用擔(dān)心還原過(guò)頭）,對(duì)此我之前的一篇文章會(huì)更有幫助:Debunking a couple of myths around full database backups。
24 b)使用了WITH CONTINUE_AFTER_ERROR選項(xiàng)之后還可以按照既定的還原順序進(jìn)行還原
錯(cuò)誤。如果你的備份集有損壞而不得不使用這個(gè)選項(xiàng)，那么你的還原順序?qū)?huì)不復(fù)存在。當(dāng)進(jìn)行日志還原時(shí)日志損壞，那么使用這個(gè)選項(xiàng)之前就需要三思而后行，因?yàn)檫@很有可能造成數(shù)據(jù)不一致的問(wèn)題。在最壞的情況下會(huì)造成數(shù)據(jù)庫(kù)中結(jié)構(gòu)被破壞，我不推薦使用這個(gè)選項(xiàng)。
24 c)可以將數(shù)據(jù)庫(kù)的一部分還原到特定時(shí)間點(diǎn)
不能，數(shù)據(jù)庫(kù)的每個(gè)部分都需要和主文件組時(shí)間點(diǎn)一致，否則就無(wú)法上線。當(dāng)然只讀文件組除外。
24 d)可以將不同數(shù)據(jù)庫(kù)的不同文件組還原到一個(gè)新的數(shù)據(jù)庫(kù)中
不能，每個(gè)數(shù)據(jù)庫(kù)的文件頭頁(yè)（譯者注：也就是頁(yè)號(hào)為0的頁(yè)）都有一個(gè)GUID，除非這個(gè)GUID和另外數(shù)據(jù)庫(kù)的GUID一致才能還原（這當(dāng)然不可能）。
24 e)還原可以去除索引碎片（或是更新統(tǒng)計(jì)信息等等）
不能，你備份的是什么還原的就是什么，我之前的一篇文章對(duì)此有更詳細(xì)的解釋:blog post over on our SQL Server Magazine Q&A blog。
24 f)在還原的過(guò)程中可以進(jìn)行數(shù)據(jù)庫(kù)收縮
不能，雖然大家都需要這個(gè)功能，在開(kāi)發(fā)環(huán)境下恢復(fù)一個(gè)大部分是空的備份集時(shí)這就十分有用。但就是不能。
24 g)可以將數(shù)據(jù)庫(kù)還原到任何更低版本的實(shí)例
不能，這是一個(gè)普遍存在的誤區(qū)。低版本的實(shí)例對(duì)于高版本的數(shù)據(jù)庫(kù)的部分內(nèi)容有可能無(wú)法理解（比如sql server 2005的數(shù)據(jù)庫(kù)就無(wú)法理解SQL Server 2008數(shù)據(jù)庫(kù)的一些內(nèi)容）。
24 h)可以將數(shù)據(jù)庫(kù)還原到任意版本的SQL Server中
錯(cuò)誤，比如說(shuō)SQL Server 2005,一個(gè)含有表分區(qū)的數(shù)據(jù)庫(kù)只能還原到企業(yè)版中。在SQL Server 2008只能還原到企業(yè)版的數(shù)據(jù)庫(kù)包含了如下特性:分區(qū)，透明數(shù)據(jù)加密，CDC,數(shù)據(jù)壓縮。有關(guān)這里我已經(jīng)寫(xiě)過(guò)一篇文章，請(qǐng)看:SQL Server 2008: Does my database contain Enterprise-only features?。
24 i)WITH STANDBY參數(shù)會(huì)破壞還原鏈
不會(huì)，這個(gè)參數(shù)的作用是使得在還原的過(guò)程中，保證數(shù)據(jù)庫(kù)事務(wù)級(jí)別的一致性。從還原順序的角度來(lái)說(shuō)，With Standby參數(shù)WITH NORECOVERY并無(wú)區(qū)別。你可以在還原的過(guò)程中停止N次。這也是事務(wù)日志傳送的機(jī)制。經(jīng)常有人會(huì)問(wèn)在事務(wù)傳送的輔助服務(wù)器進(jìn)行日志恢復(fù)的過(guò)程是否能訪問(wèn)，至此你應(yīng)該知道是可以只讀訪問(wèn)的。同時(shí)，這個(gè)選項(xiàng)也可能造成一些詭異的問(wèn)題，請(qǐng)看:Why could restoring a log-shipping log backup be slow?。
24 j)如果備份數(shù)據(jù)庫(kù)的服務(wù)器沒(méi)有開(kāi)啟即時(shí)文件初始化選項(xiàng)，那么恢復(fù)的服務(wù)器就不能利用這個(gè)特性
是否能進(jìn)行即時(shí)文件初始化完全取決于被還原的服務(wù)器受否開(kāi)啟這個(gè)特性。備份集中不會(huì)含有任何有關(guān)這點(diǎn)的信息。更詳細(xì)的內(nèi)容請(qǐng)看:SQL Server誤區(qū)30日談-Day3-即時(shí)文件初始化特性可以在SQL Server中開(kāi)啟和關(guān)閉。
24 k)還原是從損壞中恢復(fù)的最佳辦法
不是,并不完全是。這要取決于你有的備份類(lèi)型。如果損壞的數(shù)據(jù)比較多，那么利用還原是一個(gè)不錯(cuò)的主意，但如果損失的數(shù)據(jù)比較少并允許一些數(shù)據(jù)損失的情況下，亦或是由事務(wù)日志傳送的輔助服務(wù)器回傳一些日志的情況下，那么downtime就會(huì)少很多。最佳辦法就是在可接受的數(shù)據(jù)損失范圍內(nèi)，在盡量少的downtime修復(fù)損壞。
24 l)在開(kāi)始還原之后還可以備份尾端日志
不允許，一旦你開(kāi)始還原之后，就不再允許備份尾端日志。所以當(dāng)災(zāi)難發(fā)生之后，第一件事永遠(yuǎn)都是查看是否需要備份尾端日志。
24 m)你可以還原到在備份的日志范圍之內(nèi)的任何時(shí)間點(diǎn)
這是不對(duì)的。如果日志中包含了那些那些僅僅少量日志的操作(比如批量數(shù)據(jù)導(dǎo)入操作)，這類(lèi)操作具有原子性，要么全部還原，要么不還原。這是由于這類(lèi)操作對(duì)于區(qū)的進(jìn)行了修改，但備份集中并沒(méi)記錄何時(shí)修改了這些區(qū)。你可以通過(guò)如下腳本查看日志備份包含的信息量：New script: how much data will the next log backup include?。
24 n)只要備份成功，就可以利用這個(gè)備份集進(jìn)行還原
No,no,no。備份集只是存儲(chǔ)在IO子系統(tǒng)的文件，就和數(shù)據(jù)庫(kù)的文件一樣。它也有損壞的可能。你需要定期檢查備份是否被損壞，否則當(dāng)災(zāi)難發(fā)生后的驚喜怕你是承受不了。請(qǐng)看:Importance of validating backups。另外一點(diǎn)需要注意的是避免額外的完整備份破壞恢復(fù)順序，這個(gè)例子或許會(huì)給你一點(diǎn)警示：BACKUP WITH COPY_ONLY - how to avoid breaking the backup chain。
24 o)所有的SQL Server頁(yè)類(lèi)型都可以通過(guò)單頁(yè)恢復(fù)進(jìn)行還原
不，一些分配位圖的頁(yè)（譯者注：比如GAM,SGMA,FPS頁(yè)等）不能通過(guò)進(jìn)行單頁(yè)還原(這類(lèi)頁(yè)可以通過(guò)SQL Server 2008 的鏡像進(jìn)行自動(dòng)頁(yè)修復(fù))。詳情你可以看我這篇文章:Search Engine Q&A #22: Can all page types be single-page restored?。
24 p)RESTORE ... WITH VERIFYONLY選項(xiàng)會(huì)驗(yàn)證整個(gè)備份集
不，這個(gè)選項(xiàng)僅僅檢查備份的頭是否正確。只有使用WITH CHECKSUM才可以完整備份集的校驗(yàn)和檢查。
24 q)可以在不還原證書(shū)的情況下，還原被透明數(shù)據(jù)加密的數(shù)據(jù)庫(kù)
不能，對(duì)于透明數(shù)據(jù)加密最重要的一點(diǎn)要記住，證書(shū)丟了意味著整個(gè)數(shù)據(jù)庫(kù)就沒(méi)了。
24 r)當(dāng)還原過(guò)程完成后，還原會(huì)進(jìn)行Redo和Undo
每次還原操作后其實(shí)執(zhí)行的都是Redo操作，只有在整個(gè)還原過(guò)程完成后，才會(huì)進(jìn)行Undo。
24 s)壓縮備份集只能被還原到SQL Server 2008企業(yè)版中
不，所有的版本都能還原壓縮后的備份。從SQL Server 2008 R2開(kāi)始，標(biāo)準(zhǔn)版也可以進(jìn)行壓縮備份。
24 t)將低版本的數(shù)據(jù)庫(kù)還原到高版本的實(shí)例可以跳過(guò)升級(jí)過(guò)程
不允許，在數(shù)據(jù)還原和附加的過(guò)程中是不允許跳過(guò)必須的升級(jí)和恢復(fù)過(guò)程。
24 u)在32位實(shí)例下備份的數(shù)據(jù)庫(kù)無(wú)法恢復(fù)到64位實(shí)例。反之亦然
錯(cuò)誤，數(shù)據(jù)庫(kù)的內(nèi)部格式和CPU構(gòu)架無(wú)關(guān)。
24 v)只要進(jìn)行數(shù)據(jù)還原，就可以保證程序正常執(zhí)行
不對(duì)，就像高可用性中的鏡像故障轉(zhuǎn)移和事務(wù)日志傳送轉(zhuǎn)移到輔助服務(wù)器一樣，還有很多額外的步驟需要做才能保證程序正常執(zhí)行。包括輔助數(shù)據(jù)庫(kù)和正確的登錄名等。
24 w)還原受損的文件需要從多個(gè)文件組進(jìn)行還原，則必須還原相關(guān)的所有文件組
不，在SQL Server 2000中的確是這樣，但在SQL Server 2005以后的版本就完全不用了。
24 x)你可以將數(shù)據(jù)庫(kù)還原到任何最新版本的實(shí)例
不對(duì)，數(shù)據(jù)庫(kù)只能還原到比其新的一個(gè)或兩個(gè)版本.(比如SQL Server 7.0下的數(shù)據(jù)庫(kù)就不能還原到SQL Server 2008)。
24 y)恢復(fù)時(shí)間和還原時(shí)間是一樣的
不，很多因素會(huì)影響還原的時(shí)間，比如說(shuō)是否有長(zhǎng)事務(wù)需要回滾，或是即時(shí)文件初始化特性是否開(kāi)啟。
24 z)在還原數(shù)據(jù)庫(kù)之前需要先Drop被還原的數(shù)據(jù)庫(kù)
不是的，如果你在還原數(shù)據(jù)庫(kù)之前Drop被還原的數(shù)據(jù)庫(kù)，那么還原過(guò)程首先需要即時(shí)文件初始化，還有，你最好保留被還原數(shù)據(jù)庫(kù)的副本以便還原失敗的情況下把損失減到最小。
