亚洲成a∨人片在线观看无码,少妇高潮太爽了在线视频,日本在线天堂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24 n)只要備份成功，就可以利用這個(gè)備份集進(jìn)行還原
No,no,no。備份集只是存儲(chǔ)在IO子系統(tǒng)的文件，就和數(shù)據(jù)庫的文件一樣。它也有損壞的可能。你需要定期檢查備份是否被損壞，否則當(dāng)災(zāi)難發(fā)生后的驚喜怕你是承受不了。請(qǐng)看:Importance of validating backups。另外一點(diǎn)需要注意的是避免額外的完整備份破壞恢復(fù)順序，這個(gè)例子或許會(huì)給你一點(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)行自動(dòng)頁修復(fù))。詳情你可以看我這篇文章:Search Engine QA #22: Can all page types be single-page restored?。

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

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

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

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

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

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

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

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

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

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

24 z)在還原數(shù)據(jù)庫之前需要先Drop被還原的數(shù)據(jù)庫
不是的，如果你在還原數(shù)據(jù)庫之前Drop被還原的數(shù)據(jù)庫，那么還原過程首先需要即時(shí)文件初始化，還有，你最好保留被還原數(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)鎖升級(jí)的誤區(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天破壞日志備份鏈之后，需要一個(gè)完整備份來重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會(huì)被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲(chǔ)，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會(huì)將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會(huì)將相關(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天鏡像在檢測(cè)到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫文件收縮不會(huì)影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對(duì)索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個(gè)實(shí)例多個(gè)鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個(gè)誤區(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天即時(shí)文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會(huì)導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
SQL Server誤區(qū)30日談第30天有關(guān)備份的30個(gè)誤區(qū)

標(biāo)簽：昭通上海拉薩江蘇貴州新鄉(xiāng) 呼和浩特重慶

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