Oracle資料庫中Insert、Update、Delete操作速度

　在Oracle資料庫中，Insert、Update、Delete三個操作是對資料庫中的資料進行插入、更新以及刪除。在進行這些操作時，如果 資料庫中的記錄比較多時，則所需要的時間比較長。如需要利用一個Update語句更新大量記錄時，即使更新的內容很簡單，如只是將價格提升10%，但是仍 然需要花費比較成的時間。所以從某種程度上來說，進行這些操作時其執行速度跟內容的大小關係不大，反而跟記錄的多少卻有很大的關係。那麼在Oracle數 據庫中，能否採取一些措施來提高這些操作的速度呢?為此筆者有如下兩個建議，希望對大家有所幫助。[@more@]

　　建議一：在執行這些操作時不向重做日誌中寫東西。

　　在執行更新、插入、刪除操作時，預設情況下，其在更新資料的同時，也會像重做日誌檔案中記錄這些改變。如利用Update語句將資料庫中產品的 價格提高10%時。資料庫會更改這些價格，同時也會在重做日誌中記錄這些改變。顯然，更新一個資料，資料庫要進行兩項工作。為此，當更新所涉及到的記錄比 較多時，這個更新操作就可能要耗費比較長的時間。此時，可能需要更新內容本身字元的多少，跟其更新的效率並不具有很大的聯絡。其執行的速度主要跟其更新所 涉及到的記錄數量有關。

　　為此，有時候在追求其更快的執行速度時，我們往往需要在這些語句中加入一個nologging選項。如在使用Update語句更新價格資訊時， 加上這個Nologging選項就可以顯著提高其執行的速度。更新操作所涉及到的記錄越多，其效果越明顯。那麼這個可選項到底有什麼作用呢?顧名思義，這 個引數就是告訴資料庫系統，在執行這個操作的時候，不要忘重做日誌中記錄相關的資訊。也就是說，此時資料庫系統只需要做一件工作即可，至需要更改資料，而 不會產生重做日誌檔案。在理想的狀態下，這麼設定可以將這些操作的速度提高一倍。所以在進行大規模的更新、刪除、插入記錄等操作時，筆者往往建議大家加上 這個可選項，以提高執行的速度。

　　不過如果採用這個可選項的話，也有一個缺點。因為其不會產生重做日誌，所以如果資料更新失敗或者出現其他一些意外故障，就不能夠利用重做日誌來 恢復資料。為此如果對於資料的準確性要求非常苛刻的話，採用這種方式來提高這些操作的執行速度，可能並不是一種合理的方法。其是以犧牲資料的安全性來獲取 效能上的改進。雖然這些操作出現故障的機率比較少見，但是在使用這個可選項時，資料庫管理員必須要了解這個風險。在可能的情況下，即使做好風險的評估與預 防。

　　建議二：調整重做日誌的大小來提高執行速度。

　　上面這種方法由於不產生重做日誌，雖然提高了執行的速度，但是也帶來了一定的安全風險。那麼是否有兩全其美的方法呢，即能夠提高執行速度，又能 夠保障資料的安全呢?在Oracle資料庫中就有這麼一個兩全其美的方法。就是調整重做日誌的大小來提高執行速度。來具體講解這個方案時，筆者要強調的是 此時資料庫仍然會產生重做日誌。為此其效果沒有上面這種方法好。但是其可以保障資料的安全，在出現問題時，仍然可以利用重做日誌來恢復資料。所以說，這是 在安全與速度之間實現了一個均衡。

　　在對記錄進行大批次的更新時，在重做日誌中產生相關的記錄會花費比較多的時間。其實這個時間也可以分為兩個部分。一是往重做日誌中記錄相關資訊 的時間;二是重做日誌進行切換的時間。在Oracle資料庫的聯機重做日誌中，往往同時有多個重做日誌檔案。當某個重做日誌檔案滿時，則會將後續的記錄寫 到下一個重做日誌檔案中。但是在寫入之前，其需要對這個即將被覆蓋的重做日至進行歸檔，也就是進行備份。在這個備份的時候，Update等更新操作不得不 進行等待。要等待其歸檔完成之後，再繼續進行更新併產生重做記錄。也就是說，聯機重做日誌只有在被歸檔後才能夠被覆蓋，在這個歸檔的過程中，其他相關的操 作必須等待，直到有可能的聯接重做日誌。為此，如果這個重做日誌的檔案比較小，而利用Update更新的記錄又比較多時，此時就可能需要使用多個重做日誌 檔案來儲存這些更改資訊。此時就需要進行多次等待才行。那麼就無形之中增加了這個操作的執行時間。所以，經常需要對資料庫進行大容量的更新、刪除或者插入 記錄等操作的，最好能夠調整這個重做日誌檔案的大小，以減少重做日誌歸檔的等待時間，提高資料庫的效能。

