SQL Server誤區30日談 第24天 26個有關復原(Restore)的誤區。本站提示廣大學習愛好者：（SQL Server誤區30日談 第24天 26個有關復原(Restore)的誤區）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第24天 26個有關復原(Restore)的誤區正文
本系列文章一向所沒有觸及的就是有關”復原(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被復原的數據庫，那末復原進程起首須要即時文件初始化，還有，你最好保存被復原數據庫的正本以便復原掉敗的情形下把喪失減到最小。
