Sql-Server

SQL Server 範例數據庫 WideWorldImporters 失敗 dbcc checkdb

  • February 17, 2022

問題陳述

我剛剛dbcc checkdb在範例 WideWorldImporters 數據庫上執行。我收到了 (4) 個關於統計數據損壞的錯誤,我不記得過去在執行此命令時看到過這些錯誤。雖然這只是一個範例數據庫,但我很好奇,因為我不想在真實數據庫中看到類似的錯誤。

SSMS 和 Windows 版本

SSMS:18.10 (15.0.18390.0) / Windows 10:版本 21H1(作業系統內部版本 19043.1526)

SQL Server 開發人員版本

Microsoft SQL Server 2019 (RTM-CU13) (KB5005679) - 15.0.4178.1 (X64) 2021 年 9 月 23 日 16:47:49 版權所有 (C) 2019 Microsoft Corporation Developer Edition (64-bit) o​​n Windows 10 Pro 10.0 (建構 19043:)

SSMS 中發出的命令:

dbcc checkdb ([WideWorldImporters]) with all_errormsgs, data_purity, extended_logical_checks , no_infomsgs;  
go

錯誤資訊

消息 9122,級別 16,狀態 201,第 10 行

統計資訊“sys.TT_OrderIDList_22AA2996.PK__TT_Order__C3905BAE80B57D6F”已損壞。

消息 9122,級別 16,狀態 201,第 10 行

統計資訊“sys.TT_OrderLineList_24927208.IX_Website_OrderLineList”已損壞。

消息 9122,級別 16,狀態 201,第 10 行

統計資訊“sys.TT_OrderList_25869641.PK__TT_Order__288FD689F5006DE2”已損壞。

消息 9122,級別 16,狀態 201,第 10 行

統計資訊“sys.TT_SensorDataList_276EDEB3.PK__TT_Senso__88385F3043E9E8D9”已損壞。

CHECKDB 在數據庫“WideWorldImporters”中發現 0 個分配錯誤和 4 個一致性錯誤。

我嘗試修復

我很快了解到我沒有刪除 sys.* 索引所需的權限。我嘗試從上次備份中恢復數據庫,但這產生了完全相同的錯誤消息。

接下來,我打開這個網頁下載一個新的副本:

https ://github.com/Microsoft/sql-server-samples/releases/tag/wide-world-importers-v1.0

我下載了“WideWorldImporters-Full.bak”(121 MB),清除了屬性中的“Mark of the Web”(MOTW),並成功恢復了數據庫。但是,在執行上面顯示的相同 dbcc checkdb 命令時,我收到了完全相同的錯誤!

最後,我下載了“WideWorldImporters-Full.bacpac”(59.1 MB),清除了屬性中的“Mark of the Web”(MOTW),成功恢復了數據庫。這也導致了dbcc checkdb上面顯示的相同錯誤。

我顯然不記得曾經收到過這些錯誤,這讓我想知道在我目前版本的 Windows、SSMS 或 SQL Developer 中是否存在導致這些錯誤的“問題”?

謝謝你

錯誤消息有點誤導。並不是與主鍵索引相關的統計對象損壞了;相反,DBCC 檢查統計數據損壞在EXTENDED_LOGICAL_CHECKS指定時遇到斷言失敗,並且程式碼嘗試獲取 Hekaton 表類型索引的索引大小。EXTENDED_LOGICAL_CHECKS如果未指定,這些對象將作為不受支持而跳過。

當然,這是一個只有 Microsoft 才能修復的錯誤,而且我確實意識到這不是真實數據庫的問題。儘管如此,明顯的解決方法是跳過EXTENDED_LOGICAL_CHECKS.

如果不希望這樣做,也可以通過在DBCC CHECKDB語句執行時暫時禁用 Hekaton 對象的自動統計更新來跳過有問題的檢查。沒有記錄的方法可以做到這一點,但全域跟踪標誌 9823 確實執行了該功能:

DBCC TRACEON (9823, -1);

DBCC CHECKDB (WideWorldImporters) 
WITH 
   ALL_ERRORMSGS, 
   DATA_PURITY, 
   EXTENDED_LOGICAL_CHECKS, 
   NO_INFOMSGS;  

DBCC TRACEOFF (9823, -1);

如果您沒有 Microsoft 支持協議,或者不想完成該過程,您可以在http://aka.ms/sqlfeedback留下回饋。

我可以在 2019 CU15 Developer Edition 上重現您的問題。我最初安裝了 2019 RTM,並且 dbcc 恢復正常。

做一些調查,看起來這些統計資訊與使用者定義的表類型相關聯。我嘗試僅刪除/重新創建 UDT 並遇到了同樣的問題。只有在從 UDT 中刪除記憶體優化屬性(並相應地更改相關過程)時,checkdb 才恢復乾淨。

我建議向 MS 提出問題並將它們指向他們自己的範例數據庫。希望這可以縮短他們方面的故障排除過程。😀

引用自:https://dba.stackexchange.com/questions/307609