SQL Server誤區30日談 第30天 有關備份的30個誤區

誤區 #30：有關備份的30個誤區
全是錯的
在開始有關備份的誤區之前，如果你對備份的基礎沒有瞭解，請看之前我在TechNet Magazine的文章:Understanding SQL Server Backups 。

30-01)備份操作會導致阻塞
不，備份不會導致對使用者物件加鎖，雖然備份對IO系統的負擔導致看起來阻塞了，但實際上不會。唯一的特例是當備份包含到那些最小日誌操作涉及到的資料區需要被加鎖時，這個操作會阻塞CheckPoint,但DML操作永遠不會受到備份操作的阻塞。

30-02)由完整復原模式切換到大容量交易記錄復原模式再切換回來會導致日誌鏈斷裂
不，這兩種模式互相切換不會導致日誌鏈斷裂。

30-03)只有完整備份才能重新開始被斷裂的日誌鏈
除了完整備份模式可以重新日誌鏈之外，差異備份也可以重新開始日誌鏈-總而言之，日誌斷裂那部分只要被差異備份所包含，就可以重新開始日誌鏈。詳情請看我之前的一篇博文：SQL Server誤區30日談-Day20-破壞記錄備份鏈之後，需要一個完整備份來重新開始日誌鏈。

30-04)在完整或是差異備份時，不允許進行記錄備份
錯誤，在SQL Server 2005之後，完整或是差異備份的同時可以進行記錄備份，詳情請看:Search Engine Q&A #16: Concurrent log and full backups。

30-05)完整或差異備份會清除日誌
不，因為記錄備份包含了自上次記錄備份以來所有的日誌，這點無可改變，即使這期間的日誌被完整或是差異備份所備份。我在Twitter上曾經有一個有名的文章闡述了這點：Misconceptions around the log and log backups: how to convince yourself。總之，在完整或大容量交易記錄復原模式下，只有備份日誌才會清除日誌。

30-06)如果使用大容量交易記錄復原模式中含有了那些最小記錄日誌的操作，則下一次記錄備份的日誌會減少
不，“最小記錄日誌”之所以這麼叫是因為只有涉及到相關的頁分配才會被記錄到日誌。記錄備份中必須包含使得這類操作可以復原的部分，也就是所有日誌以及“最小記錄日誌”操作所涉及的相關區。這使得大容量交易記錄模式下日誌需要備份的內容和完整復原模式下日誌需要備份的內容大小基本一致。

30-07)完整或差異備份中所包含的日誌僅僅是這個操作進行時產生的日誌
錯誤，完整或差異備份需要日誌來將資料庫還原到當完整或差異備份結束時的事務一致性狀態。
下面兩篇博文對此有更詳細的解釋:

• Debunking a couple of myths around full database backups
• More on how much transaction log a full backup includes

30-08)備份操作會檢查頁的校正和
錯誤，只有在備份時指定WITH CHECKSUM選項時才會檢查校正和，這也是備份應該指定的選項。

30-09)備份通過緩衝區中讀取資料
不，備份子系統會對資料檔案單獨開一個通道以避免將所有涉及到的內容讀到記憶體後再存到存放裝置，因為如果這樣的話備份時效能會嚴重下降(因為這涉及到虛擬記憶體置換回磁碟)。如果備份時你指定了WITH CHECKSUM，則會涉及到少量記憶體使用量。

30-10)備份會進行一致性檢查（也就是和DBCC CHECKDB功能一樣）
不會，這沒什麼好說的。

30-11)如果備份成功，那麼還原也能成功
錯誤，希望你不要形成這樣的思維定勢。你必須定期檢查備份以確保在災難發生時，可以正確的進行還原。詳情請看:Importance of validating backups。

30-12)即使鏡像的路徑不可用，鏡像備份依然可以成功
錯誤，如果鏡像中的一個路徑失效，那麼整個鏡像備份都都會失敗。我倒是希望這種機制可以改成鏡像備份時即使一端路徑不可用，那另一端還可以成功備份，但遺憾的是，這不行。

30-13)任何時候都可以進行尾端記錄備份
錯誤，尾端日誌包含了自上次記錄備份以來所有的日誌，但這是一種緊急情況，如果資料檔案受損，並且日誌中包含了那些“最小記錄日誌”的操作，由於此時需要備份日誌以及這類“最小記錄日誌”涉及到的相關區。如果資料檔案中的這些區收縮，則無法備份尾端日誌。所以，對於那些24*7的生產環境，永遠不要使用大量記錄復原模式。

30-14)備份可以替代DBCC CheckDB
錯誤，詳情請看SQL Server誤區30日談-Day27-使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB

30-15)可以備份資料庫快照集
不可以，雖然我也希望可以備份資料庫快照集。

30-16)可以使用資料庫鏡像來替代記錄備份
不，只有在資料庫鏡像所基於的資料庫可用時，鏡像才可用。如果資料庫本身被損壞，鏡像一般也不會倖免。而資料庫本身suspect,資料庫鏡像往往也會suspect。
當然，由於當資料庫中頁被修改時，也需要被同步到鏡像，因此存在多個鏡像對資料庫效能的影響會非常大。此外，當資料庫中被修改的部分越來越多時，鏡像也會不斷膨脹。因此無法用鏡像代替記錄備份。