　　在調整這個重做日誌檔案之前，資料庫管理員最好能夠先確認一下，這個重做日誌檔案歸檔的頻率。如果歸檔的頻率比較高，那麼增加重做日誌檔案的大 小，往往可以明顯的提高資料庫的效能，特別是插入、刪除、更新等操作的效率。那麼該如何來判斷這個重做日誌檔案歸檔是否頻繁呢?在Oracle資料庫中有 比較多的方法。其實重做日誌檔案就跟普通的檔案相同，其也有更新時間等屬性。為此在作業系統上，可以對比幾個重做日誌檔案的更新時間，來判斷其歸檔的頻率 是否頻繁。另外在Oracle資料庫中還有一個動態檢視，名字為v$log_history。在這個檢視中存放著重做日至切換的相關記錄。如資料庫管理員 可以查詢最近50個重做日誌的切換記錄，看看其相關的時間有多長，從而來判斷這個重做日誌的切換是正常的，還是太過於頻繁。一般情況下，只要增加這個重做 日誌檔案的容量，就可以為大批次的更新、刪除等操作提供比較大的重做日誌空間。此時執行一個大批次的更新操作時，可能只需要使用一個重做日誌檔案即可。此 時，在重做日誌上所花的時間，就是隻有產生重做記錄的那部分時間，而沒有重做日誌切換歸檔時的等待時間。所以，經過類似的調整之後，往往可以在很大程度上 提高資料庫的效能。另外還有一種可行的方法是，不調整重做日誌檔案的大小，而是增加重做日誌檔案的數目。如此也可以在頻繁的日誌切換過程中提供足夠的日誌 空間。不過筆者還是傾向與增加重做日誌檔案的容量來解決這個問題。

　　不過重做日誌檔案也並不是越大越好。重做日誌檔案越大，其歸檔的時間也就越長。俗話說，過之而不及。有時候這反而會給資料庫的安全與效能帶來負 面的影響。根據筆者的經驗，筆者認為這個重做日誌檔案切換的時間間隔最好能夠在30分鐘-40分鐘之間。因為現在即使再複雜的更新或者刪除操作，基本上可 以在這個時間內完成。否則的話，可能就是語句方面有問題，需要對SQL語句進行最佳化。所以將這個日誌歸檔的時間間隔確定在這個時間範圍之內是合理的。作為 合格的資料庫管理員，需要持續追蹤這個日誌切換的時間間隔。可以透過檢視兩個連續重做日誌檔案之間的更新時間間隔或者資料庫系統的日誌切換記錄來檢視這個 日誌切換的頻率。

　　當調整完重做日誌檔案的大小之後，資料庫管理員仍然需要在一段時間內追蹤這個日誌切換的頻率。以判斷調整後的重做日誌檔案是否能夠實現既定的目標。如果效果不明顯的話，可能還需要再次調整這個重做日誌檔案的大小。

　　Oracle資料庫管理員可以使用ALTER DATABASE ADD LOGFILE語句來建立比較大的日誌檔案。注意此時需要及時將比較小的日誌檔案刪除。否則的話，大小重做日誌檔案混用，並不能夠起到預計的效果。為此在 調整日誌檔案大小時一般的步驟就是先建立多個大日誌檔案，然後再將小日誌檔案刪除。一般情況下，在刪除小日誌檔案過程中，最好不要透過刪除重做日誌檔案組 來實現。也就是說，在原有的重做日誌檔案組下面，建立大的重做日誌檔案;然後只刪除小的重做日誌檔案。即重做日誌檔案組仍然保持不變。改變的只是其內部的 重做日誌成員而已。

　　另外在重做日誌管理中，如果將重做日誌檔案放置在效能比較好的硬碟中，或者採用磁碟陣列等技術來提高重做日誌檔案的寫入速度，也可以提高大批次 插入、更新等操作的效率。總之，最好這個日誌切換的頻率不要低於30分鐘。如果少於這個時間的話，那麼系統管理員就需要調整日誌檔案的大小，來延長兩次日 志切換之間的時間間隔。當然這個時間間隔需要根據企業應用的變化而變化。

轉自：