SQL Server誤區30日談-Day24-26個有關還原(Restore)的誤區

    本系列文章是我在sqlskill.com的PAUL的部落格看到的，很多誤區都比較具有典型性和代表性，原文來自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,經過我們團隊的翻譯和整理釋出在AgileSharp上。希望對大家有所幫助。

    本系列文章一直所沒有觸及的就是有關”還原(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被還原的資料庫，那麼還原過程首先需要即時檔案初始化，還有，你最好保留被還原資料庫的副本以便還原失敗的情況下把損失減到最小。

本文轉自CareySon部落格園部落格，原文連結：http://www.cnblogs.com/CareySon/archive/2013/01/18/2866428.html，如需轉載請自行聯系原作者