問題：我使用的備份策略是在每天的凌晨 1 點鐘進行一次完整備份，每一小時進行一次日志備份，同時，在每天的凌晨 4 點鐘會運行一次 DBCC CHECKDB。如果我在上午 8 點開始工作時發現，夜間運行的一致性檢查報告了大量損壞的情況，我該如何進行恢復才不會丟失太多數據？

解答：這取決于損壞發生的時間、損壞的內容以及您所采取的備份措施。理想情況是您事先已制定了災難恢復計劃，因而知道接下來應該怎么操作。不過，我會將您的問題當作假設性問題進行回答。

根據您的描述，損壞的情況是在完整數據庫備份完成后通過運行 DBCC CHECKDB 發現的，據此很難判斷是在數據庫備份之前還是之后出現的損壞。如果是在數據庫備份之前的某段時間出現了損壞的情況，則備份中包含已損壞的數據庫版本，因此恢復過程將更加復雜。

首先要做的是在其他位置還原最近的數據庫備份，并對其運行 DBCC CHECKDB。如果未發現損壞情況，請按以下步驟進行還原，這樣應該不會丟失任何數據：

運行損壞數據庫的日志尾部備份（以捕獲最近的事務）。
還原最近的完整數據庫備份，指定 WITH NORECOVERY。
使用 WITH NORECOVERY 依次還原自完整數據庫備份以來的所有事務日志備份以及日志尾部備份。
使用命令 RESTORE databasename WITH RECOVERY 完成還原過程。
最后，您應該再運行一次 DBCC CHECKDB 以確保不再存在損壞的內容，然后在第一時間執行根源分析以找出導致損壞的原因，并采取措施解決此問題。

如果在執行了上述還原步驟后仍存在損壞的內容，則說明某個事務日志備份中可能包含損壞的內容，也可能是內存中包含損壞的內容，隨后這些內容被記錄到了事務日志中。如果是這種情況，您可能需要執行時間點還原，以確定損壞出現的時間并在此時間之前停止還原。此步驟超出了本專欄的討論范圍，但在聯機叢書中對此有詳細介紹。

如果最近的數據庫備份確實包含損壞的內容，您可能需要按照上述步驟進行操作，但要從下一個最近的完整數據庫備份開始。此操作假定您仍保有此完整數據庫備份和所有干預日志備份。

另一種可用策略（您可能必須采用以適應允許的最長停機時間或恢復時間目標的限制）是手動或使用 DBCC CHECKDB 中的修復功能刪除損壞的數據，然后嘗試從較早的一系列備份中恢復一些數據。

從損壞中進行恢復可能非常容易，也可能非常困難，具體取決于錯誤的根源以及您可以采取的措施。在接下來的幾個月內，我將會在幾篇文章中對此進行闡述。

問題：我們的開發團隊打算構建一個采用 SQL Server 2008 的更改跟蹤功能的解決方案。根據相關文檔的說明，我們可能需要針對相關的數據庫啟用快照隔離，但我擔心這樣會影響數據庫的性能。您對此有何評論？

解答：我在 2008 年 11 月這一期的雜志（“跟蹤企業數據庫中的更改”）中對更改跟蹤進行了說明，對于您的問題，答案是肯定的，您需要啟用行版本控制。這是因為檢索已更改數據的機制通常如下：

查詢更改跟蹤系統以找出更改的表格行。
查詢表格以檢索已更改的行。
在沒有任何行版本控制機制的情況下，如果在執行查詢的過程中運行更改跟蹤清理任務，則首次查詢可能會返回無效結果。而在執行第二次查詢前，如果首次查詢的結果中引用的一些表格行被刪除，則第二次查詢可能會失敗。

保持穩定性的一種做法是鎖定更改跟蹤數據和必需的用戶表，但這樣會導致并發性能變差（因為阻止的原因）和工作負載吞吐量降低。另一種保持穩定性的做法是使用快照隔離。

