對于數據庫維護，主要使用DBCC CHECKDB來實現，以下是對大型數據庫的使用說明，小型數據庫一般直接使用就可以了：
1、2008（2005我不確認）已經實現了快照檢查，也就是當你執行DBCC時，DBMS會先快照出一個數據庫，然后在快照上執行檢查，這樣對原來的庫不造成鎖的影響。
2、使用Physical_only選項，可以以較少的開銷檢查數據庫的物理一致性。并且能檢查出會危及用戶數據安全的殘缺頁、校驗和錯誤及常見的硬件故障。所以對于頻繁使用的生產庫，建議使用該選項。，可以極大地縮短對大數據庫運行DBCC CHECKDB的時間。
3、CHECKDB所花費的時間主要取決于：
? a、數據庫自身大??；
? b、當前I/O讀寫能力和繁忙程度；
? c、當前系統CPU負荷；
? d、當前數據庫的并發修改量；
? e、存放tempdb磁盤的速度；
? f、數據庫對象類型：如LOB會花更多時間；
? g、CHECKDB的參數；參數的選擇會影響DBCC所做的事情多少；
? h、數據庫的錯誤類型和錯誤數量；
按照別人的經驗：1T的數據庫如果沒錯誤，checkdb可能要花上20小時。如果一個成百上千的數據庫，哪怕只有2、300G?？赡芤惶於寂懿煌辍?
現在入正題：
如果數據庫設計了分區表機制，做起來會簡單一些，對于存儲歷史數據的分區文件組，由于本身數據不發生變化，可以設為只讀模式，防止任何錯誤修改。每個月左右經行一次DBCC CHECKFILEGROUP即可。對于當前數據，最好一周兩次，單獨做DBCC CHECKFILEGROUP。
如果沒有分區的超大型數據庫，可以參照以下方式：
周一到周三：每天運行一組DBCC CHECKTABLE
周四：DBCC CHECKALLOC+一組DBCC CHECKTABLE
周五周六：每天運行一組DBCC CHECKTABLE?
周日：DBCC CHECKALLOC+DBCC CHECKCATALOG+一組DBCC CHECKTABLE。
對于TB級數據庫可以嘗試使用這個方法。

對于超大型SQL SERVER數據庫執行DBCC操作