誤區 #27:使用BACKUP ... WITH CHECKSUM可以替代DBCC CheckDB 錯誤 乍一看，由于BACKUP WITH CHECKSUM會檢測所有分配出去的頁的校驗和的值，這個誤區貌似是這么回事，但實際上并不是這么回事，原因如下: 由SQL Server 2000或是更早版本升上來的數據庫page checksums必須開啟，在開啟后，并不是數據庫中所有的頁都會被叫上頁校驗和，當頁損壞發生時，IO系統可不會區分損壞的頁是有頁校驗和還是沒有校驗和的。所以使用BACKUP ... WITH CHECKSUM就有可能導致一些損壞頁不被發現，造成的后果…… 除此之外，還有一個問題是完整備份的時間間隔相對比較長，假如說一個月，而相對于DBCC CheckDB的最佳實踐是一個禮拜，這導致WITH CHECKSUM不能替代CHECKDB。即使你每周都進行差異備份，但差異備份只會檢測差異部分的頁校驗和。 最后一點，也是危害最大的一點,就是使用BACKUP WITH CHECKSUM選項不能發現內存中的頁損壞。這是因為由于內存芯片或是WINDOWS進程導致內存中的頁損壞，并且在這之后寫回磁盤。這導致損壞頁卻有正常的校驗和，只有使用DBCC CheckDB才能發現這類錯誤。 因此，說到底，你必須經常使用DBCC CHECKDB，如果對此你仍然心存疑問，請看我之前的一篇文章:CHECKDB From Every Angle: Consistency Checking Options for a VLDB。
擴展閱讀:Search Engine QA #26: Myths around causing corruption
您可能感興趣的文章:
SQL Server誤區30日談 第29天 有關堆碎片的誤區
SQL Server誤區30日談 第28天 有關大容量事務日志恢復模式的誤區
SQL Server誤區30日談 第26天 SQL Server中存在真正的“事務嵌套”
SQL Server誤區30日談 第25天 有關填充因子的誤區
SQL Server誤區30日談 第24天 26個有關還原(Restore)的誤區
SQL Server誤區30日談 第23天 有關鎖升級的誤區
SQL Server誤區30日談 第22天 資源調控器可以調控IO
SQL Server誤區30日談 第21天 數據損壞可以通過重啟SQL Server來修復
SQL Server誤區30日談 第20天 破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
SQL Server誤區30日談 第19天 Truncate表的操作不會被記錄到日志
SQL Server誤區30日談 第18天 有關FileStream的存儲，垃圾回收以及其它
SQL Server誤區30日談 第17天 有關頁校驗和的誤區
SQL Server誤區30日談 第16天 數據的損壞和修復
SQL Server誤區30日談 第15天 CheckPoint只會將已提交的事務寫入磁盤
SQL Server誤區30日談 第14天 清除日志后會將相關的LSN填零初始化
SQL Server誤區30日談 第13天 在SQL Server 2000兼容模式下不能使用DMV
