作 者：楊先民
審 稿：張智凱
這篇文章將延續之前的資料庫錯誤一文的內容，來介紹一下一個並沒有在課堂上教的東西，稱為 Emergency Mode(緊急模式)的介紹，並且介紹一些和檢查資料一致性的 DBCC的指令。
Emergency Mode
如果即使使用REPAIR_ALLOW_DATA_LOSS選項，資料庫文件被損壞到無法連線和不可恢復的程度，並且您沒有可用的備份，那麼您的最後選擇是使用REPAIR_ALLOW_DATA_LOSS選項在
緊急模式下運行DBCC CHECKDB。
請記住，緊急模式是修復資料庫的不得已的選擇，如果無法通過此模式連線數據庫，則將無法通過任何其他方式訪問它們。當您在緊急模式下對資料庫執行此操作時，
DBCC CHECKDB會將由於損壞而無法訪問的頁面視為沒有錯誤，以嘗試恢復資料。
此操作還可以備份由於日誌損壞而無法連線的資料庫。這是因為即使遇到錯誤，它也會嘗試強制恢復交易日誌。如果失敗的話，它會重建交易日誌。
當然，這可能會導致交易不一致，但是如上所述，這是不得已的選擇。例如，我們將刪除操作系統中範例資料庫的交易日誌文件。通過執行下面的查詢，可以找到交易日誌文件的
操作系統位置。
SELECT physical_name FROM sys.master_files WHERE database_id = DB_ID('sampleDB') AND type_desc = 'Log' ;
由於資料和交易日誌文件已被SQL Server程式鎖定，因此我們首先需要停止 SQL Server。再次啟動 SQL Server後，我們可以看到資料庫已標記為Recovery Pending，如下圖：
由於沒有可用於該資料庫的備份，因此，我們唯一的選擇是在緊急模式下使用DBCC CHECKDB。下面的程式將資料庫置於緊急模式，然後將DBCC CHECKDB與REPAIR_ALLOW_DATA_LOSS
選項一起使用來修復錯誤。
ALTER DATABASE DBName SET EMERGENCY ; GO
ALTER DATABASE DBName SET SINGLE_USER ;
DBCC CHECKDB ('DBName',REPAIR_ALLOW_DATA_LOSS) ; GO
ALTER DATABASE Chapter9 SET MULTI_USER ; GO
如下圖示，部分結果表示 SQL Server 能夠通過重建交易日誌使資料庫庫連線。但是，這也表明這意味著交易日誌的一致性已經遺失並且恢復鏈已斷開。
由於失去了交易日誌的一致性，因此我們現在應該運行 DBCC CHECKCONSTRAINTS來查找 FK 條件約束和 CHECK 條件約束中的錯誤。 DBCC CHECKCONSTRAINTS將在之後介紹。
有關其他的 DBCC指令對於一致性相關的
下面有幾個和一致性有關的 DBCC指令(除了 DBCC CHECKDB之外的)，稍微來介紹一下：
DBCC CHECKCATALOG
在 SQL Server中，系統目錄是元資料的集合，這些元資料描述了資料庫及其中保存的數據。運行 DBCC CHECKCATALOG時，它將對此目錄執行一致性檢查。該命令作為DBCC CHECKDB
的一部分運行，但也可以單獨作為命令運行。當單獨運行時，它接受與DBCC CHECKDB相同的參數，但PHYSICAL_ONLY和DATA_PURITY除外，該參數對此命令不可用。
DBCC CHECKALLOC
DBCC CHECKALLOC 對資料庫中的磁碟分配結構執行一致性檢查。它作為 DBCC CHECKDB 的一部分運行，但也可以單獨作為命令運行。當單獨運行時，它接受許多與 DBCC CHECKDB相同的參數，但PHYSICAL_ONLY，DATA_PURITY和REPAIR_REBUILD對此參數不可用。輸出是按表，索引和分區。
DBCC CHECKTABLE
作為DBCC CHECKDB的一部分，對資料庫中的每個表和索引檢視表運行DBCC CHECKTABLE。但是，它也可以單獨針對特定的表和該表的索引作為單獨的命令運行。
它針對該特定表執行一致性檢查，如果有索引檢視表引用該表，它還將執行跨表一致性檢查。它接受與DBCC CHECKDB相同的參數，但與此同時，您還需要指定要檢查的表的名稱或ID。
DBCC CHECKFILEGROUP
DBCC CHECKFILEGROUP對指定檔案群組內的系統目錄，分配結構，表和索引檢視執行一致性檢查。但是，當表具有儲存在不同檔案群組中的索引時，對此有一些限制。
在這種情況下，不檢查索引的一致性。如果是要檢查的檔案群組中儲存的索引，但是相應的基本資料表位於其他檔案群組上，則仍然適用。
如果您有一個分區表，該分區表儲存在多個檔案組上，則DBCC CHECKFILEGROUP僅檢查儲存在要檢查的檔案群組上的分區的一致性。
DBCC CHECKIDENT
DBCC CHECKIDENT掃描指定表中的所有行，以在IDENTITY列中找到最大值。然後檢查以確保儲存在資料表元資料中的下一個IDENTITY值高於表的IDENTITY列中的最大值。
DBCC CHECKIDENT嚴格講起來和一致性沒什麼關係，這個和資料表中是否有自動編號，也就是 identity的設定有關係，它可以顯示最大值之外，最重要的是還可以 RESEED，也就是
讓種子數歸0之類的。
DBCC CHECKCONSTRAINTS
DBCC CHECKCONSTRAINTS可以檢查特定外鍵的完整性或檢查表中的條件約束，檢查單個表中的所有條件約束，或檢查表中的所有條件約束。
DBCC CHECKDB with PHYSICAL_ONLY
您可以採用的一種策略是使用 PHYSICAL_ONLY選項定期（最好在每晚）執行DBCC CHECKDB，然後定期但不經常（最好每週一次）運行一次完整檢查。當使用PHYSICAL_ONLY選項執行DBCC CHECKDB時，將對系統目錄和分配結構進行一致性檢查，並對每個表的每一頁進行掃描和驗證。最終結果是，可以捕獲由IO錯誤引起的損壞，但可以識別其他問題，例如邏輯一致性錯誤。
這就是為什麼仍然每週運行一次完整掃描很重要的原因。
以上就是本期的主題，希望大家能對一些資料一致性的錯誤能有所了解，其實還是一句話：多備份沒事，沒事多備份。
訂閱