SQL Server2005索引碎片分析和解決方法

SQL Server2005索引碎片分析和解決方法

本文做者(鄭賢嫺),請您在閱讀本文時尊重做者版權。

摘要: SQL Server,爲了反應數據的更新,須要維護表上的索引,於是這些索引會造成碎片。根據工做量的特徵,這些碎片會影響對應的工做性能。此文幫助決定是否須要整理碎片以改善性能的信息。SQL Serve提供一些命令來實現索引的碎片整理。這裏比較其中兩個命令:DBCC DBREINDEX 和 DBCC INDEXDEFRAG。

關鍵詞: SQL Server;索引碎片;數據庫優化毫無疑問,給表添加索引是有好處的,你要作的大部分工做就是維護索引,在數據更改期間索引可能產生碎片,因此一些維護是必要的。碎片多是你查詢產生性能問題的來源。

怎樣肯定索引是否有碎片?

SQLServer提供了一個數據庫命令:DBCC SHOWCONTIG,來肯定一個指定的表或索引是否有碎片。下面舉一個例子:

對't_exam' 表執行DBCC SHOWCONTIG,結果以下:

-- - 掃描頁數.....................................: 20229

-- - 掃描擴展盤區數...............................: 2543

-- - 擴展盤區開關數...............................: 15328

-- - 每一個擴展盤區上的平均頁數.....................: 8.0

-- - 掃描密度〔最佳值:實際值〕....................: 16.50%〔2529:15329〕(若是小於 100,則存在碎片。16.50%說明有不少碎片)

-- - 邏輯掃描碎片.................................: 46.23%(若是爲0是最好)

-- - 擴展盤區掃描碎片.............................: 45.10%

-- - 每頁上的平都可用字節數.......................: 3240.1

-- - 平均頁密度(完整)...........................: 59.97%(若是爲100%是最好)

以上結果顯示:邏輯掃描碎片和擴展盤區掃描碎片都很是大,須要對索引碎片進行處理。

DBCC DBREINDEX 和DBCC INDEXDEFRAG命令經常使用來整理索引碎片。

這裏須要注意的是,很是低的碎片級別(小於5%)不該經過這些命令來解決,由於刪除如此少許的碎片所得到的收益始終遠低於從新組織或從新生成索引的開銷。

1 DBCC DBREINDEX

DBCC DBREINDEX用於在指定的表上物理地重建一個或多個索引。DBCC DBREINDEX是離線操做方式。當該操做運行時,涉及到的表就沒法被用戶訪問。

DBCC DBREINDEX動態地重建索引。沒有必要知道參與重建的表結構到底如何,是否用主鍵或者惟一性約束等信息;重建的時候會自動管理的。DBCC DBREINDEX徹底重建索引,就是此過程當中將刪除碎片,經過使用指定的或現有的填充因子設置壓縮頁來回收磁盤空間,並在連續頁中對索引行從新排序(根據須要分配新頁)。這樣能夠減小獲取所請求數據所需的頁讀取數,從而提升磁盤性能。從內部運行看,DBCC DBREINDEX和手工用T-SQL語句來運行刪除而後從新建立索引十分類似。

下面兩點是DBCC DBREINDEX比DBCC INDEXDEFRAG優越的地方:

DBCC DBREINDEX在重建索引過程當中,自動重建統計;這將顯著提升工做性能。

DBCC DBREINDEX能夠運行在多處理器環境下,利用多處理器的優點,當重建較大和碎片厲害的索引時,速度能夠十分快。

DBCC DBREINDEX的全部工做是一個單一的,原子事務。必須完成建立新的索引並替換舊索引,而後舊索引頁被釋放。完成重建須要數據文件中有足夠的空餘空間。若是空餘空間不夠,DBCC DBREINDEX要麼沒法重建索引,要麼會產生大於0的邏輯碎片。所需空餘空間視狀況而定,取決於事務中要建立的索引數目。

2 DBCC INDEXDEFRAG

DBCC INDEXDEFRAG用於對指定的索引進行重建。和DBCC DBREINDEX相似,也不需顧及表的基礎結構;不過,DBCC INDEXDEFRAG沒法用一個語句對全部的索引進行重建。對於每一個但願進行碎片整理的索引,都必須運行一次DBCC INDEXDEFRAG。

不管是DBCC DBREINDEX仍是DBCC INDEXDEFRAG,均可以有效地整理索引碎片,並將頁密度恢復到初始填充因子規定的頁密度附近。基於這些結果,下面須要決定何時應用哪一種整理方式。

若是容許有一段時間進行離線索引重建,DBCC DBREINDEX通常來講比DBCC INDEXDEFRAG要快。DBCC DBREINDEX能夠充分利用多處理器系統的平行性能。DBCC INDEXDEFRAG用於對生產環境干擾不大,對工做性能影響不大的場合。測試顯示,即便同時幾個DBCC INDEXDEFRAG並行工做,對性能降低的影響也歷來不會超出10%。可是,這也一樣使得DBCC INDEXDEFRAG針對較大的索引整理時,須要很長的時間才能完成。並且,工做時間的長短還依賴於當時在服務器上運行的訪問工做。

3 結論

對於不一樣的工做類型,索引碎片整理具備十分不一樣的影響。某些應用能夠從碎片整理中獲取很大的性能提高。理解應用特徵,系統性能和SQL Server提供的碎片統計信息,是正確決定什麼時候進行碎片整理的關鍵。SQL Server提供一些命令來完成索引碎片整理。而在SQL Server 2005中, DBCC DBREINDEX和DBCC INDEXDEFRAG已經被做爲維護計劃中的兩個步驟:從新生成索引和從新組織索引,方便了數據庫管理的數據庫維護工做。本文能夠幫助咱們來決定什麼時候以及如何整理索引碎片,從而使性能獲得最大的改善。

 

出處：http://blog.csdn.net/wxzyq/article/details/6821802