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