30-17)記錄備份所佔的大小會和日誌所佔的大小一致
錯誤。日誌中包含了需要復原活動事務的日誌。DBCC SQLPERF (LOGSPACE)所體現出來的日誌空間使用並不能正確反映出日誌條目所佔的空間。Search Engine Q&A #25: Why isn't my log backup the same size as my log?。此外，需要備份的日誌部分往往是自上次記錄備份以來所有的日誌。如果日誌大於自上次記錄備份以來所有的日誌，說明還有長時間活動未結束的事務。

30-18)無法備份損壞的資料庫
錯誤，你可以使用WITH CONTINUE_AFTER_ERROR選項來備份損壞的資料庫（如果這個選項還不行，可能是boot頁或檔案頭頁損壞了），這也是除了OS層級之上的SQL SERVER備份損壞資料庫的唯一辦法。

30-19)你不能禁止別人進行BACKUP LOG .. WITH NO_LOG 和TRUNCATE_ONLY操作
錯誤，在SQL Server 2005中，的確是這樣，但是在SQL Server 2008中，你可以通過跟蹤標記3231來實現這一點。

30-20)記錄備份無論在什麼條件下都會清除日誌
錯誤。如果記錄備份的同時並沒有並存執行Database Backup，則記錄備份會嘗試清除不活動的VLF。對於SQL Server的角度來說，那些沒有備份的日誌是也就是SQL Server所必須的日誌，這類日誌不能被清除。因此對於某些特殊情況，雖然進行了記錄備份，但SQL Server仍然認為這些日誌是必須的，SQL Server會不斷檢查這些日誌直到認為這些日誌不再必須，我在TechNet雜誌的一篇文章對此有詳細的探討:Understanding Logging and Recovery in SQL Server。

30-21)差異備份是增長式的
錯誤,差異備份所備份的資料是自上次完整備份後所有修改的資料區-所以是積累性質的(譯者註：比如說在期間你對用一個資料區進行多次修改，差異備份的大小不會變)。只有日誌是增長式的。雖然很多人認為差異備份是積累性質的，但實際不是。

30-22)當備份完成時，你就可以刪除前一個備份了
No. No. No.
如果當你還原時發現完整備份已經損壞，此時你就該束手無策了吧。如果此時你沒有前一個完整備份，你還是趕緊去招聘網站更新簡曆吧。你需要按照策略多留幾個備份，這樣就能有備無患了。

30-23)可以備份鏡像資料庫
錯誤，鏡像(Mirror)只能通過資料庫快照集訪問。對其也不能進行備份。

30-24)你可以單獨備份一個表
錯誤，如果湊巧這個單獨表在一個檔案組上，那麼你可以通過備份檔案組來達到這個目的，但沒有所謂的:BACKUP TABLE。

30-25)備份資料需要關閉SQL Server
這個，我真不知道這個謠言從哪來的。(編輯:顯然從Oracle來的，因為我們都知道和SQL Server比起來Oracle要強很多:-)。

30-26)正在執行的事務只要在備份完成之前提交就一定會包含在這個備份中
錯誤，只有在備份的資料讀取階段完成之前提交並寫入磁碟的事務才會包含在備份之。詳情請看:Search Engine Q&A #6: Using fn_dblog to tell if a transaction is contained in a backup。

30-27)在備份之前收縮資料庫可以減少備份的大小
錯誤，收縮僅僅是移動頁，並不會引起備份大小的改變。詳情請看:Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup。除此之外，還有一篇博文:SQL Server誤區30日談-Day9-資料庫檔案收縮不會影響效能。不但如此，還有人提醒我說，如果在完整備份之後進行了資料庫收縮，則即使資料沒有改變，下一次差異備份也會變得巨大。

30-28)從備份進行恢複是當災難發生時最好的辦法
錯誤，只有當0資料損失時，備份才是災難恢複最好的辦法。但要減少DownTime由備份進行還原並不是一個好辦法，如果業務允許，容錯移轉或允許一些資料損失會更好。

30-29)不需要備份master, msdb, model...等幾個系統資料庫

錯誤，這幾個系統資料庫是需要進行備份的。Master資料庫包含了安全資訊以及執行個體上存在哪些資料庫。MSDB資料庫包含了SSIS的包，代理任務，備份曆史。Model資料庫包含了建立資料庫的模版。不要僅僅只備份使用者資料庫，否則從頭開始配置執行個體將會非常痛苦。

30-30)你需要一個好的備份策略

錯誤

我猜想你一定會說”什麼”?你需要的是一個好的還原計劃，而不是備份計劃。根據業務需求和技術限制來決定什麼時間還原什麼，再根據還原來決定應該什麼時間備份什麼。請看下面兩篇文章:

• Importance of having the right backups
• Planning a backup strategy - where to start?

很多人都做了一個備份策略，但不測試也不想怎麼還原。當災難發生時導致無法還原，希望你不是這樣。