素人大屁股午夜激情电影,狠狠噜天天噜日日噜av

主頁 > 知識庫 > SQL Server誤區(qū)30日談第24天 26個有關(guān)還原(Restore)的誤區(qū)

SQL Server誤區(qū)30日談第24天 26個有關(guān)還原(Restore)的誤區(qū)

本系列文章一直所沒有觸及的就是有關(guān)”還原(Restore)”的話題，因?yàn)橐坏砍兜竭@個話題就會涉及大量的誤區(qū)，多到我無法通過一篇文章說完的地步。
事實(shí)上，我希望用字母表的順序?yàn)槊恳粋€誤區(qū)進(jìn)行編號，希望你看了不要昏昏欲睡。下面開始揭穿這26個誤區(qū)。

誤區(qū) #24: 26個有關(guān)還原(Restore)的誤區(qū)
都是錯誤的

24 a)可以通過WITH STOPAT參數(shù)在完整備份和差異備份的基礎(chǔ)上還原到特定時間點(diǎn)
當(dāng)然不能。雖然這個語法看上去貌似能的樣子，但這個語法的最佳實(shí)踐是你在進(jìn)行日志還原到特定時間點(diǎn)時帶上，這樣你的還原就不會超過這個時間點(diǎn)（譯者注：比如說還原的第一個日志備份中不包含這個時間點(diǎn)，但你帶上這個參數(shù)則這個日志備份會被全部還原，直到你還原到包含時間點(diǎn)的日志備份而不用擔(dān)心還原過頭）,對此我之前的一篇文章會更有幫助:Debunking a couple of myths around full database backups。

24 b)使用了WITH CONTINUE_AFTER_ERROR選項(xiàng)之后還可以按照既定的還原順序進(jìn)行還原
錯誤。如果你的備份集有損壞而不得不使用這個選項(xiàng)，那么你的還原順序?qū)粡?fù)存在。當(dāng)進(jìn)行日志還原時日志損壞，那么使用這個選項(xiàng)之前就需要三思而后行，因?yàn)檫@很有可能造成數(shù)據(jù)不一致的問題。在最壞的情況下會造成數(shù)據(jù)庫中結(jié)構(gòu)被破壞，我不推薦使用這個選項(xiàng)。

24 c)可以將數(shù)據(jù)庫的一部分還原到特定時間點(diǎn)
不能，數(shù)據(jù)庫的每個部分都需要和主文件組時間點(diǎn)一致，否則就無法上線。當(dāng)然只讀文件組除外。

24 d)可以將不同數(shù)據(jù)庫的不同文件組還原到一個新的數(shù)據(jù)庫中
不能，每個數(shù)據(jù)庫的文件頭頁（譯者注：也就是頁號為0的頁）都有一個GUID，除非這個GUID和另外數(shù)據(jù)庫的GUID一致才能還原（這當(dāng)然不可能）。

24 e)還原可以去除索引碎片（或是更新統(tǒng)計(jì)信息等等）
不能，你備份的是什么還原的就是什么，我之前的一篇文章對此有更詳細(xì)的解釋:blog post over on our SQL Server Magazine QA blog。

24 f)在還原的過程中可以進(jìn)行數(shù)據(jù)庫收縮
不能，雖然大家都需要這個功能，在開發(fā)環(huán)境下恢復(fù)一個大部分是空的備份集時這就十分有用。但就是不能。

24 g)可以將數(shù)據(jù)庫還原到任何更低版本的實(shí)例
不能，這是一個普遍存在的誤區(qū)。低版本的實(shí)例對于高版本的數(shù)據(jù)庫的部分內(nèi)容有可能無法理解（比如sql server 2005的數(shù)據(jù)庫就無法理解SQL Server 2008數(shù)據(jù)庫的一些內(nèi)容）。

24 h)可以將數(shù)據(jù)庫還原到任意版本的SQL Server中
錯誤，比如說SQL Server 2005,一個含有表分區(qū)的數(shù)據(jù)庫只能還原到企業(yè)版中。在SQL Server 2008只能還原到企業(yè)版的數(shù)據(jù)庫包含了如下特性:分區(qū)，透明數(shù)據(jù)加密，CDC,數(shù)據(jù)壓縮。有關(guān)這里我已經(jīng)寫過一篇文章，請看:SQL Server 2008: Does my database contain Enterprise-only features?。

