BACKUP WITH CHECKSUM 有效，但 DBCC CHECKDB 檢測到問題

我管理的一台伺服器最近遇到了導致 SSRS 出現問題的斷電ReportServerTempDB。中斷後，執行 Ola 的夜間作業DatabaseIntegriyCheck開始報告問題：

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d Master 
 -Q "EXECUTE [dbo].[DatabaseIntegrityCheck] 
     @Databases = 'USER_DATABASES,SYSTEM_DATABASES', 
     @LogToTable = 'Y'" -b

命令：DBCC CHECKDB (

$$ ReportServerTempDB $$) WITH NO_INFOMSGS、ALL_ERRORMSGS、DATA_PURITY

消息 8979、級別 16、狀態 1、伺服器 XXXXXXX、第 1 行

表錯誤：對象 ID 133575514、索引 ID 1、分區 ID 72057594040156160、分配單元 ID 72057594041466880（行內數據類型）。頁面 (1:130168) 缺少來自父節點（未知）和先前（頁面 (1:123239)）節點的引用。系統目錄中可能存在錯誤的根條目。

消息 8979，級別 16，狀態 1，伺服器 XXXXXXX，第 1 行

表錯誤：對象 ID 133575514，索引 ID 1，分區 ID 72057594040156160，分配單元 ID 72057594041466880（鍵入行內數據）。頁面 (1:130169) 缺少來自父節點（未知）和先前（頁面 (1:123239)）節點的引用。系統目錄中可能存在錯誤的根條目。

消息 8979，級別 16，狀態 1，伺服器 XXXXXXX，第 1 行

表錯誤：對象 ID 133575514，索引 ID 1，分區 ID 72057594040156160，分配單元 ID 72057594041466880（類型行內數據）。頁面 (1:130170) 缺少來自父級的引用（未知…

處理退出程式碼 1。該步驟失敗。

但是，我們的夜間備份作業在每次執行時都繼續報告成功。SSRS 似乎也沒有任何問題。備份作業確實將多個備份命令匯總為一個步驟：

BACKUP DATABASE [ReportServer] TO  DISK = N'C:\Backup-SQLServer\ReportServer.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'ReportServer-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
BACKUP DATABASE [ReportServerTempDB] TO  DISK = N'C:\Backup-SQLServer\ReportServerTempDB.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'ReportServerTempDB-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
BACKUP DATABASE [TEST-PH] TO  DISK = N'C:\Backup-SQLServer\TEST-PH.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'TEST-PH-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

我們備份作業的第二步檢查文件。它每天晚上執行，每次都報告成功：

RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\ReportServer.bak'
GO
RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\ReportServerTempDB.bak'
GO
RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\TEST-PH.bak'
GO

這種情況持續了幾天，直到方便的停機時間。ReportServerTempDB我通過使用中斷前的夜間備份恢復/覆蓋來解決了這個問題。

我們的數據庫PAGE_VERIFY_OPTION設置為CHECKSUM.

什麼場景可以解釋這種行為？

sp_BlitzErik在評論中寫道（已刪除）：

…正在詢問 [關於PAGE_VERIFY_OPTION] 因為這個：Blitz Results: Page Verification Not Optimal。如果您使用正確的CHECKSUM頁面驗證選項，備份選項只會引發錯誤。如果您的數據庫來自舊版本的 SQL Server，它有時可能不是最理想的。

如果頁面在寫入磁碟後損壞，它只會拋出錯誤，即使CHECKSUM頁面驗證選項正在使用該選項。而且我認為他們不一定會因為那篇文章而問這個問題——我猜他們已經將選項設置為。CHECKSUM

當記憶體中發生頁面損壞（由於記憶體錯誤、記憶體亂寫器或 SQL Server 損壞錯誤），然後損壞的頁面使用有效校驗和寫入磁碟時，問題中描述的場景可以並且確實發生。

頁面的後續讀取，包括頁面校驗和的測試，將成功。但是，當DBCC CHECKDB（或不幸的查詢）執行時，損壞將變得明顯。BACKUP在這種情況下， andRESTORE語句是否使用CHECKSUM;並不重要。他們不會發現這種腐敗。

這就是為什麼你不能僅僅依賴於CHECKSUM到處使用而不執行一致性檢查。

希望這有助於解釋你所看到的。

從您發布的錯誤來看，該聚集索引的根頁面似乎以某種方式被破壞了。

引用自：https://dba.stackexchange.com/questions/187566