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

SQL S

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

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

數(shù)據(jù)庫維護計劃是通過一系列的DBCC命令和系統(tǒng)存儲過程實現(xiàn)的。DBCC的意思是數(shù)據(jù)庫一致性檢測(database consistency check)或者數(shù)據(jù)庫控制臺命令(database console command)。有非常多的寫入文檔的和沒有寫入文檔的DBCC命令，但是只有一小部分可以用于維護SQL Server保駕護航。這里我將回顧一些與數(shù)據(jù)庫維護SQL Server保駕護航的各個方面相關的DBCC命令和系統(tǒng)存儲過程。

通常的數(shù)據(jù)庫維護時間表都具有如下的活動。點擊活動，可以獲得與此相關的DBCC命令和系統(tǒng)存儲過程。

1、檢測數(shù)據(jù)庫一致性和數(shù)據(jù)的完整性

DBCC CHECKDB是最廣泛使用的，檢測數(shù)據(jù)庫中所有對象的工具。這個語句可以為每一個表和索引視圖，以及文本和圖像對象，檢測所有的數(shù)據(jù)和索引頁面的分配和結構上的完整性。DBCC CHECKDB保證了所有的數(shù)據(jù)和索引頁面都正確鏈接，并且指針都是一致的。在指定的數(shù)據(jù)庫中，用戶和系統(tǒng)表都會被檢測到。DBCC CHECKDB對數(shù)據(jù)庫中每個對象都都執(zhí)行DBCC CHECKALLOC和 DBCC CHECKTABLE語句，所以如果你使用DBCC CHECKDB，你就不需要再執(zhí)行DBCC CHECKALLOC和DBCC CHECKTABLE了。

DBCC CHECKDB的某些選項(REPAIR_FAST, REPAIR_REBUILD 和 REPAIR_ALLOW_DATA_LOSS)需要數(shù)據(jù)庫在單用戶的模式下運行。如果不是單用戶模式的化，語句就失敗了。注意，當用戶連接在上面的時候，不要將數(shù)據(jù)庫設置成單用戶模式。

如果你執(zhí)行不帶參數(shù)的DBCC CHECKDB并且發(fā)現(xiàn)錯誤的時候，你應該將你的數(shù)據(jù)庫設置在單用戶模式，然后嘗試修復這個問題。首先，確保執(zhí)行那些不會導致數(shù)據(jù)丟失的語句——REPAIR_FAST 和 REPAIR_REBUILD。如果你還是遇到錯誤，那么執(zhí)行DBCC CHECKDB，帶著參數(shù)REPAIR_ALLOW_DATA_LOSS。還要確保在顯性事務中關閉語句。如果發(fā)生了可接受的數(shù)據(jù)丟失，你可以提交這個事務。否則，你還可以通過語句來回滾所作的修改。

請注意，運行DBCC CHECKDB是一項非常消耗資源的操作。你應該在限制用戶在數(shù)據(jù)庫服務器上的活動的時候運行這個語句。

DBCC CHECKTABLE與DBCC CHECKDB相同，除了它是在一個單個的表、索引視圖或者即使是一個索引上，而不是在整個數(shù)據(jù)庫上。

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

DBCC CHECKCONSTRAINTS在某個數(shù)據(jù)庫中，檢測某些特定的約束或者全部約束的一致性。DBCC CHECKCONSTRAINTS總是在當前數(shù)據(jù)庫的上下文環(huán)境中執(zhí)行。

注意，DBCC CHECKCONSTRAINTS并不進行磁盤或者文件級別的一致性檢測;它只是確保外鍵定義的一致性，同時檢測約束——僅僅是確認數(shù)據(jù)有效。如果你希望檢測磁盤上表和索引的一致性，你應該執(zhí)行DBCC CHECKDB或者在所有的表上執(zhí)行DBCC CHECKALLOC和 DBCC CHECKTABLE的組合。

首先，為什么會發(fā)生約束違規(guī)?當數(shù)據(jù)庫創(chuàng)建的時候，外鍵和一致性檢測也許并不存在。開發(fā)人員和數(shù)據(jù)庫管理員也許使用了WITH NOCHECK選項來創(chuàng)建約束，這個選項只能防止約束違規(guī)的進一步擴展，而不是會檢測已經存在的數(shù)據(jù)。更進一步的說，通過外鍵鏈接的數(shù)據(jù)可能會過期并且從母表中刪除，但是仍然會留在相關的表中，因為它在下級表中仍然具有相關記錄。

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

2、重建索引

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

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

1、 使用CREATE INDEX……WITH DROP EXISTING語句來刪除并重新創(chuàng)建索引

2、 執(zhí)行DBCC DBREINDEX

3、 執(zhí)行DBCC INDEXDEFRAG

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

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

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

3、更新統(tǒng)計數(shù)字

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

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

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

如果你想要為單個的表或者索引更新統(tǒng)計數(shù)字，你可以使用UPDATE STATISTICS命令?；蛘吣氵€可以執(zhí)行sp_updatestats系統(tǒng)過程來更新當前數(shù)據(jù)庫中所有表上的統(tǒng)計數(shù)字。

4、報告數(shù)據(jù)和日志文件中的空間利用率

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

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

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

【編輯推薦】

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