24 i)WITH STANDBY參數(shù)會破壞還原鏈
不會，這個參數(shù)的作用是使得在還原的過程中，保證數(shù)據(jù)庫事務(wù)級別的一致性。從還原順序的角度來說，With Standby參數(shù)WITH NORECOVERY并無區(qū)別。你可以在還原的過程中停止N次。這也是事務(wù)日志傳送的機(jī)制。經(jīng)常有人會問在事務(wù)傳送的輔助服務(wù)器進(jìn)行日志恢復(fù)的過程是否能訪問，至此你應(yīng)該知道是可以只讀訪問的。同時，這個選項(xiàng)也可能造成一些詭異的問題，請看:Why could restoring a log-shipping log backup be slow?。

24 j)如果備份數(shù)據(jù)庫的服務(wù)器沒有開啟即時文件初始化選項(xiàng)，那么恢復(fù)的服務(wù)器就不能利用這個特性
是否能進(jìn)行即時文件初始化完全取決于被還原的服務(wù)器受否開啟這個特性。備份集中不會含有任何有關(guān)這點(diǎn)的信息。更詳細(xì)的內(nèi)容請看:SQL Server誤區(qū)30日談-Day3-即時文件初始化特性可以在SQL Server中開啟和關(guān)閉。

24 k)還原是從損壞中恢復(fù)的最佳辦法
不是,并不完全是。這要取決于你有的備份類型。如果損壞的數(shù)據(jù)比較多，那么利用還原是一個不錯的主意，但如果損失的數(shù)據(jù)比較少并允許一些數(shù)據(jù)損失的情況下，亦或是由事務(wù)日志傳送的輔助服務(wù)器回傳一些日志的情況下，那么downtime就會少很多。最佳辦法就是在可接受的數(shù)據(jù)損失范圍內(nèi)，在盡量少的downtime修復(fù)損壞。

24 l)在開始還原之后還可以備份尾端日志
不允許，一旦你開始還原之后，就不再允許備份尾端日志。所以當(dāng)災(zāi)難發(fā)生之后，第一件事永遠(yuǎn)都是查看是否需要備份尾端日志。

24 m)你可以還原到在備份的日志范圍之內(nèi)的任何時間點(diǎn)
這是不對的。如果日志中包含了那些那些僅僅少量日志的操作(比如批量數(shù)據(jù)導(dǎo)入操作)，這類操作具有原子性，要么全部還原，要么不還原。這是由于這類操作對于區(qū)的進(jìn)行了修改，但備份集中并沒記錄何時修改了這些區(qū)。你可以通過如下腳本查看日志備份包含的信息量：New script: how much data will the next log backup include?。

24 n)只要備份成功，就可以利用這個備份集進(jìn)行還原
No,no,no。備份集只是存儲在IO子系統(tǒng)的文件，就和數(shù)據(jù)庫的文件一樣。它也有損壞的可能。你需要定期檢查備份是否被損壞，否則當(dāng)災(zāi)難發(fā)生后的驚喜怕你是承受不了。請看:Importance of validating backups。另外一點(diǎn)需要注意的是避免額外的完整備份破壞恢復(fù)順序，這個例子或許會給你一點(diǎn)警示：BACKUP WITH COPY_ONLY - how to avoid breaking the backup chain。

24 o)所有的SQL Server頁類型都可以通過單頁恢復(fù)進(jìn)行還原
不，一些分配位圖的頁（譯者注：比如GAM,SGMA,FPS頁等）不能通過進(jìn)行單頁還原(這類頁可以通過SQL Server 2008 的鏡像進(jìn)行自動頁修復(fù))。詳情你可以看我這篇文章:Search Engine QA #22: Can all page types be single-page restored?。

24 p)RESTORE ... WITH VERIFYONLY選項(xiàng)會驗(yàn)證整個備份集
不，這個選項(xiàng)僅僅檢查備份的頭是否正確。只有使用WITH CHECKSUM才可以完整備份集的校驗(yàn)和檢查。

24 q)可以在不還原證書的情況下，還原被透明數(shù)據(jù)加密的數(shù)據(jù)庫
不能，對于透明數(shù)據(jù)加密最重要的一點(diǎn)要記住，證書丟了意味著整個數(shù)據(jù)庫就沒了。

