摘要:[SQL SERVER] 基礎 DBCC CHECKDB 在做什麼、要花多久時間、大型資料庫執行CHECKDB方法

DBCC CHECKDB在做什麼，檢查指定資料庫中所有物件的完整性

檢查相關系統表

執行DBCC CHECKALLOC (檢查資料庫所有頁面分配)

執行DBCC CHECKTABLE (

執行DBCC CHECKCATALOG

驗證索引檢視內容

驗證Service Broker資料

執行CHECKDB要花多久時間，跟下面因素有關

資料庫本身大小

磁碟IO能力 (checkdb需要把資料庫從頭到尾讀一次，故IO速度是最重要的因素)

CPU目前的負荷、平行處理度 (checkdb本身需要CPU做驗證工作)

tempdb磁碟速度 (需把暫存資料存放在記憶體或tempdb上)

資料庫內物件類型 (LOB、XML、computed column等等驗證需更多時間)

使用的參數 (with physical_only可以只做實體結構完整性檢查)

錯誤數量 (錯誤的數量越多，時間花費越久)

實際案例，花費時間參考

1. 約80G (SSD,48core)資料庫，約8分鐘完成

2. 約40G (一般硬碟,16core)舊資料庫，跑約30分鐘....

所以CHECKDB每台機器時間跟資料庫內容差異，各會不同，可以用以下語法估計時間

雖然不太精確，但也有一個估算時間

SELECT session_id, percent_complete, estimated_completion_time,

DATEADD(ms,estimated_completion_time,GETDATE()) AS EstimatedEndTime,

start_time, status, command

FROM sys.dm_exec_requests

WHERE command like '%DBCC%'

大型資料庫如何執行CHECKDB

如果資料庫大到執行一次CHECKDB成本太高，時間太久

可以考慮將CHECKDB工作內容 (CHECKTABLE , CHECKALLOC , CHECKCATALOG ) 分段執行

每日分批執行DBCC CHECKTABLE，周六周日執行DBCC CHECKALLOC , DBCC CHECKCATALOG

DBCC CHECKDB修復參數

預設DBCC CHECKDB只會驗證資料庫是否完好，不會主動去做資料庫修復動作，若要修復資料庫

需要將資料庫設為單人使用者模式，才能使用以下三個修復參數

REPAIR_ALLOW_DATA_LOSS (嘗試修復所有錯誤，可能會導致一些資料遺失)

REPAIR_FAST (保留該語法只為了向後相容，並未執行任何修復，請不要使用)

REPAIR_REBUILD (執行此修復不會有遺失資料危險)

MSDN官方文件

重要事項

最好不要使用這些 REPAIR 選項。 若要修復錯誤，我們建議您從備份中還原。 修復作業並不考慮資料表或資料表之間的任何條件約束。 如果指定的資料表涉及一或多項條件約束，建議您在修復作業之後，執行 DBCC CHECKCONSTRAINTS。 如果您必須使用 REPAIR，請執行不含修復選項的 DBCC CHECKDB 來尋找要使用的修復層級。 如果您使用 REPAIR_ALLOW_DATA_LOSS 層級，建議您在搭配這個選項執行 DBCC CHECKDB 之前，先備份資料庫。

https://msdn.microsoft.com/zh-tw/library/ms176064(v=sql.120).aspx

參考書籍: 王者歸來SQL SERVER2012實戰指南