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

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

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

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

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

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