有些新手在Oracle數據庫中創建索引時往往不會使用可選項其實有時候在合適的場合使用一些可選項可以提高索引的創建速度如為了大批量導入數據我們往往會先取消索引其以提高插入的速度然後等數據導入完畢後再重新創建索引在這個過程中如果能夠采用一些可選項則可以縮短索引創建的時間在Oracle數據庫中提供了豐富的可選項我們常用的可選項主要有以下這些
可選項一NOSORT記錄排序可選項
默認情況下在表中創建索引的時候會對表中的記錄進行排序排序成功後再創建索引但是當記錄比較多的是這個排序作業會占用比較多的時間這也就增加了索引建立的時間(排序作業是在索引創建作業中完成)有時候我們導入數據的時候如采用insert into 語句插入數據過程中同時采用Order by子句對索引字段進行了排序此時如果在索引創建過程中再進行排序的話就有點脫褲子放屁多此一舉了為此在重新創建索引時如果表中的數據已經排好序了(按索引字段排序)那麼在創建索引時就不需要為此重新排序此時在創建索引時數據庫管理員就可以使用NOSORT可選項告訴數據庫系統不需要對表中當記錄進行重新排序了
采用了這個選項之後如果表中的記錄已經按順序排列那麼在重新創建索引的時候就不會重新排序可以提高索引創建的時間節省內存中的排序緩存空間相反如果表中的記錄是不按索引關鍵字排序的話那麼此時采用NOSORT關鍵字的話系統就會提示錯誤信息並拒絕創建索引所以在使用NOSORT可選項的時候數據庫管理員盡管放心大膽的使用因為其實在不能夠使用這個選項的時候數據庫也會明確的告知為此其副作用就比較少數據庫管理員只需要把這個可選項去掉然後重新執行一次即可不過這裡需要注意的是如果表中的記錄比較少的話那麼使用NOSORT選項的效果並不是很明顯當采用insert into批量導入數據並在這個過程中采用了Order by子句對索引關鍵字進行了排序的話則此時采用NOSORT選項的話往往能夠起到比較好的效果
可選項二NOLOGGING是否需要記錄日志信息
在創建索引的時候系統會把相關的信息存儲到日志信息中去如果表中的記錄比較多則需要一一的把這些信息記錄到日志文件中這顯然會讓數據庫增加很大的工作量從而增加索引創建的時間為此在創建索引的過程中如果有必要時我們可以采用NOLOGGING選項讓數據庫在創建索引的過程中不產生任何重做日志信息此時當表中的記錄比較多時就可以明顯提高速度
但是默認情況下數據庫在在創建索引時是不采用這個選項的即會把相關的信息保存到重做日志中去這雖然降低了索引創建的效率但是如果遇到什麼意外的話卻可以利用重做日志來進行恢復所以此時數據庫管理員就比較難以抉擇了一方面是數據的安全另一方面是索引創建的速度根據筆者的經驗只要數據庫服務器比較穩定而數據庫中約束機制又比較完善的話那麼在創建索引的過程中一般不會出現問題可以放心大膽的使用這個可選項
但是如果數據庫已經使用了好幾年了後來因為某種原因需要重建索引在這種情況下由於數據庫使用過程中很多因素數據庫管理員無法控制此時為這種類型的數據庫創建索引時為了保險起見還是不要采用這個選項好因為此時遇到錯誤的幾率相對來說會搞一點為此此時犧牲一下索引創建的速率而提高數據的安全性還是有必要的萬一遇到什麼問題時可以通過重做日志來及時的恢復數據為企業用戶減少損失
可選項三COMPUTE STATISTICS是否生成統計信息
如果管理員在創建索引時采用了這個選項則數據庫將在創建索引的過程中以非常小的代價直接生成關於索引的相關統計信息然後把這些信息存儲在數據字典中這就可以避免以後對索引進行分析統計而且優化器在優化SQL語句的時候可以隨機使用這些統計信息以確定是否生成使用該索引的執行計劃通常情況下在生成索引的過程中統計索引的相關信息其所花的代價是最小的無論從時間上還是從硬件資源的耗費上都是非常小的所以在創建索引的過程中統計相關的索引信息是非常有用的
但是默認情況下數據庫是不采用這個選項的這主要是因為一些事物處理系統索引的信息是經常需要發生變化的如果在索引創建的過程中統計了相關信息這些信息隨著索引的調整等等原因會很快的過時所以說其在默認情況下沒有采用這個選項可見這個選項並不是在任何情況下都能夠起到效果但是如果這個數據庫系統是一個決策支持系統其數據索引等等在一段時間內基本上是穩定不變的此時在創建索引時可以使用這個選項如此的話在生成索引時可以以最小的代價生成這些統計信息方便優化器使用筆者在部署數據庫應用的時候對於事務型的數據庫系統一般不會啟用這個選項但是對於一些決策性的數據庫系統或者數據倉庫中創建索引時則筆者喜歡采用這個選項這有助於提高數據庫的性能因為優化器在生成執行計劃時可以直接采用這個統計信息所以數據庫能夠在最短的時間內確定需要采用的執行計劃而且在執行計劃制定中參考了這個索引統計信息為此所生成的執行計劃在同等條件下可能更加的合理
可選項四ONLINEDML操作與創建索引操作是否可以同時進行
默認情況下數據庫系統是不允許DML操作與創建索引的操作同時進行的也就是說在創建索引的過程中是不允許其他用戶對其所涉及的表進行任何的DML操作這主要是因為對基礎表進行DML操作時會對基礎表進行加鎖所以在基礎表上的DDL事務沒有遞交之前即沒有對基礎表進行解鎖之前是無法對這基礎表創建索引的反之亦然顯然此時數據庫沒有采用這個ONLIE選項繼之DML操作與創建索引操作同時進行主要是從創建索引的效率出發的防止因為兩個作業相互沖突從而延長某個作業的運行時間
但是有時會我們必須允許他們進行同時操作如用戶可能一刻都不能夠離開數據庫系統需要時時刻刻對數據庫基礎表進行DML操作而此時由於某些原因數據庫管理員又需要重新建立索引時那麼不得不在創建索引的語句中加入這個ONLINE選項讓他們同時運行此時雖然可能會延長索引創建作業的時間但是可以保障用戶DML操作能夠正常進行有時候犧牲這個代價是值得的用戶是不能夠等的而我們數據庫管理員則可以勉強的等一會兒
當然如果用戶對於這個DML操作及時性沒有這麼高如數據庫管理員在晚上員工沒有使用數據庫時創建索引時則可以不帶這個選項在限制用戶對基礎表進行DML操作的同時提高數據庫創建索引的效率
可選項五PARALLEL多服務進程創建索引
默認情況下Oracle數據庫系統不采用這個選項這並不是說這個選項不可用而是因為大多數情況下企業部署Oracle數據庫時所采用的數據庫服務器往往只有單個CPU此時數據庫系統是用一個服務進程來創建索引的
如果企業的服務器有多個CPU的話則可以在創建索引時采用這個選項因為只要采用了這個選項則數據庫就會使用多個服務進程來並行的創建索引以提高索引創建的速度為此在同等條件下多服務並行創建進索引並單服務創建索引速度要快的多所以如果服務器中有多個CPU而且需要創建的索引比較多或者基礎表中記錄比較多的話則采用這個選項能夠大幅度的提高索引的創建效率
故筆者建議如果采用多CPU的服務器時最好在創建索引時使用這個選項不能夠浪費了服務器的CPU呀不然的話多CPU服務器的優勢就體現不出來了為此采用這個選項也是物盡其用
From:http://tw.wingwit.com/Article/program/SQL/201311/16409.html
