編者注：Robert L Davis是微軟的高級數據庫管理員和專家，同時是《SQL Server》雜志的撰稿人，并合著《Pro SQL Server 2008 Mirroring》一書。

數據損壞隨時可能發生在任何人身上，沒有任何辦法可保證它不會發生。DBA的職責是，盡量盡早發現損壞，并及時處理。我在之前的文章《DBA 五大致命失誤：你的數據可靠嗎?》中提到過，數據受損是災難事件中的一部分，現在單獨拿出來討論，希望大家能夠重視它的重要性。大多數DBA沒有豐富經驗如何處理損壞，因為這并不是定期會遇到的問題。真正發生時，關鍵措施之一就是迅速找到損壞的數據所在。如果不這樣做，可能會導致無法從損壞之處進行恢復，并且不丟失數據，相反，可能有時會丟失大量數據。

SQL Server提供了很多內置的方法幫助檢測損壞。 我在之前一文介紹了用于備份和恢復的CHECKSUM選項，并在以后會介紹頁校驗(page verification)選項。現在要介紹的是使用DBCC CHECKDB命令或其他DBCC CHECK命令進行基本的數據完整性檢查。

DBA再忙，但至少應該定期檢查所有數據庫的完整性。經常被DBA忽視的是“定期檢查”。恢復受損數據不丟失任何數據，并將停機時間最小化，這就意味著要對部分或整個數據庫進行備份。但是，如果你備份的數據庫已經受損(沒有使用CHECKSUM選項)，那你得到的就是受損的備份。如果這個受損備份長時間沒有被發現，你不太可能有一個好的、未損壞的備份，并能夠把數據庫恢復到當前時間。

即使是在磁帶上長期存儲，你可能也需要及時檢查備份是否有損壞。也有可能你并沒有從受損點之后的所有日志文件，以致你無法把數據庫恢復至當前。這可能意味著相當多的數據會丟失。至少，如果通過異地存儲進行恢復，可能造成長時間的宕機。最糟的情況是，大多數(或全部)的數據可能丟失。曾有過這樣的公司因為發生類似的事件，造成***公司倒閉。

雖然DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS這個選項操作簡單，但自動修復損壞應該作為***不得已的選擇。這個選項通過重新分配受損頁進行修復，但如果數據頁一旦消失了，就***消失了。在無法快速查找損壞，也沒有未受損的有效備份時，很多DBA可能會采用這種方法。但，這是DBA很嚴重的疏忽之處，不及時檢測受損數據，會讓自己時刻面臨被炒的危險。