SQL Server誤區30日談 第24天 26個有關還原(Restore)的誤區_MsSql

本系列文章一直所沒有觸及的就是有關”還原(Restore)”的話題，因為一旦牽扯到這個話題就會涉及大量的誤區，多到我無法通過一篇文章說完的地步。
事實上，我希望用字母表的順序為每一個誤區進行編號，希望你看了不要昏昏欲睡。下面開始揭穿這26個誤區。

誤區 #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被還原的資料庫，那麼還原過程首先需要檔案立即初始化，還有，你最好保留被還原資料庫的副本以便還原失敗的情況下把損失減到最小。