【轉載】SQL Server 維護

        每個新發布的SQL Server都具有越來越多的自我維護能力，但是“安全比抱歉好得多”的原則仍然是正確的:實際的資料庫管理包含了對系統和使用者資料庫進行的週期性維護，這樣才能在你的使用者發現問題之前把它解決掉。

　　SQL Server 2000中包含了資料庫維護計劃嚮導，它可以為你自動完成所有的維護任務。然而，你需要了解，在現場和你的維護計劃後面，什麼是隱藏的可能給你帶來麻煩的東西。

　　資料庫維護計劃是透過一系列的DBCC命令和系統儲存過程實現的。DBCC的意思是資料庫一致性檢測(database consistency check)或者資料庫控制檯命令(database console command)。有非常多的寫入文件的和沒有寫入文件的DBCC命令，但是隻有一小部分可以用於維護。這裡我將回顧一些與資料庫維護的各個方面相關的DBCC命令和系統儲存過程。

　　通常的資料庫維護時間表都具有如下的活動。點選活動，可以獲得與此相關的DBCC命令和系統儲存過程。

　　1、檢測資料庫一致性和資料的完整性

　　DBCC CHECKDB是最廣泛使用的，檢測資料庫中所有物件的工具。這個語句可以為每一個表和索引檢視，以及文字和影像物件，檢測所有的資料和索引頁面的分配和結構上的完整性。DBCC CHECKDB保證了所有的資料和索引頁面都正確連結，並且指標都是一致的。在指定的資料庫中，使用者和系統表都會被檢測到。DBCC CHECKDB對資料庫中每個物件都都執行DBCC CHECKALLOC和 DBCC CHECKTABLE語句，所以如果你使用DBCC CHECKDB，你就不需要再執行DBCC CHECKALLOC和DBCC CHECKTABLE了。

　　DBCC CHECKDB的某些選項(REPAIR_FAST, REPAIR_REBUILD 和 REPAIR_ALLOW_DATA_LOSS)需要資料庫在單使用者的模式下執行。如果不是單使用者模式的化，語句就失敗了。注意，當使用者連線在上面的時候，不要將資料庫設定成單使用者模式。

　　如果你執行不帶引數的DBCC CHECKDB並且發現錯誤的時候，你應該將你的資料庫設定在單使用者模式，然後嘗試修復這個問題。首先，確保執行那些不會導致資料丟失的語句——REPAIR_FAST 和 REPAIR_REBUILD。如果你還是遇到錯誤，那麼執行DBCC CHECKDB，帶著引數REPAIR_ALLOW_DATA_LOSS。還要確保在顯性事務中關閉語句。如果發生了可接受的資料丟失，你可以提交這個事務。否則，你還可以透過語句來回滾所作的修改。

　　請注意，執行DBCC CHECKDB是一項非常消耗資源的操作。你應該在限制使用者在資料庫伺服器上的活動的時候執行這個語句。

　　DBCC CHECKTABLE與DBCC CHECKDB相同，除了它是在一個單個的表、索引檢視或者即使是一個索引上，而不是在整個資料庫上。

　　DBCC CHECKALLOC檢測某個資料庫的磁碟空間分配結構的一致性。因為DBCC CHECKDB包括了與DBCC CHECKALLOC同樣的檢測，那麼如果執行了CHECKDB的話就沒有必要再執行DBCC CHECKALLOC了。實際上，我們推薦只使用DBCC CHECKALLOC，如果用DBCC CHECKDB或者 DBCC CHECKTABLE會報告說產生分配錯誤的話。

　　DBCC CHECKCONSTRAINTS在某個資料庫中，檢測某些特定的約束或者全部約束的一致性。DBCC CHECKCONSTRAINTS總是在當前資料庫的上下文環境中執行。

　　注意，DBCC CHECKCONSTRAINTS並不進行磁碟或者檔案級別的一致性檢測;它只是確保外來鍵定義的一致性，同時檢測約束——僅僅是確認資料有效。如果你希望檢測磁碟上表和索引的一致性，你應該執行DBCC CHECKDB或者在所有的表上執行DBCC CHECKALLOC和 DBCC CHECKTABLE的組合。

　　首先，為什麼會發生約束違規?當資料庫建立的時候，外來鍵和一致性檢測也許並不存在。開發人員和資料庫管理員也許使用了WITH NOCHECK選項來建立約束，這個選項只能防止約束違規的進一步擴充套件，而不是會檢測已經存在的資料。更進一步的說，透過外來鍵連結的資料可能會過期並且從母表中刪除，但是仍然會留在相關的表中，因為它在下級表中仍然具有相關記錄。

