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