DBCC CHECKDB 算是管理員們最常用的命令也是必須要知道的命令了。定期的檢查及問題的修復都是比較重要的！！下面介紹一下 DBCC CHECKDB 的一些基本用法。
DBCC CHECKDB 完成兩項任務：
- 檢查數據庫里有沒有損壞發生。
- 盡力修復數據庫損壞，使數據庫能夠被重新正常訪問。
DBCC CHECK 做了些什么：
- 檢查一些關鍵的系統表
- 對數據庫運行DBCC CHECKALLOC
- 對數據庫運行DBCC CHECKCATALOG
- 驗證數據庫中每個索引視圖的內容
- 驗證數據庫中service broker數據
DBCC CHECKDB提供的修復方法
- Repair_allow_data_loss ：嘗試修復所有錯誤（可能導致一些數據丟失，一般無發從備份恢復才使用）
- Repair_fast 未執行任何修復
- Repair_rebuild ：執行次要、快速修復（如：修復非聚集索引中的額外鍵）及耗時修復（如：重新生成索引），這些修復不會造成數據丟失。
注意：使用Repair_allow_data_loss參數導致的數據丟失也許是不能接受的，一般從備份還原的數據丟失可以做到心里有數，可以通過查詢丟失前數據條數與修復后數據條數進行對比知道丟了多少數據。另外在早期備份中嘗試找回。
如果使用repair_allow_data_loss級別都不能恢復：
- 按照預先備份恢復
- 如果損壞發生在默寫用戶對象（表、視圖、存儲過程等），可以把它們DROP掉
- 將數據庫設置成緊急只讀模式，用select into 將數據導入一個新建的空庫。挽救盡可能多的數據，但是損壞嚴重程度不一樣，丟失的數據多少也不一樣。這樣挽救回來的數據庫各個數據表的狀態將不一致，一般在邏輯上或有很大的問題。
雖然sqlserver 對dbcc checkdb 做了一些優化但是對於較大的數據庫還是不小的負擔所以分時間段進行不同的check檢查以分散一次check的影響。還可以通過下面兩個參數減輕一些消耗負擔
- With noindex : 不對非聚集索引檢查。
- With physical_only：只做物理結構完整性檢查。
數據庫損壞確實讓人頭疼，但出現問題耐心處理並積累處理手法還是很重要的！損壞的修復處理我也是新手仍然需要多多積累！