　　DBCC CHECKCATALOG在某個資料庫的系統表內或者之間檢測一致性。很多類似DBCC CHECKCONSTRAINTS的命令都不會檢測頁面分配的一致性;它只是檢測系統表中的資料。DBCC CHECKCATALOG報告錯誤意味著有些人手工從系統表中新增、修改或者刪除記錄了。如果你沒有注意此類活動，那麼你應該看緊你的安全措施了——看看誰具有系統管理員和資料庫主任的全縣，然後評估你的安全策略。

　　2、重建索引

　　當資料行從表中INSERTED, UPDATED and DELETED的時候，索引就產生了碎片。碎片越多，索引的效率越低。資料庫管理員必需確保碎片的級別很低或者根本不存在。碎片級別可以透過在某個索引上執行DBCC SHOWCONTIG語句來找到。

　　這裡有三種方法可以去掉碎片:

　　1、 使用CREATE INDEX……WITH DROP EXISTING語句來刪除並重新建立索引

　　2、 執行DBCC DBREINDEX

　　3、 執行DBCC INDEXDEFRAG

　　DBCC DBREINDEX重新構建一個特定的索引或者某個特定的表上的所有的索引。這個語句允許強制PRIMARY KEY和UNIQUE約束的索引重新構建，而不需要刪除約束。你不需要知道索引的類別和名稱，你同樣可以使用。使用DBCC DBREINDEX比單獨為表上的每個索引編寫DROP INDEX 和CREATE INDEX語句簡單。時刻記住，重新構建聚簇索引也會引起非聚簇索引的重建。

　　DBCC INDEXDEFRAG可以刪除某個聚簇索引或者非聚簇索引的碎片。與DBCC DBREINDEX不同，這個語句需要指定某個特別的索引，並且不能執行在表上所有索引上。刪除碎片也是一項線上操作，因此不會妨礙使用者對錶進行操作。DBCC INDEXDEFRAG給系統增加了額外的負擔，因為它產生了額外的I/O負擔。它還會影響到索引頁面，並且會在壓縮之後刪除所有遺留的沒有資料的頁面。

　　刪除碎片的頻率依賴於在你的資料庫中，資料修改的級別。需要每天處理幾百萬個事務的系統應該至少每個星期都進行一次索引重建。另一方面，在幾乎沒有修改的資料庫上，即使你每個月進行一次索引重建，資料庫都會執行得不錯。

　　2、重建索引

　　當資料行從表中INSERTED, UPDATED and DELETED的時候，索引就產生了碎片。碎片越多，索引的效率越低。資料庫管理員必需確保碎片的級別很低或者根本不存在。碎片級別可以透過在某個索引上執行DBCC SHOWCONTIG語句來找到。

　　這裡有三種方法可以去掉碎片:

　　1、 使用CREATE INDEX……WITH DROP EXISTING語句來刪除並重新建立索引

　　2、 執行DBCC DBREINDEX

　　3、 執行DBCC INDEXDEFRAG

　　DBCC DBREINDEX重新構建一個特定的索引或者某個特定的表上的所有的索引。這個語句允許強制PRIMARY KEY和UNIQUE約束的索引重新構建，而不需要刪除約束。你不需要知道索引的類別和名稱，你同樣可以使用。使用DBCC DBREINDEX比單獨為表上的每個索引編寫DROP INDEX 和CREATE INDEX語句簡單。時刻記住，重新構建聚簇索引也會引起非聚簇索引的重建。

　　DBCC INDEXDEFRAG可以刪除某個聚簇索引或者非聚簇索引的碎片。與DBCC DBREINDEX不同，這個語句需要指定某個特別的索引，並且不能執行在表上所有索引上。刪除碎片也是一項線上操作，因此不會妨礙使用者對錶進行操作。DBCC INDEXDEFRAG給系統增加了額外的負擔，因為它產生了額外的I/O負擔。它還會影響到索引頁面，並且會在壓縮之後刪除所有遺留的沒有資料的頁面。

　　刪除碎片的頻率依賴於在你的資料庫中，資料修改的級別。需要每天處理幾百萬個事務的系統應該至少每個星期都進行一次索引重建。另一方面，在幾乎沒有修改的資料庫上，即使你每個月進行一次索引重建，資料庫都會執行得不錯。