[SQL SERVER][Memo]定期執行 DBCC CHECK?
DBCC CHECK做什麼?
檢查所指定資料庫中所有物件一致性(邏輯和實體完整性)，
DBCC CHECK將對資料庫執行一連串的作業(如下圖)
擷取BOL。
看到一連串的作業，可想而知DBCC CHECK是一個相當繁重又吃系統資源的指令，
繁重和耗費系統資源的程度取決於資料庫物件數量大小、資料量大小..等相關因素成正比，
我下面舉一個簡單例子你會更了解上面我說的，
假設資料庫A大小共500GB，資料量不到1GB，
資料庫B大小共500GB，資料量約480GB，
這兩個資料庫同時執行DBCC CHECK來比較執行時間的話，
絕對可以肯定資料庫A執行時間比較短，
這意味比資料庫B可以更快完成資料庫所有物件邏輯和實體的一致性檢查(不是看資料庫總大小喔)，
看到這裡，我相信很多人會覺得沒事還是別定期執行DBCC CHECK亂搞自己的Server和DB，
當然如果你想密集壓榨Server和DB效能的話就另當別論了...XD，
下面我從災難復原角度來看是否應該定期執行DBCC CHECK，
因為我比較主張定期執行DBCC CHECK，檢查系統資料庫(master、model、msdb)和使用者資料庫。
災難復原看定期執行DBCC CHECK
定期執行DBCC CHECK有助於DBA預先了解目前資料庫是否有那些毀損頁..等，
有點像是定期幫資料庫來個全身健檢(早知道早預防早排除)，
但如果你都沒為資料庫執行過DBCC CHECK的話，
或許那一天很不幸你必須執行災難復原過程，
這時候你才發現資料庫有過多毀損頁...等，
那無疑會是拖慢並影響整個資料庫復原上線時間(可能要好幾個小時檢查修復...你老板應該會很不爽...XD)，
雖然我主張對資料庫定期執行DBCC CHECK，
但凡事也不是那麼絕對，因為影響DBCC CHEKC執行時間的因素太多，
不太可能準確知道何時完成，大多只能估計一個大概時間(下面我會列出一些因素)，
因為這樣導致我之前有些使用者反對我執行這項排程，
就像我前面所說的，凡事沒那麼絕對，
因為使用者可能比我更了解自家系統環境或其他因素，
使用者也許有足夠的理由來反對這樣的定期排程作業，
而大部分讓人擔心的就是DBCC CHECK真正執行完成的時間
(如果上班時間還沒完成，那真不是一個好消息)，
下面我大概列舉幾個影響DBCC CHECK執行時間的相關因素。
1.資料量大小、物件數量大小:
如同我前面所舉的例子，不是看資料庫總大小，而是資料量和物件數量大小，
資料庫中每個物件都需要花時間和資源成本來檢查的，
數量越多當然花的時間也就會越久。
2.tempDB優化設定:
由於DBCC CHECK會使用大量的記憶體來儲存每項作業過程中所檢查資料和物件的一致性結果，
而通常每個作業都會去估計tempDB所需要的空間來存放一些必要資料集結果，
如果tempDB不夠優化，那麼tempDB將會造成DBCC CHECK執行緩慢的主因(I/O 效能對資料庫來說相當重要)。
3.系統負載:
我前面說過，DBCC CHECK是一個相當繁重又吃系統資源的指令，
如果現在系統負載已經相當沉重了，那你又還執行該指令的話，
這將會造成很嚴重的資源爭奪現象，並且DBCC CHECK執行也會奇慢無比，
請依系統環境選擇適當的時間和執行頻率是相當重要的。
4.PHYSICAL_ONLY選項:
雖然BOL寫PHYSICAL_ONLY選項可縮短對大型資料庫執行時間，並且建議你經常使用它，
但我個人不建議災難復原過程中使用該選項，因為有可能會愈搞越糟，我建議執行不使用任何選項。
5.毀損頁數量過多:
如果資料庫被找到的毀損頁數量過多，
有可能會導致DBCC CHECK需要更深入檢查並處理這些資料，
而這些都是導致執行緩慢的因素。
結論:
是否需要定期執行 DBCC CHECK檢查資料庫，
雖然我主張是需要的，但這是在系統資源充足的前提下來討論，
以避免DBCC CHECK越搞越糟。
備註:
看完文章後，如果你正打算定期排程DBCC CHEKC的話，
那你一定不能錯過這訊息，否則執行完DBCC CHECK後，
資料庫的效能將大打折扣(請更新到SQL2005 SP2以後版本)。
參考
