隨筆檔案

　　重建索引有兩種方法：一種是最簡單的，刪除原索引，然后重建;第二種是使用ALTER INDEX … REBUILD   it培訓機構

　　命令對索引進行重建。第二種方式是從oracle 7.3.3版本開始引入的，從而使得用戶在重建索引時不必刪除原索引再重新CREATE INDEX了。ALTER INDEX … REBUILD相對CREATE INDEX有以下好處：

　　它使用原索引的葉子節點作為新索引的數據來源。我們知道，原索引的葉子節點的數據塊通常都要比表里的數據塊要少很多，因此進行的I/O就會減少;同時，由于原索引的葉子節點里的索引條目已經排序了，因此在重建索引的過程中，所做的排序工作也要少的多。

　　自從oracle 8.1.6以來，ALTER INDEX … REBUILD命令可以添加ONLINE短語。這使得在重建索引的過程中，用戶可以繼續對原來的索引進行修改，也就是說可以繼續對表進行DML操作。

　　而同時，ALTER INDEX … REBUILD與CREATE INDEX也有很多相同之處：

　　它們都可以通過添加PARALLEL提示進行并行處理。

　　它們都可以通過添加NOLOGGING短語，使得重建索引的過程中產生最少的重做條目(redo entry)。

　　自從oracle 8.1.5以來，它們都可以田間COMPUTE STATISTICS短語，從而在重建索引的過程中，就生成CBO所需要的統計信息，這樣就避免了索引創建完畢以后再次運行analyze或dbms_stats來收集統計信息。

　　當我們重建索引以后，在物理上所能獲得的好處就是能夠減少索引所占的空間大小(特別是能夠減少葉子

　　節點的數量)。而索引大小減小以后，又能帶來以下若干好處：

　　CBO對于索引的使用可能會產生一個較小的成本值，從而在執行計劃中選擇使用索引。

　　使用索引掃描的查詢掃描的物理索引塊會減少，從而提高效率。

　　由于需要緩存的索引塊減少了，從而讓出了內存以供其他組件使用。

　　盡管重建索引具有一定的好處，但是盲目的認為重建索引能夠解決很多問題也是不正確的。比如我見過一

　　個生產系統，每隔一個月就要重建所有的索引(而且我相信，很多生產系統可能都會這么做)，其中包括一些100GB的大表。為了完成重建所有的索引，往往需要把這些工作分散到多個晚上進行。事實上，這是一個7×24的系統，僅重建索引一項任務就消耗了非常多的系統資源。但是每隔一段時間就重建索引有意義嗎?這里就有一些關于重建索引的很流行的說法，主要包括：

　　如果索引的層級超過X(X通常是3)級以后需要通過重建索引來降低其級別。

　　如果經常刪除索引鍵值，則需要定時重建索引來收回這些被刪除的空間。

　　如果索引的clustering_factor很高，則需要重建索引來降低該值。

　　定期重建索引能夠提高性能。

　　對于第一點來說，我們在前面已經知道，B樹索引是一棵在高度上平衡的樹，所以重建索引基本不可能降

　　低其級別，除非是極特殊的情況導致該索引有非常大量的碎片，導致B樹索引“虛高”，那么這實際又來到第二點上(因為碎片通常都是由于刪除引起的)。實際上，對于第一和第二點，我們應該通過運行ALTER INDEX … REBUILD命令以后檢查indest_stats.pct_used字段來判斷是否有必要重建索引。