此文章主要向大家講述的是正確維護SQL Server保駕護航的實際操作步驟，我前兩天在相關網站看見正確維護SQL Server保駕護航的實際操作步驟的資料，覺得挺好，就拿出來供大家分享。

SQL S

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

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

數據庫維護計劃是通過一系列的DBCC命令和系統存儲過程實現的。DBCC的意思是數據庫一致性檢測(database consistency check)或者數據庫控制臺命令(database console command)。有非常多的寫入文檔的和沒有寫入文檔的DBCC命令，但是只有一小部分可以用于維護SQL Server保駕護航。這里我將回顧一些與數據庫維護SQL Server保駕護航的各個方面相關的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負擔。它還會影響到索引頁面，并且會在壓縮之后刪除所有遺留的沒有數據的頁面。

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

3、更新統計數字

統計數據中包含了表中某個索引或者字段的數值分布的信息。你可以通過使用CREATE STATISTICS語句或者使用sp_createstatistics系統過程來創建統計數字。統計數字檢索有關索引是否具有良好或者糟糕的選擇性的信息，索引的選擇性可以用來判斷索引的效率是否足以滿足查詢的要求。當你創建索引的時候，SQL Serve保駕護航r自動創建統計數字。此外，SQL Server還為那些沒有定義索引的字段創建統計數字。

針對某個索引的統計數字可以通過使用DBCC SHOW_STATISTIC0S語句來查看。當數據發生改變的時候，統計數字就過時了。當選擇索引來滿足查詢的時候，陳舊的統計數字會讓SQL Server作出次優化的決定。

默認情況下，SQL Server 2000自動更新每個表上的統計數字。然而，在某些情況下，關閉統計數字的自動更新是有意義的。例如，我們假設你有某種類型的批處理例程，每個周末，系統具有最小利用率的時候，都會向你的表中添加上百萬行數據。統計數字的自動更新只會降低你的批處理過程，而不會為系統帶來任何好處。除了你可以在周末關閉自動更新，然后在每個周一早上首先更新統計數字之外，你還可以啟用或者禁用統計數字的自動更新，通過使用sp_autostats過程。

如果你想要為單個的表或者索引更新統計數字，你可以使用UPDATE STATISTICS命令。或者你還可以執行sp_updatestats系統過程來更新當前數據庫中所有表上的統計數字。

4、報告數據和日志文件中的空間利用率

也許你被要求擴展或者縮減一個數據文件或者事務日志文件的尺寸，那么這時候就可以使用DBCC SHRINKDATABASE 或者 DBCC SHRINKFILE命令了。

Sysindexes表在經過一段時間之后會變得不準確，特別是在增長頻繁并且/或者縮減頻繁的數據庫中。DBCC UPDATEUSAGE命令報告并且糾正sysindexes表中不準確的數字。如果你認為你的數據庫或者表的尺寸與sp_spaceused系統過程中報告的數字不符的話，那么你就應該使用這個語句。

每次在你使用DBCC SHRINKDATABASE 或者 DBCC SHRINKFILE縮減數據庫文件之后，都執行DBCC UPDATEUSAGE，或者只是作為一個周期性的維護SQL Server保駕護航計劃，都是個好主意。

【編輯推薦】

1. SQL Server數據轉換服務利用與導入式格式的描述
2. SQL Server數據庫的妙招用法
3. SQL Server性能進行提高的4項技術概述
4. SQL Server數據庫修復用SQL語句，很簡單！
5. SQL Server數據轉換服務的妙用之導入導出數據