快照隔離有兩種，一種是在事務級別提供一致性（數據庫選項：allow_snapshot_isolation），另一種是在 T-SQL 語句級別（數據庫選項：read_committed_snapshot）提供一致性。事務級別的選項要求正確使用更改跟蹤，這種選項簡稱為快照隔離。

快照隔離可保持表格記錄的版本，舉例來說，某個顯式事務啟動后，從其啟動的時間點開始，該事務肯定可以看到數據庫的一致的時間點視圖。要使用更改跟蹤，上述兩次查詢都應納入單個顯式事務中，隔離級別應設為快照；這樣就可以保證一致性。

我的妻子 Kimberly 在其白皮書“SQL Server 2005 快照隔離”中對快照隔離作了詳細的介紹。

使用快照隔離時，可能會出現兩種性能問題。第一種性能問題是，對數據庫中的所有表格進行的所有更新都必須生成更改記錄版本，即使版本從未使用過也是如此。記錄的預更改版本必須被復制到版本存儲區中，同時新的記錄包含指向較早記錄的鏈接，這是為了應對在此事務完成之前，另一事務啟動并需要正確的記錄版本的情況。這為所有更新操作都增加了一些處理開銷。

第二種性能問題是，版本存儲區位于 tempdb 數據庫內。對某些 SQL Server 實例而言，Tempdb 可能是最繁忙的數據庫，因為它供所有連接和數據庫共享。一般而言，tempdb 可能是一個性能瓶頸，即使不使用行版本控制也是如此。添加行版本控制意味著向 tempdb 增加更多壓力（體現在使用的空間和 I/O 操作上），從而可能導致常規的工作負載吞吐量下降。

您可以閱讀白皮書“使用 SQL Server 2005 中的 tempdb”了解更多相關內容。雖然這里提到的兩本白皮書都是針對 SQL Server 2005 撰寫的，但它們同樣適用于 SQL Server 2008。

問題：DBCC CHECKDB 會全面檢查數據庫中的所有內容嗎？有人說不會。另外，修復系統能修復所有問題嗎？同樣有人說不能。如果 DBCC CHECKDB 的檢查和修復并不全面，我該怎么做？

解答：該工具的檢查和修復可以說是全面的，也可以說是不全面的！DBCC CHECKDB 可提供一組全面的一致性檢查，而隨著其版本的不斷更新，其檢查功能還在不斷增強。不過，也有一些方面是該工具無法檢查的。

簡單來說，該工具可以：

檢查系統目錄的一致性
檢查分配元數據的一致性
檢查所有用戶表的一致性
本解答不提供有關運行哪些檢查的更詳細的說明（您可以訪問我的博客或閱讀最近的 SQL Server 2008 Internals 一書了解詳情），但所用的每個數據庫頁至少會被讀入內存并驗證。這樣可以找出由 I/O 子系統中的錯誤導致的常見損壞（約 99.99% 的損壞都是這樣產生的）。

在任何版本的 SQL Server 中都不會被檢查的兩個最常見的項目是，存儲在數據庫中的列內容和索引鍵值統計信息，不過，在今后的版本中，我們可能會添加對這兩個項目和約束有效性（舉例來說，表格之間的外鍵約束）的檢查。約束有效性可單獨使用 DBCC CHECKDB 的 DBCC CHECKCONSTRAINTS 命令檢查，實際上，如果您必須在包含約束的數據庫中運行修復操作，則建議您以后再驗證約束的有效性，這是因為修復操作不會考慮約束，并可能會意外使其無效。這些內容都可以在聯機叢書中找到。

修復系統無法修復所有問題。在合理的時間內，此工具可能無法保證徹底修復某些錯誤。此類損壞很少，我的博客文章“CHECKDB From Every Angle:Can CHECKDB Repair Everything?”對此進行了說明，舉例來說，如果在系統目錄中有一個損壞的頁面，則可采取的修復措施只能是刪除此頁面。不過，如果該頁面存儲了數據庫中某些用戶表的元數據，那該怎么辦？刪除該頁面也就意味著刪除這些用戶表，因此不能進行修復。

