SQL Server資料庫中的緊急模式

by adonisy 17. 八月 2020 14:14

作 者:楊先民
審 稿:張智凱
 

這篇文章將延續之前的資料庫錯誤一文的內容,來介紹一下一個並沒有在課堂上教的東西,稱為 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錯誤引起的損壞,但可以識別其他問題,例如邏輯一致性錯誤。

這就是為什麼仍然每週運行一次完整掃描很重要的原因。

以上就是本期的主題,希望大家能對一些資料一致性的錯誤能有所了解,其實還是一句話:多備份沒事,沒事多備份。

Tags:

SQL Server資料庫 | 楊先民Adonis Young

不允許評論

NET Magazine國際中文電子雜誌

NET Magazine國際中文電子版雜誌,由恆逸資訊創立於2000,自發刊日起迄今已發行超過500篇.NET相關技術文章,擁有超過40000名註冊讀者群。NET Magazine國際中文電子版雜誌希望藉於電子雜誌與NET Developer達到共同學習與技術新知分享,歡迎每一位對.NET 技術有興趣的朋友們多多支持本雜誌,讓作者群們可以有持續性的動力繼續爬文。<請加入免費訂閱>

月分類Month List