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

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

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

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

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

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