首先，對于數(shù)據(jù)修復可以做什么，不可以做什么，我已經(jīng)寫過一篇博文Misconceptions around database repair涵蓋了13個誤區(qū)—從不用DBCC CHECKDB是否能修復錯誤（當然不能）到REPAIR_ALLOW_DATA_LOSS是否會引起數(shù)據(jù)丟失（這個名字的確很讓人迷惑）。
其次，很多人抱怨說DBCC CHECKDB第一次運行時顯示的錯誤在第二次運行時會自行消失。這很好解釋:第一次由DBCC CHECKDB檢測出的錯誤頁已經(jīng)不屬于頁分配集了，因此在第二次運行DBCC時就顯示不出來了。我有一篇博文對此進行了詳細的解釋：Misconceptions around corruptions: can they disappear?。
還有一個傳的很廣泛的流言是，運行時間長的操作(比如索引重建，大容量數(shù)據(jù)插入,數(shù)據(jù)庫或文件的收縮)會導致頁損壞。其實不然，除非SQL Server存在BUG的情況下（非常罕見）。沒有任何T-SQL語句會導致數(shù)據(jù)出錯。我?guī)啄昵皩戇^一篇文章對此進行了詳細的解釋:Search Engine QA #26: Myths around causing corruption。
希望這篇文章對澄清這個概念有幫助
您可能感興趣的文章:
SQL Server誤區(qū)30日談 第29天 有關堆碎片的誤區(qū)
SQL Server誤區(qū)30日談 第28天 有關大容量事務日志恢復模式的誤區(qū)
SQL Server誤區(qū)30日談 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
