誤區(qū) #30：有關(guān)備份的30個誤區(qū)
全是錯的
在開始有關(guān)備份的誤區(qū)之前，如果你對備份的基礎(chǔ)沒有了解，請看之前我在TechNet Magazine的文章:Understanding SQL Server Backups。
30-01)備份操作會導致阻塞
不，備份不會導致對用戶對象加鎖，雖然備份對IO系統(tǒng)的負擔導致看起來阻塞了，但實際上不會。唯一的特例是當備份包含到那些最小日志操作涉及到的數(shù)據(jù)區(qū)需要被加鎖時，這個操作會阻塞CheckPoint,但DML操作永遠不會受到備份操作的阻塞。
30-02)由完整恢復(fù)模式切換到大容量事務(wù)日志恢復(fù)模式再切換回來會導致日志鏈斷裂
不，這兩種模式互相切換不會導致日志鏈斷裂。
30-03)只有完整備份才能重新開始被斷裂的日志鏈
除了完整備份模式可以重新日志鏈之外，差異備份也可以重新開始日志鏈-總而言之，日志斷裂那部分只要被差異備份所包含，就可以重新開始日志鏈。詳情請看我之前的一篇博文：SQL Server誤區(qū)30日談-Day20-破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈。
30-04)在完整或是差異備份時，不允許進行日志備份
錯誤，在SQL Server 2005之后，完整或是差異備份的同時可以進行日志備份，詳情請看:Search Engine QA #16: Concurrent log and full backups。
30-05)完整或差異備份會清除日志
不，因為日志備份包含了自上次日志備份以來所有的日志，這點無可改變，即使這期間的日志被完整或是差異備份所備份。我在Twitter上曾經(jīng)有一個有名的文章闡述了這點：Misconceptions around the log and log backups: how to convince yourself?？傊谕暾虼笕萘渴聞?wù)日志恢復(fù)模式下，只有備份日志才會清除日志。
30-06)如果使用大容量事務(wù)日志恢復(fù)模式中含有了那些最小記錄日志的操作，則下一次日志備份的日志會減少
不，“最小記錄日志”之所以這么叫是因為只有涉及到相關(guān)的頁分配才會被記錄到日志。日志備份中必須包含使得這類操作可以回滾的部分，也就是所有日志以及“最小記錄日志”操作所涉及的相關(guān)區(qū)。這使得大容量事務(wù)日志模式下日志需要備份的內(nèi)容和完整恢復(fù)模式下日志需要備份的內(nèi)容大小基本一致。
30-07)完整或差異備份中所包含的日志僅僅是這個操作進行時生成的日志
錯誤，完整或差異備份需要日志來將數(shù)據(jù)庫還原到當完整或差異備份結(jié)束時的事務(wù)一致性狀態(tài)。
下面兩篇博文對此有更詳細的解釋:
- Debunking a couple of myths around full database backups
- More on how much transaction log a full backup includes
30-08)備份操作會檢查頁的校驗和
錯誤，只有在備份時指定WITH CHECKSUM選項時才會檢查校驗和，這也是備份應(yīng)該指定的選項。
30-09)備份通過緩沖區(qū)中讀取數(shù)據(jù)
不，備份子系統(tǒng)會對數(shù)據(jù)文件單獨開一個通道以避免將所有涉及到的內(nèi)容讀到內(nèi)存后再存到存儲設(shè)備，因為如果這樣的話備份時性能會嚴重下降(因為這涉及到虛擬內(nèi)存置換回磁盤)。如果備份時你指定了WITH CHECKSUM，則會涉及到少量內(nèi)存使用。
30-10)備份會進行一致性檢查（也就是和DBCC CHECKDB功能一樣）
不會，這沒什么好說的。
30-11)如果備份成功，那么還原也能成功
錯誤，希望你不要形成這樣的思維定勢。你必須定期檢查備份以確保在災(zāi)難發(fā)生時，可以正確的進行還原。詳情請看:Importance of validating backups。
30-12)即使鏡像的路徑不可用，鏡像備份依然可以成功
錯誤，如果鏡像中的一個路徑失效，那么整個鏡像備份都都會失敗。我倒是希望這種機制可以改成鏡像備份時即使一端路徑不可用，那另一端還可以成功備份，但遺憾的是，這不行。
30-13)任何時候都可以進行尾端日志備份
錯誤，尾端日志包含了自上次日志備份以來所有的日志，但這是一種緊急情況，如果數(shù)據(jù)文件受損，并且日志中包含了那些“最小記錄日志”的操作，由于此時需要備份日志以及這類“最小記錄日志”涉及到的相關(guān)區(qū)。如果數(shù)據(jù)文件中的這些區(qū)收縮，則無法備份尾端日志。所以，對于那些24*7的生產(chǎn)環(huán)境，永遠不要使用大容量日志恢復(fù)模式。
30-14)備份可以替代DBCC CheckDB
錯誤，詳情請看SQL Server誤區(qū)30日談-Day27-使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
30-15)可以備份數(shù)據(jù)庫快照
不可以，雖然我也希望可以備份數(shù)據(jù)庫快照。
30-16)可以使用數(shù)據(jù)庫鏡像來替代日志備份
不，只有在數(shù)據(jù)庫鏡像所基于的數(shù)據(jù)庫可用時，鏡像才可用。如果數(shù)據(jù)庫本身被損壞，鏡像一般也不會幸免。而數(shù)據(jù)庫本身suspect,數(shù)據(jù)庫鏡像往往也會suspect。
當然，由于當數(shù)據(jù)庫中頁被修改時，也需要被同步到鏡像，因此存在多個鏡像對數(shù)據(jù)庫性能的影響會非常大。此外，當數(shù)據(jù)庫中被修改的部分越來越多時，鏡像也會不斷膨脹。因此無法用鏡像代替日志備份。
30-17)日志備份所占的大小會和日志所占的大小一致
錯誤。日志中包含了需要回滾活動事務(wù)的日志。DBCC SQLPERF (LOGSPACE)所體現(xiàn)出來的日志空間使用并不能正確反映出日志條目所占的空間。Search Engine QA #25: Why isn't my log backup the same size as my log?。此外，需要備份的日志部分往往是自上次日志備份以來所有的日志。如果日志大于自上次日志備份以來所有的日志，說明還有長時間活動未結(jié)束的事務(wù)。
30-18)無法備份損壞的數(shù)據(jù)庫
錯誤，你可以使用WITH CONTINUE_AFTER_ERROR選項來備份損壞的數(shù)據(jù)庫（如果這個選項還不行，可能是boot頁或文件頭頁損壞了），這也是除了OS級別之上的SQL SERVER備份損壞數(shù)據(jù)庫的唯一辦法。
30-19)你不能禁止別人進行BACKUP LOG .. WITH NO_LOG 和TRUNCATE_ONLY操作
錯誤，在SQL Server 2005中，的確是這樣，但是在SQL Server 2008中，你可以通過跟蹤標記3231來實現(xiàn)這一點。
30-20)日志備份無論在什么條件下都會清除日志
錯誤。如果日志備份的同時并沒有并行執(zhí)行數(shù)據(jù)庫備份，則日志備份會嘗試清除不活動的VLF。對于SQL Server的角度來說，那些沒有備份的日志是也就是SQL Server所必須的日志，這類日志不能被清除。因此對于某些特殊情況，雖然進行了日志備份，但SQL Server仍然認為這些日志是必須的，SQL Server會不斷檢查這些日志直到認為這些日志不再必須，我在TechNet雜志的一篇文章對此有詳細的探討:Understanding Logging and Recovery in SQL Server。
30-21)差異備份是增長式的
錯誤,差異備份所備份的數(shù)據(jù)是自上次完整備份后所有修改的數(shù)據(jù)區(qū)-所以是積累性質(zhì)的(譯者注：比如說在期間你對用一個數(shù)據(jù)區(qū)進行多次修改，差異備份的大小不會變)。只有日志是增長式的。雖然很多人認為差異備份是積累性質(zhì)的，但實際不是。
30-22)當備份完成時，你就可以刪除前一個備份了
No. No. No.
如果當你還原時發(fā)現(xiàn)完整備份已經(jīng)損壞，此時你就該束手無策了吧。如果此時你沒有前一個完整備份，你還是趕緊去招聘網(wǎng)站更新簡歷吧。你需要按照策略多留幾個備份，這樣就能有備無患了。
30-23)可以備份鏡像數(shù)據(jù)庫
錯誤，鏡像(Mirror)只能通過數(shù)據(jù)庫快照訪問。對其也不能進行備份。
30-24)你可以單獨備份一個表
錯誤，如果湊巧這個單獨表在一個文件組上，那么你可以通過備份文件組來達到這個目的，但沒有所謂的:BACKUP TABLE。
30-25)備份數(shù)據(jù)需要關(guān)閉SQL Server
這個，我真不知道這個謠言從哪來的。(編輯:顯然從Oracle來的，因為我們都知道和SQL Server比起來Oracle要強很多:-)。
30-26)正在執(zhí)行的事務(wù)只要在備份完成之前提交就一定會包含在這個備份中
錯誤，只有在備份的數(shù)據(jù)讀取階段完成之前提交并寫入磁盤的事務(wù)才會包含在備份之。詳情請看:Search Engine QA #6: Using fn_dblog to tell if a transaction is contained in a backup。
30-27)在備份之前收縮數(shù)據(jù)庫可以減少備份的大小
錯誤，收縮僅僅是移動頁，并不會引起備份大小的改變。詳情請看:Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup。除此之外，還有一篇博文:SQL Server誤區(qū)30日談-Day9-數(shù)據(jù)庫文件收縮不會影響性能。不但如此，還有人提醒我說，如果在完整備份之后進行了數(shù)據(jù)庫收縮，則即使數(shù)據(jù)沒有改變，下一次差異備份也會變得巨大。
30-28)從備份進行恢復(fù)是當災(zāi)難發(fā)生時最好的辦法
錯誤，只有當0數(shù)據(jù)損失時，備份才是災(zāi)難恢復(fù)最好的辦法。但要減少DownTime由備份進行還原并不是一個好辦法，如果業(yè)務(wù)允許，故障轉(zhuǎn)移或允許一些數(shù)據(jù)損失會更好。
30-29)不需要備份master, msdb, model...等幾個系統(tǒng)數(shù)據(jù)庫
錯誤，這幾個系統(tǒng)數(shù)據(jù)庫是需要進行備份的。Master數(shù)據(jù)庫包含了安全信息以及實例上存在哪些數(shù)據(jù)庫。MSDB數(shù)據(jù)庫包含了SSIS的包，代理任務(wù)，備份歷史。Model數(shù)據(jù)庫包含了新建數(shù)據(jù)庫的模版。不要僅僅只備份用戶數(shù)據(jù)庫，否則從頭開始配置實例將會非常痛苦。
30-30)你需要一個好的備份策略
錯誤
我猜想你一定會說”什么”?你需要的是一個好的還原計劃，而不是備份計劃。根據(jù)業(yè)務(wù)需求和技術(shù)限制來決定什么時間還原什么，再根據(jù)還原來決定應(yīng)該什么時間備份什么。請看下面兩篇文章:
- Importance of having the right backups
- Planning a backup strategy - where to start?
很多人都做了一個備份策略，但不測試也不想怎么還原。當災(zāi)難發(fā)生時導致無法還原，希望你不是這樣。
您可能感興趣的文章:- 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日談 第24天 26個有關(guān)還原(Restore)的誤區(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)頁校驗和的誤區(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)對索引進行在線操作的誤區(qū)
- SQL Server誤區(qū)30日談 第7天 一個實例多個鏡像和日志傳送延遲
- 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會導致阻塞
- SQL Server誤區(qū)30日談 第1天 正在運行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
