損壞恢復(fù)提示、數(shù)據(jù)庫壓縮建議等等
問題：我使用的備份策略是在每天的凌晨 1 點(diǎn)鐘進(jìn)行一次完整備份，每一小時(shí)進(jìn)行一次日志備份，同時(shí)，在每天的凌晨 4 點(diǎn)鐘會(huì)運(yùn)行一次 DBCC CHECKDB。如果我在上午 8 點(diǎn)開始工作時(shí)發(fā)現(xiàn)，夜間運(yùn)行的一致性檢查報(bào)告了大量損壞的情況，我該如何進(jìn)行恢復(fù)才不會(huì)丟失太多數(shù)據(jù)？
解答：這取決于損壞發(fā)生的時(shí)間、損壞的內(nèi)容以及您所采取的備份措施。理想情況是您事先已制定了災(zāi)難恢復(fù)計(jì)劃，因而知道接下來應(yīng)該怎么操作。不過，我會(huì)將您的問題當(dāng)作假設(shè)性問題進(jìn)行回答。
根據(jù)您的描述，損壞的情況是在完整數(shù)據(jù)庫備份完成后通過運(yùn)行 DBCC CHECKDB 發(fā)現(xiàn)的，據(jù)此很難判斷是在數(shù)據(jù)庫備份之前還是之后出現(xiàn)的損壞。如果是在數(shù)據(jù)庫備份之前的某段時(shí)間出現(xiàn)了損壞的情況，則備份中包含已損壞的數(shù)據(jù)庫版本，因此恢復(fù)過程將更加復(fù)雜。
首先要做的是在其他位置還原最近的數(shù)據(jù)庫備份，并對(duì)其運(yùn)行 DBCC CHECKDB。如果未發(fā)現(xiàn)損壞情況，請(qǐng)按以下步驟進(jìn)行還原，這樣應(yīng)該不會(huì)丟失任何數(shù)據(jù)：
運(yùn)行損壞數(shù)據(jù)庫的日志尾部備份（以捕獲最近的事務(wù)）。
還原最近的完整數(shù)據(jù)庫備份，指定 WITH NORECOVERY。
使用 WITH NORECOVERY 依次還原自完整數(shù)據(jù)庫備份以來的所有事務(wù)日志備份以及日志尾部備份。
使用命令 RESTORE databasename WITH RECOVERY 完成還原過程。
最后，您應(yīng)該再運(yùn)行一次 DBCC CHECKDB 以確保不再存在損壞的內(nèi)容，然后在第一時(shí)間執(zhí)行根源分析以找出導(dǎo)致?lián)p壞的原因，并采取措施解決此問題。
如果在執(zhí)行了上述還原步驟后仍存在損壞的內(nèi)容，則說明某個(gè)事務(wù)日志備份中可能包含損壞的內(nèi)容，也可能是內(nèi)存中包含損壞的內(nèi)容，隨后這些內(nèi)容被記錄到了事務(wù)日志中。如果是這種情況，您可能需要執(zhí)行時(shí)間點(diǎn)還原，以確定損壞出現(xiàn)的時(shí)間并在此時(shí)間之前停止還原。此步驟超出了本專欄的討論范圍，但在聯(lián)機(jī)叢書中對(duì)此有詳細(xì)介紹。
如果最近的數(shù)據(jù)庫備份確實(shí)包含損壞的內(nèi)容，您可能需要按照上述步驟進(jìn)行操作，但要從下一個(gè)最近的完整數(shù)據(jù)庫備份開始。此操作假定您仍保有此完整數(shù)據(jù)庫備份和所有干預(yù)日志備份。
另一種可用策略（您可能必須采用以適應(yīng)允許的最長停機(jī)時(shí)間或恢復(fù)時(shí)間目標(biāo)的限制）是手動(dòng)或使用 DBCC CHECKDB 中的修復(fù)功能刪除損壞的數(shù)據(jù)，然后嘗試從較早的一系列備份中恢復(fù)一些數(shù)據(jù)。
從損壞中進(jìn)行恢復(fù)可能非常容易，也可能非常困難，具體取決于錯(cuò)誤的根源以及您可以采取的措施。在接下來的幾個(gè)月內(nèi)，我將會(huì)在幾篇文章中對(duì)此進(jìn)行闡述。
問題：我們的開發(fā)團(tuán)隊(duì)打算構(gòu)建一個(gè)采用 SQL Server 2008 的更改跟蹤功能的解決方案。根據(jù)相關(guān)文檔的說明，我們可能需要針對(duì)相關(guān)的數(shù)據(jù)庫啟用快照隔離，但我擔(dān)心這樣會(huì)影響數(shù)據(jù)庫的性能。您對(duì)此有何評(píng)論？
解答：我在 2008 年 11 月這一期的雜志（“跟蹤企業(yè)數(shù)據(jù)庫中的更改”）中對(duì)更改跟蹤進(jìn)行了說明，對(duì)于您的問題，答案是肯定的，您需要啟用行版本控制。這是因?yàn)闄z索已更改數(shù)據(jù)的機(jī)制通常如下：
查詢更改跟蹤系統(tǒng)以找出更改的表格行。
查詢表格以檢索已更改的行。
在沒有任何行版本控制機(jī)制的情況下，如果在執(zhí)行查詢的過程中運(yùn)行更改跟蹤清理任務(wù)，則首次查詢可能會(huì)返回?zé)o效結(jié)果。而在執(zhí)行第二次查詢前，如果首次查詢的結(jié)果中引用的一些表格行被刪除，則第二次查詢可能會(huì)失敗。
保持穩(wěn)定性的一種做法是鎖定更改跟蹤數(shù)據(jù)和必需的用戶表，但這樣會(huì)導(dǎo)致并發(fā)性能變差（因?yàn)樽柚沟脑颍┖凸ぷ髫?fù)載吞吐量降低。另一種保持穩(wěn)定性的做法是使用快照隔離。
快照隔離有兩種，一種是在事務(wù)級(jí)別提供一致性（數(shù)據(jù)庫選項(xiàng)：allow_snapshot_isolation），另一種是在 T-SQL 語句級(jí)別（數(shù)據(jù)庫選項(xiàng)：read_committed_snapshot）提供一致性。事務(wù)級(jí)別的選項(xiàng)要求正確使用更改跟蹤，這種選項(xiàng)簡稱為快照隔離。
快照隔離可保持表格記錄的版本，舉例來說，某個(gè)顯式事務(wù)啟動(dòng)后，從其啟動(dòng)的時(shí)間點(diǎn)開始，該事務(wù)肯定可以看到數(shù)據(jù)庫的一致的時(shí)間點(diǎn)視圖。要使用更改跟蹤，上述兩次查詢都應(yīng)納入單個(gè)顯式事務(wù)中，隔離級(jí)別應(yīng)設(shè)為快照；這樣就可以保證一致性。
我的妻子 Kimberly 在其白皮書“SQL Server 2005 快照隔離”中對(duì)快照隔離作了詳細(xì)的介紹。
使用快照隔離時(shí)，可能會(huì)出現(xiàn)兩種性能問題。第一種性能問題是，對(duì)數(shù)據(jù)庫中的所有表格進(jìn)行的所有更新都必須生成更改記錄版本，即使版本從未使用過也是如此。記錄的預(yù)更改版本必須被復(fù)制到版本存儲(chǔ)區(qū)中，同時(shí)新的記錄包含指向較早記錄的鏈接，這是為了應(yīng)對(duì)在此事務(wù)完成之前，另一事務(wù)啟動(dòng)并需要正確的記錄版本的情況。這為所有更新操作都增加了一些處理開銷。
第二種性能問題是，版本存儲(chǔ)區(qū)位于 tempdb 數(shù)據(jù)庫內(nèi)。對(duì)某些 SQL Server 實(shí)例而言，Tempdb 可能是最繁忙的數(shù)據(jù)庫，因?yàn)樗┧羞B接和數(shù)據(jù)庫共享。一般而言，tempdb 可能是一個(gè)性能瓶頸，即使不使用行版本控制也是如此。添加行版本控制意味著向 tempdb 增加更多壓力（體現(xiàn)在使用的空間和 I/O 操作上），從而可能導(dǎo)致常規(guī)的工作負(fù)載吞吐量下降。
您可以閱讀白皮書“使用 SQL Server 2005 中的 tempdb”了解更多相關(guān)內(nèi)容。雖然這里提到的兩本白皮書都是針對(duì) SQL Server 2005 撰寫的，但它們同樣適用于 SQL Server 2008。
問題：DBCC CHECKDB 會(huì)全面檢查數(shù)據(jù)庫中的所有內(nèi)容嗎？有人說不會(huì)。另外，修復(fù)系統(tǒng)能修復(fù)所有問題嗎？同樣有人說不能。如果 DBCC CHECKDB 的檢查和修復(fù)并不全面，我該怎么做？
解答：該工具的檢查和修復(fù)可以說是全面的，也可以說是不全面的！DBCC CHECKDB 可提供一組全面的一致性檢查，而隨著其版本的不斷更新，其檢查功能還在不斷增強(qiáng)。不過，也有一些方面是該工具無法檢查的。
簡單來說，該工具可以：
檢查系統(tǒng)目錄的一致性
檢查分配元數(shù)據(jù)的一致性
檢查所有用戶表的一致性
本解答不提供有關(guān)運(yùn)行哪些檢查的更詳細(xì)的說明（您可以訪問我的博客或閱讀最近的 SQL Server 2008 Internals 一書了解詳情），但所用的每個(gè)數(shù)據(jù)庫頁至少會(huì)被讀入內(nèi)存并驗(yàn)證。這樣可以找出由 I/O 子系統(tǒng)中的錯(cuò)誤導(dǎo)致的常見損壞（約 99.99% 的損壞都是這樣產(chǎn)生的）。
在任何版本的 SQL Server 中都不會(huì)被檢查的兩個(gè)最常見的項(xiàng)目是，存儲(chǔ)在數(shù)據(jù)庫中的列內(nèi)容和索引鍵值統(tǒng)計(jì)信息，不過，在今后的版本中，我們可能會(huì)添加對(duì)這兩個(gè)項(xiàng)目和約束有效性（舉例來說，表格之間的外鍵約束）的檢查。約束有效性可單獨(dú)使用 DBCC CHECKDB 的 DBCC CHECKCONSTRAINTS 命令檢查，實(shí)際上，如果您必須在包含約束的數(shù)據(jù)庫中運(yùn)行修復(fù)操作，則建議您以后再驗(yàn)證約束的有效性，這是因?yàn)樾迯?fù)操作不會(huì)考慮約束，并可能會(huì)意外使其無效。這些內(nèi)容都可以在聯(lián)機(jī)叢書中找到。
修復(fù)系統(tǒng)無法修復(fù)所有問題。在合理的時(shí)間內(nèi)，此工具可能無法保證徹底修復(fù)某些錯(cuò)誤。此類損壞很少，我的博客文章“CHECKDB From Every Angle:Can CHECKDB Repair Everything?”對(duì)此進(jìn)行了說明，舉例來說，如果在系統(tǒng)目錄中有一個(gè)損壞的頁面，則可采取的修復(fù)措施只能是刪除此頁面。不過，如果該頁面存儲(chǔ)了數(shù)據(jù)庫中某些用戶表的元數(shù)據(jù)，那該怎么辦？刪除該頁面也就意味著刪除這些用戶表，因此不能進(jìn)行修復(fù)。
大部分修復(fù)操作都會(huì)導(dǎo)致某些數(shù)據(jù)丟失（因?yàn)檫@是在合理的時(shí)間內(nèi)保證正確修復(fù)損壞的唯一途徑），因此，在執(zhí)行災(zāi)難恢復(fù)時(shí)，不到萬不得已請(qǐng)勿使用修復(fù)操作。使用全面?zhèn)浞莶呗灾械膫浞菔潜苊鈦G失數(shù)據(jù)的唯一途徑（除非維護(hù)了某些格式的同步副本）。
DBCC CHECKDB 功能非常全面，可以檢測到破壞性損壞，為確保在第一時(shí)間發(fā)現(xiàn)損壞的內(nèi)容，應(yīng)將定期運(yùn)行 DBCC CHECKDB 作為數(shù)據(jù)庫維護(hù)策略的一部分（參見我的博客文章“Importance of Running Regular Consistency Checks”）。沒有任何工具可以解決一切問題，不過，如果您確保針對(duì)所有數(shù)據(jù)庫啟用頁面校驗(yàn)和，則可以使 DBCC CHECKDB 發(fā)揮更大的作用，同時(shí)可使 SQL Server 檢測到在 SQL Server 內(nèi)存之外更改數(shù)據(jù)庫頁的時(shí)間。
問題：我對(duì)壓縮操作感到困惑。在我閱讀過的相關(guān)文章中，關(guān)于壓縮數(shù)據(jù)文件的操作是好還是壞，說法不一。我在查找有關(guān)壓縮日志文件的相關(guān)信息時(shí)也遇到了這種問題。到底是怎么回事？
解答：壓縮操作的確非常容易讓人產(chǎn)生誤解，而數(shù)據(jù)文件壓縮和日志文件壓縮之間的差異是導(dǎo)致這些誤解的重要原因。
針對(duì)數(shù)據(jù)文件的壓縮操作是為了將距離文件末尾最近的數(shù)據(jù)庫頁移到文件的開頭部分。這樣會(huì)導(dǎo)致數(shù)據(jù)文件的末尾部分產(chǎn)生“空白”區(qū)域，這些區(qū)域可以返還 OS。換句話說，數(shù)據(jù)文件從物理角度而言變小了。
另一方面，針對(duì)事務(wù)日志文件的壓縮操作不會(huì)移動(dòng)任何內(nèi)容，只要事務(wù)日志記錄沒有因?yàn)槿魏卧虮槐Ａ?，該操作就只?huì)刪除文件末尾的事務(wù)日志的空白區(qū)域。如果操作成功，日志文件從物理角度而言會(huì)變小。
用戶的困惑主要集中在這兩種操作的副作用以及何時(shí)執(zhí)行上。
用戶有時(shí)會(huì)被建議（或自行決定）壓縮數(shù)據(jù)文件以回收空間，這可能是因?yàn)槠渌饕S護(hù)操作導(dǎo)致數(shù)據(jù)文件增大，或者其驅(qū)動(dòng)器空間不足，面對(duì)這種情況，用戶自然會(huì)想到回收這樣的一些“被浪費(fèi)”的空間。不過，數(shù)據(jù)文件可能會(huì)再次用到這些空間，因此，通常情況下，最好將剩余的空閑空間保留供數(shù)據(jù)文件使用，而不要重復(fù)地壓縮文件并使文件自動(dòng)增長。
壓縮數(shù)據(jù)文件的副作用非常嚴(yán)重，因此應(yīng)盡量避免使用此操作。壓縮數(shù)據(jù)文件會(huì)導(dǎo)致大量索引碎片的產(chǎn)生，因此可能會(huì)影響查詢的性能。我的博客文章“Why You Should Not Shrink Your Data Files”中提供了一段簡單的腳本來說明這種情況。
我在這篇博客文章中還闡述了何時(shí)可以壓縮數(shù)據(jù)文件（幾乎沒有合適的時(shí)間）以及可以避免產(chǎn)生碎片副作用的其他方法。遺憾的是，我見過許多未提及相關(guān)的副作用就推薦用戶執(zhí)行數(shù)據(jù)文件壓縮的情況。
與壓縮數(shù)據(jù)文件相比，壓縮日志文件的操作更應(yīng)該慎之又慎。通常情況下，由于用戶采用的文件大小管理方法不當(dāng)，導(dǎo)致日志文件過大且與數(shù)據(jù)文件大小相比極不均衡，因此用戶希望壓縮日志文件，或者是因?yàn)橛脩艨吹饺罩疚募兇蠖Ｍ麑⑵淇刂圃诒M可能小的范圍內(nèi)。主動(dòng)數(shù)據(jù)庫的日志文件需要保持合理的大小，但應(yīng)對(duì)日志進(jìn)行管理，以保證無需對(duì)其進(jìn)行壓縮，并無需使其增大以應(yīng)對(duì)數(shù)據(jù)庫中的活動(dòng)。
您可以閱讀我為 2009 年 2 月那一期雜志撰寫的文章“Understanding Logging and Recovery”了解有關(guān)事務(wù)日志的詳情。我還寫過一篇闡述如何管理事務(wù)日志大小的博客文章，請(qǐng)參閱“Importance of Proper Transaction Log Size Management”。
最低要求是盡可能少地進(jìn)行任何形式的壓縮操作，如果確定采取壓縮操作，應(yīng)確保完全理解其可能造成的后果。
本文來源：微軟TechNet中文站