大部分修復操作都會導致某些數據丟失（因為這是在合理的時間內保證正確修復損壞的唯一途徑），因此，在執行災難恢復時，不到萬不得已請勿使用修復操作。使用全面備份策略中的備份是避免丟失數據的唯一途徑（除非維護了某些格式的同步副本）。

DBCC CHECKDB 功能非常全面，可以檢測到破壞性損壞，為確保在第一時間發現損壞的內容，應將定期運行 DBCC CHECKDB 作為數據庫維護策略的一部分（參見我的博客文章“Importance of Running Regular Consistency Checks”）。沒有任何工具可以解決一切問題，不過，如果您確保針對所有數據庫啟用頁面校驗和，則可以使 DBCC CHECKDB 發揮更大的作用，同時可使 SQL Server 檢測到在 SQL Server 內存之外更改數據庫頁的時間。

問題：我對壓縮操作感到困惑。在我閱讀過的相關文章中，關于壓縮數據文件的操作是好還是壞，說法不一。我在查找有關壓縮日志文件的相關信息時也遇到了這種問題。到底是怎么回事？

解答：壓縮操作的確非常容易讓人產生誤解，而數據文件壓縮和日志文件壓縮之間的差異是導致這些誤解的重要原因。

針對數據文件的壓縮操作是為了將距離文件末尾最近的數據庫頁移到文件的開頭部分。這樣會導致數據文件的末尾部分產生“空白”區域，這些區域可以返還 OS。換句話說，數據文件從物理角度而言變小了。

另一方面，針對事務日志文件的壓縮操作不會移動任何內容，只要事務日志記錄沒有因為任何原因被保留，該操作就只會刪除文件末尾的事務日志的空白區域。如果操作成功，日志文件從物理角度而言會變小。

用戶的困惑主要集中在這兩種操作的副作用以及何時執行上。

用戶有時會被建議（或自行決定）壓縮數據文件以回收空間，這可能是因為其索引維護操作導致數據文件增大，或者其驅動器空間不足，面對這種情況，用戶自然會想到回收這樣的一些“被浪費”的空間。不過，數據文件可能會再次用到這些空間，因此，通常情況下，最好將剩余的空閑空間保留供數據文件使用，而不要重復地壓縮文件并使文件自動增長。

壓縮數據文件的副作用非常嚴重，因此應盡量避免使用此操作。壓縮數據文件會導致大量索引碎片的產生，因此可能會影響查詢的性能。我的博客文章“Why You Should Not Shrink Your Data Files”中提供了一段簡單的腳本來說明這種情況。

我在這篇博客文章中還闡述了何時可以壓縮數據文件（幾乎沒有合適的時間）以及可以避免產生碎片副作用的其他方法。遺憾的是，我見過許多未提及相關的副作用就推薦用戶執行數據文件壓縮的情況。

與壓縮數據文件相比，壓縮日志文件的操作更應該慎之又慎。通常情況下，由于用戶采用的文件大小管理方法不當，導致日志文件過大且與數據文件大小相比極不均衡，因此用戶希望壓縮日志文件，或者是因為用戶看到日志文件變大而希望將其控制在盡可能小的范圍內。主動數據庫的日志文件需要保持合理的大小，但應對日志進行管理，以保證無需對其進行壓縮，并無需使其增大以應對數據庫中的活動。

您可以閱讀我為 2009 年 2 月那一期雜志撰寫的文章“Understanding Logging and Recovery”了解有關事務日志的詳情。我還寫過一篇闡述如何管理事務日志大小的博客文章，請參閱“Importance of Proper Transaction Log Size Management”。

最低要求是盡可能少地進行任何形式的壓縮操作，如果確定采取壓縮操作，應確保完全理解其可能造成的后果。

原文地址

本文來源：微軟TechNet中文站