DBCC CHECKDB 和 DBCC CHECKTABLE 之間的表級完整性檢查有什麼具體區別嗎？
在我們的一個數據庫上執行 DBCC CHECKDB 時，我遇到了分配錯誤。它拋出下面提到的錯誤：
消息 8947，級別 16，狀態 1，第 5 行表錯誤：對象 ID 1277199566、索引 ID 1、分區 ID 72057717676669456、分配單元 ID 72057708766647328（LOB 數據類型）的多個 IAM 頁包含相同間隔的分配。IAM 頁面 (1:425664) 和 (1:1422669)。
CHECKDB 在表“schemaName.tableName”（對象 ID 1277199566）中發現 1 個分配錯誤和 0 個一致性錯誤。CHECKDB 在數據庫“databaseName”中發現 1 個分配錯誤和 0 個一致性錯誤。
奇怪的是，當我試圖在這個表上執行 DBCC CHECKTABLE 時，它沒有顯示任何錯誤。此外，我嘗試執行 CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS 選項，但沒有收到任何錯誤。
根據 Microsoft 文件：
要對數據庫中的每個表執行 DBCC CHECKTABLE，請使用 DBCC CHECKDB。
對於指定的表，DBCC CHECKTABLE 檢查以下內容：
- 索引、行內、LOB 和行溢出數據頁已正確連結。
- 索引的排序順序正確。
- 指針是一致的。
- 每頁上的數據都是合理的，包括計算列。
- 頁面偏移是合理的。
- 基表中的每一行在每個非聚集索引中都有一個匹配的行，反之亦然。
- 分區表或索引中的每一行都在正確的分區中。
- 使用 FILESTREAM 在文件系統中儲存 varbinary(max) 數據時文件系統和表之間的連結級一致性
但正如我所見，相反的情況並非如此。我們不能只為一張表執行 CHECKTABLE 並為同一張表獲得相同的結果。
在檢查特定對象的完整性和一致性方面，是否有人知道與這兩個命令之間的差異相關的資訊？
通過執行以下操作檢查指定數據庫中所有對象的邏輯和物理完整性：
- 在數據庫上執行DBCC CHECKALLOC 。
- 對數據庫中的每個表和視圖執行DBCC CHECKTABLE。
- 在數據庫上執行DBCC CHECKCATALOG 。
- 驗證數據庫中每個索引視圖的內容。
- 使用 FILESTREAM 在文件系統中儲存 varbinary(max) 數據時，驗證表元數據與文件系統目錄和文件之間的連結級別一致性。
- 驗證數據庫中的 Service Broker 數據。
跑步
DBCC CHECKTABLE只是這些步驟之一。要查看分配錯誤，您需要執行
DBCC CHECKALLOC.
DBCC CHECKTABLE確實對屬於該對象的頁面執行了廣泛的檢查。它不檢查可能以不一致的方式引用表的數據庫範圍的分配元數據。DBCC CHECKALLOC執行這些檢查。