共計 3056 個字符，預計需要花費 8 分鐘才能閱讀完成。
本篇內容介紹了“sqlserver 關于 DBCC CHECKDB 的知識點有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
通過執行下列操作檢查指定數據庫中所有對象的邏輯和物理完整性：
對數據庫運行 DBCC CHECKALLOC。
對數據庫中的每個表和視圖運行 DBCC CHECKTABLE。
對數據庫運行 DBCC CHECKCATALOG。
驗證數據庫中每個索引視圖的內容。
使用 FILESTREAM 在文件系統中存儲 varbinary(max) 數據時，驗證表元數據和文件系統目錄和文件之間的鏈接級一致性。
驗證數據庫中的 Service Broker 數據。
DBCC CHECKDB 其實主要做兩件事情：
檢查數據庫里有沒有損壞發生 (不檢查禁用的索引)
盡力修復數據庫損壞，使數據庫能夠被重新正常訪問。
DBCC CHECKDB 最佳實踐
建議對生產系統頻繁使用 PHYSICAL_ONLY 選項。使用 PHYSICAL_ONLY 可以極大地縮短對大型數據庫運行 DBCC CHECKDB 的運行時間。同時建議您定期運行沒有選項的 DBCC CHECKDB。應當以什么頻率執行這些運行任務將取決于各個企業及其生產環境。
DBCC CHECKDB 修復參數
示例：DBCC CHECKDB (db_name , REPAIR_FAST);
1. REPAIR_ALLOW_DATA_LOSS 嘗試修復報告的所有錯誤。這些修復可能會導致一些數據丟失。
2. REPAIR_FAST 保留該語法只是為了向后兼容。未執行修復操作。
3. REPAIR_REBUILD，執行不會丟失數據的修復。這包括快速修復（如修復非聚集索引中缺少的行）以及更耗時的修復（如重新生成索引）。此參數不修復涉及 FILESTREAM 數據的錯誤。
DBCC CHECKDB 是否加鎖
DBCC CHECKDB 默認不加鎖而是工作在一個隱藏的數據庫快照，執行 DBCC CheckDB 時指定了 TABLOCK 選項才會加鎖
DBCC CHECKDB 參數說明
ALL_ERRORMSGS：顯示針對每個對象報告的所有錯誤。默認情況下顯示所有錯誤消息。
EXTENDED_LOGICAL_CHECKS：如果兼容性級別為 100 (SQL Server 2008) 或更高，則對索引視圖、XML 索引和空間索引（如果存在）執行邏輯一致性檢查。
NO_INFOMSGS：取消顯示所有信息性消息。
NOINDEX：指定不應對用戶表的非聚集索引執行會占用很大系統開銷的檢查。這將減少總執行時間。NOINDEX 不影響系統表，因為總是對系統表索引執行完整性檢查。
PHYSICAL_ONLY：將檢查限制為頁和記錄標頭的物理結構完整性以及數據庫的分配一致性。設計該檢查是為了以較小的開銷檢查數據庫的物理一致性，但它還可以檢測會危及用戶數據安全的殘缺頁、校驗和錯誤以及常見的硬件故障。因此，使用 PHYSICAL_ONLY 選項可能會大幅減少對較大數據庫運行 DBCC CHECKDB 所需的時間，所以對需要頻繁檢查的生產系統，建議使用此選項。我們仍然建議完整地定期執行 DBCC CHECKDB。
ESTIMATEONLY：顯示運行包含所有其他指定選項的 DBCC CHECKDB 時所需的 tempdb 空間估計量。不執行實際數據庫檢查。
DATA_PURITY：使 DBCC CHECKDB 檢查數據庫中是否存在無效或越界的列值。
TABLOCK：使 DBCC CHECKDB 獲取鎖，而不使用內部數據庫快照。這包括一個短期數據庫排他 (X) 鎖。TABLOCK 可使 DBCC CHECKDB 在負荷較重的數據庫上運行得更快，但 DBCC CHECKDB 運行時會減少數據庫上可獲得的并發性。
DBCC
CHECKDB 錯誤消息
DBCC CHECKDB 命令結束之后，便會將一個消息寫入 SQL Server 錯誤日志。如果 DBCC 命令成功執行，則消息指示成功以及命令的運行時間。如果 DBCC 命令在完成檢查之前由于錯誤而停止，則消息將指示命令已終止，并指示狀態值和命令運行的時間。下表列出并說明了此消息中可包含的狀態值。
State
描述
0
出現錯誤號 8930。這表示元數據中存在的損壞終止了 DBCC 命令。
1
出現錯誤號 8967。存在一個內部 DBCC 錯誤。
2
在緊急模式數據庫修復過程中出錯。
3
這表示元數據中存在的損壞終止了 DBCC 命令。
4
檢測到斷言或訪問違規。
5
出現終止了 DBCC 命令的未知錯誤
sp_MSforeachDB
sp_MSforeachdb 是微軟提供的不公開的存儲過程，存儲在 master 數據庫中。可以用來對某個數據庫的所有表或某個 SQL 服務器上的所有數據庫進行管理，下面將對此進行詳細介紹。
sp_MSforeachDB 使用 DBCC CHECKDB 的示例：
use master
exec sp_MSforeachDB DBCC CHECKDB ([?]) WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY,NO_INFOMSGS
其中? 表示通配符，表示所有數據庫
DBCC CHECKDB 遇到的一些錯誤及分析
1、There is insufficient memory available in the buffer pool. [SQLSTATE 42000] (Error 802) During undoing of a logged operation in database HistoryDB , an error occurred at log record ID (5106285:51843537:99). Typically, the specific failure is logged previously as an error in the operating system error log. Restore the database or file from a backup, or repair the database. [SQLSTATE 42000] (Error 3314) A database snapshot cannot be created because it failed to start.
原因分析：報錯很明顯：緩沖池中沒有足夠的可用內存。檢查是否數據庫 HistoryDB 特別大導致，如果是則在 DBCC CHECKDB 時加上 PHYSICAL_ONLY 選項
2、Object ID 34 (object sys.sysschobjs): DBCC could not obtain a lock on this object because the lock request timeout period was exceeded. This object has been skipped and will not be processed.
原因分析：當我看到這個錯誤時，我問自己一個問題:“DBCC CHECKDB 執行鎖嗎?”答案是否定的。從 SQL Server 2005 開始，DBCC CheckDB 工作在一個隱藏的數據庫快照上。數據庫快照是數據庫的只讀副本。由于快照 I / O 開銷，您可以看到服務器上出現了一些阻塞，或者用戶速度較慢，但肯定沒有鎖。這個時候要檢查自己的 DBCC CHECKDB 是否加了 TABLOCK 選項，如果是則取消 TABLOCK 選項
“sqlserver 關于 DBCC CHECKDB 的知識點有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！
