損壞恢複提示、資料庫壓縮建議等等

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

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

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

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

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

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

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

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

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

問題：我們的Team Dev打算構建一個採用 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中文站