24 r)當(dāng)還原過程完成后，還原會進(jìn)行Redo和Undo
每次還原操作后其實(shí)執(zhí)行的都是Redo操作，只有在整個還原過程完成后，才會進(jìn)行Undo。

24 s)壓縮備份集只能被還原到SQL Server 2008企業(yè)版中
不，所有的版本都能還原壓縮后的備份。從SQL Server 2008 R2開始，標(biāo)準(zhǔn)版也可以進(jìn)行壓縮備份。

24 t)將低版本的數(shù)據(jù)庫還原到高版本的實(shí)例可以跳過升級過程
不允許，在數(shù)據(jù)還原和附加的過程中是不允許跳過必須的升級和恢復(fù)過程。

24 u)在32位實(shí)例下備份的數(shù)據(jù)庫無法恢復(fù)到64位實(shí)例。反之亦然
錯誤，數(shù)據(jù)庫的內(nèi)部格式和CPU構(gòu)架無關(guān)。

24 v)只要進(jìn)行數(shù)據(jù)還原，就可以保證程序正常執(zhí)行
不對，就像高可用性中的鏡像故障轉(zhuǎn)移和事務(wù)日志傳送轉(zhuǎn)移到輔助服務(wù)器一樣，還有很多額外的步驟需要做才能保證程序正常執(zhí)行。包括輔助數(shù)據(jù)庫和正確的登錄名等。

24 w)還原受損的文件需要從多個文件組進(jìn)行還原，則必須還原相關(guān)的所有文件組
不，在SQL Server 2000中的確是這樣，但在SQL Server 2005以后的版本就完全不用了。

24 x)你可以將數(shù)據(jù)庫還原到任何最新版本的實(shí)例
不對，數(shù)據(jù)庫只能還原到比其新的一個或兩個版本.(比如SQL Server 7.0下的數(shù)據(jù)庫就不能還原到SQL Server 2008)。

24 y)恢復(fù)時間和還原時間是一樣的
不，很多因素會影響還原的時間，比如說是否有長事務(wù)需要回滾，或是即時文件初始化特性是否開啟。

24 z)在還原數(shù)據(jù)庫之前需要先Drop被還原的數(shù)據(jù)庫
不是的，如果你在還原數(shù)據(jù)庫之前Drop被還原的數(shù)據(jù)庫，那么還原過程首先需要即時文件初始化，還有，你最好保留被還原數(shù)據(jù)庫的副本以便還原失敗的情況下把損失減到最小。

您可能感興趣的文章:

SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)
SQL Server誤區(qū)30日談第28天有關(guān)大容量事務(wù)日志恢復(fù)模式的誤區(qū)
SQL Server誤區(qū)30日談第27天使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
SQL Server誤區(qū)30日談第26天 SQL Server中存在真正的“事務(wù)嵌套”
SQL Server誤區(qū)30日談第25天有關(guān)填充因子的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過重啟SQL Server來修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會將相關(guān)的LSN填零初始化
SQL Server誤區(qū)30日談第13天在SQL Server 2000兼容模式下不能使用DMV
SQL Server誤區(qū)30日談第12天 TempDB的文件數(shù)和需要和CPU數(shù)目保持一致
SQL Server誤區(qū)30日談第11天鏡像在檢測到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫文件收縮不會影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個實(shí)例多個鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個誤區(qū)
SQL Server誤區(qū)30日談第5天 AWE在64位SQL SERVER中必須開啟
SQL Server誤區(qū)30日談第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
SQL Server誤區(qū)30日談第3天即時文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
SQL Server誤區(qū)30日談第30天有關(guān)備份的30個誤區(qū)

標(biāo)簽：湘潭銅川仙桃湖南黃山崇左衡水蘭州

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《SQL Server誤區(qū)30日談第24天 26個有關(guān)還原(Restore)的誤區(qū)》，本文關(guān)鍵詞；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。

SQL Server誤區(qū)30日談 第24天 26個有關(guān)還原(Restore)的誤區(qū)

QQ咨詢

電話咨詢

SQL Server誤區(qū)30日談第24天 26個有關(guān)還原(Restore)的誤區(qū)