建站
咨詢
售后
建站咨詢
新聞中心
此文章主要向大家講述的是正確維護(hù)SQL Server保駕護(hù)航的實際操作步驟，我前兩天在相關(guān)網(wǎng)站看見正確維護(hù)SQL Server保駕護(hù)航的實際操作步驟的資料，覺得挺好，就拿出來供大家分享。
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、周口網(wǎng)絡(luò)推廣、小程序開發(fā)、周口網(wǎng)絡(luò)營銷、周口企業(yè)策劃、周口品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供周口建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
SQL S
每個新發(fā)布的SQL Server都具有越來越多的自我維護(hù)SQL Server保駕護(hù)航能力，但是“安全比抱歉好得多”的原則仍然是正確的:實際的數(shù)據(jù)庫管理包含了對系統(tǒng)和用戶數(shù)據(jù)庫進(jìn)行的周期性維護(hù)，這樣才能在你的用戶發(fā)現(xiàn)問題之前把它解決掉。
SQL Server 2000中包含了數(shù)據(jù)庫維護(hù)計劃向?qū)?，它可以為你自動完成所有的維護(hù)任務(wù)。然而，你需要了解，在現(xiàn)場和你的維護(hù)計劃后面，什么是隱藏的可能給你帶來麻煩的東西。
數(shù)據(jù)庫維護(hù)計劃是通過一系列的DBCC命令和系統(tǒng)存儲過程實現(xiàn)的。DBCC的意思是數(shù)據(jù)庫一致性檢測(database consistency check)或者數(shù)據(jù)庫控制臺命令(database console command)。有非常多的寫入文檔的和沒有寫入文檔的DBCC命令，但是只有一小部分可以用于維護(hù)SQL Server保駕護(hù)航。這里我將回顧一些與數(shù)據(jù)庫維護(hù)SQL Server保駕護(hù)航的各個方面相關(guān)的DBCC命令和系統(tǒng)存儲過程。
通常的數(shù)據(jù)庫維護(hù)時間表都具有如下的活動。點擊活動，可以獲得與此相關(guān)的DBCC命令和系統(tǒng)存儲過程。
1、檢測數(shù)據(jù)庫一致性和數(shù)據(jù)的完整性
DBCC CHECKDB是最廣泛使用的，檢測數(shù)據(jù)庫中所有對象的工具。這個語句可以為每一個表和索引視圖，以及文本和圖像對象，檢測所有的數(shù)據(jù)和索引頁面的分配和結(jié)構(gòu)上的完整性。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ù)庫在單用戶的模式下運(yùn)行。如果不是單用戶模式的化，語句就失敗了。注意，當(dāng)用戶連接在上面的時候，不要將數(shù)據(jù)庫設(shè)置成單用戶模式。
如果你執(zhí)行不帶參數(shù)的DBCC CHECKDB并且發(fā)現(xiàn)錯誤的時候，你應(yīng)該將你的數(shù)據(jù)庫設(shè)置在單用戶模式，然后嘗試修復(fù)這個問題。首先，確保執(zhí)行那些不會導(dǎo)致數(shù)據(jù)丟失的語句——REPAIR_FAST 和 REPAIR_REBUILD。如果你還是遇到錯誤，那么執(zhí)行DBCC CHECKDB，帶著參數(shù)REPAIR_ALLOW_DATA_LOSS。還要確保在顯性事務(wù)中關(guān)閉語句。如果發(fā)生了可接受的數(shù)據(jù)丟失，你可以提交這個事務(wù)。否則，你還可以通過語句來回滾所作的修改。
請注意，運(yùn)行DBCC CHECKDB是一項非常消耗資源的操作。你應(yīng)該在限制用戶在數(shù)據(jù)庫服務(wù)器上的活動的時候運(yùn)行這個語句。
DBCC CHECKTABLE與DBCC CHECKDB相同，除了它是在一個單個的表、索引視圖或者即使是一個索引上，而不是在整個數(shù)據(jù)庫上。
DBCC CHECKALLOC檢測某個數(shù)據(jù)庫的磁盤空間分配結(jié)構(gòu)的一致性。因為DBCC CHECKDB包括了與DBCC CHECKALLOC同樣的檢測，那么如果執(zhí)行了CHECKDB的話就沒有必要再執(zhí)行DBCC CHECKALLOC了。實際上，我們推薦只使用DBCC CHECKALLOC，如果用DBCC CHECKDB或者 DBCC CHECKTABLE會報告說產(chǎn)生分配錯誤的話。
DBCC CHECKCONSTRAINTS在某個數(shù)據(jù)庫中，檢測某些特定的約束或者全部約束的一致性。DBCC CHECKCONSTRAINTS總是在當(dāng)前數(shù)據(jù)庫的上下文環(huán)境中執(zhí)行。
注意，DBCC CHECKCONSTRAINTS并不進(jìn)行磁盤或者文件級別的一致性檢測;它只是確保外鍵定義的一致性，同時檢測約束——僅僅是確認(rèn)數(shù)據(jù)有效。如果你希望檢測磁盤上表和索引的一致性，你應(yīng)該執(zhí)行DBCC CHECKDB或者在所有的表上執(zhí)行DBCC CHECKALLOC和 DBCC CHECKTABLE的組合。
首先，為什么會發(fā)生約束違規(guī)?當(dāng)數(shù)據(jù)庫創(chuàng)建的時候，外鍵和一致性檢測也許并不存在。開發(fā)人員和數(shù)據(jù)庫管理員也許使用了WITH NOCHECK選項來創(chuàng)建約束，這個選項只能防止約束違規(guī)的進(jìn)一步擴(kuò)展，而不是會檢測已經(jīng)存在的數(shù)據(jù)。更進(jìn)一步的說，通過外鍵鏈接的數(shù)據(jù)可能會過期并且從母表中刪除，但是仍然會留在相關(guān)的表中，因為它在下級表中仍然具有相關(guān)記錄。
DBCC CHECKCATALOG在某個數(shù)據(jù)庫的系統(tǒng)表內(nèi)或者之間檢測一致性。很多類似DBCC CHECKCONSTRAINTS的命令都不會檢測頁面分配的一致性;它只是檢測系統(tǒng)表中的數(shù)據(jù)。DBCC CHECKCATALOG報告錯誤意味著有些人手工從系統(tǒng)表中添加、修改或者刪除記錄了。如果你沒有注意此類活動，那么你應(yīng)該看緊你的安全措施了——看看誰具有系統(tǒng)管理員和數(shù)據(jù)庫主任的全縣，然后評估你的安全策略。
2、重建索引
當(dāng)數(shù)據(jù)行從表中INSERTED, UPDATED and DELETED的時候，索引就產(chǎn)生了碎片。碎片越多，索引的效率越低。數(shù)據(jù)庫管理員必需確保碎片的級別很低或者根本不存在。碎片級別可以通過在某個索引上執(zhí)行DBCC SHOWCONTIG語句來找到。
這里有三種方法可以去掉碎片:
1、 使用CREATE INDEX……WITH DROP EXISTING語句來刪除并重新創(chuàng)建索引
2、 執(zhí)行DBCC DBREINDEX
3、 執(zhí)行DBCC INDEXDEFRAG
DBCC DBREINDEX重新構(gòu)建一個特定的索引或者某個特定的表上的所有的索引。這個語句允許強(qiáng)制PRIMARY KEY和UNIQUE約束的索引重新構(gòu)建，而不需要刪除約束。你不需要知道索引的類別和名稱，你同樣可以使用。使用DBCC DBREINDEX比單獨為表上的每個索引編寫DROP INDEX 和CREATE INDEX語句簡單。時刻記住，重新構(gòu)建聚簇索引也會引起非聚簇索引的重建。
DBCC INDEXDEFRAG可以刪除某個聚簇索引或者非聚簇索引的碎片。與DBCC DBREINDEX不同，這個語句需要指定某個特別的索引，并且不能運(yùn)行在表上所有索引上。刪除碎片也是一項在線操作，因此不會妨礙用戶對表進(jìn)行操作。DBCC INDEXDEFRAG給系統(tǒng)增加了額外的負(fù)擔(dān)，因為它產(chǎn)生了額外的I/O負(fù)擔(dān)。它還會影響到索引頁面，并且會在壓縮之后刪除所有遺留的沒有數(shù)據(jù)的頁面。
刪除碎片的頻率依賴于在你的數(shù)據(jù)庫中，數(shù)據(jù)修改的級別。需要每天處理幾百萬個事務(wù)的系統(tǒng)應(yīng)該至少每個星期都進(jìn)行一次索引重建。另一方面，在幾乎沒有修改的數(shù)據(jù)庫上，即使你每個月進(jìn)行一次索引重建，數(shù)據(jù)庫都會運(yùn)行得不錯。
3、更新統(tǒng)計數(shù)字
統(tǒng)計數(shù)據(jù)中包含了表中某個索引或者字段的數(shù)值分布的信息。你可以通過使用CREATE STATISTICS語句或者使用sp_createstatistics系統(tǒng)過程來創(chuàng)建統(tǒng)計數(shù)字。統(tǒng)計數(shù)字檢索有關(guān)索引是否具有良好或者糟糕的選擇性的信息，索引的選擇性可以用來判斷索引的效率是否足以滿足查詢的要求。當(dāng)你創(chuàng)建索引的時候，SQL Serve保駕護(hù)航r自動創(chuàng)建統(tǒng)計數(shù)字。此外，SQL Server還為那些沒有定義索引的字段創(chuàng)建統(tǒng)計數(shù)字。
針對某個索引的統(tǒng)計數(shù)字可以通過使用DBCC SHOW_STATISTIC0S語句來查看。當(dāng)數(shù)據(jù)發(fā)生改變的時候，統(tǒng)計數(shù)字就過時了。當(dāng)選擇索引來滿足查詢的時候，陳舊的統(tǒng)計數(shù)字會讓SQL Server作出次優(yōu)化的決定。
默認(rèn)情況下，SQL Server 2000自動更新每個表上的統(tǒng)計數(shù)字。然而，在某些情況下，關(guān)閉統(tǒng)計數(shù)字的自動更新是有意義的。例如，我們假設(shè)你有某種類型的批處理例程，每個周末，系統(tǒng)具有最小利用率的時候，都會向你的表中添加上百萬行數(shù)據(jù)。統(tǒng)計數(shù)字的自動更新只會降低你的批處理過程，而不會為系統(tǒng)帶來任何好處。除了你可以在周末關(guān)閉自動更新，然后在每個周一早上首先更新統(tǒng)計數(shù)字之外，你還可以啟用或者禁用統(tǒng)計數(shù)字的自動更新，通過使用sp_autostats過程。
如果你想要為單個的表或者索引更新統(tǒng)計數(shù)字，你可以使用UPDATE STATISTICS命令。或者你還可以執(zhí)行sp_updatestats系統(tǒng)過程來更新當(dāng)前數(shù)據(jù)庫中所有表上的統(tǒng)計數(shù)字。
4、報告數(shù)據(jù)和日志文件中的空間利用率
也許你被要求擴(kuò)展或者縮減一個數(shù)據(jù)文件或者事務(wù)日志文件的尺寸，那么這時候就可以使用DBCC SHRINKDATABASE 或者 DBCC SHRINKFILE命令了。
Sysindexes表在經(jīng)過一段時間之后會變得不準(zhǔn)確，特別是在增長頻繁并且/或者縮減頻繁的數(shù)據(jù)庫中。DBCC UPDATEUSAGE命令報告并且糾正sysindexes表中不準(zhǔn)確的數(shù)字。如果你認(rèn)為你的數(shù)據(jù)庫或者表的尺寸與sp_spaceused系統(tǒng)過程中報告的數(shù)字不符的話，那么你就應(yīng)該使用這個語句。
每次在你使用DBCC SHRINKDATABASE 或者 DBCC SHRINKFILE縮減數(shù)據(jù)庫文件之后，都執(zhí)行DBCC UPDATEUSAGE，或者只是作為一個周期性的維護(hù)SQL Server保駕護(hù)航計劃，都是個好主意。
網(wǎng)站題目：SQLServer保駕護(hù)航的正確維護(hù)4步驟
網(wǎng)頁鏈接：http://www.5511xx.com/article/dhscdij.html
