這幾天遇到一個錯誤，我也不知道算不算錯誤吧，因爲沒有報錯，只是在那突然的短短2分鐘內表的操作突然降低了，導致了該軟件重新啓動。查看alert日誌沒有報錯，而是在ASH裏找到了TOP SQL框有一個這樣的錯誤，使我百思不得其解。查看該SQL語句只是簡單的一個更新，並不需要優化。最後再百度、google的幫助下終於找到了錯誤原因，原來與UNDO的設置有關。首先來介紹下undo_retention參數，該參數是撤銷段的最短保留時間，而在默認情況下Oracle將根據表空間的大小和歷史使用情況，自動調整undo信息保存時間，同時忽略 undo_retention的值,除非undo_retention的guarantee 特性被啓用.也就是執行以下命令：
ALTER TABLESPACE UNDOTBS RETENTION GUARANTEE;
在自動調整啓用的情況下，實際的撤銷信息最短保留時間可以通過查詢V$UNDOSTAT視圖上的TUNED_UNDORETENTION列獲得。往往最短保存時間遠遠大於設定的UNDO_RETENTION。UNDO自動優化功能能夠最大限度的使用undo表空間,滿足大部分的sql執行,但是也帶來一個問題：很多事務執行完畢之後，發現UNDO表空間會在很長時間都一直保持着使用率是接近100%的狀態，active 狀態的很少。這種接近狀態還無法手工的收縮，甚至於重啓數據庫實例也無法緩解，而此時常常會收到undo表空間的監控報警。再來說說enq: US - contention問題
這是oracle10g中開始出現的bug(在11.1.0.7中仍有這個BUG)，當因爲系統activity增加或者降低的時候，oracle SMON進程會自動ONLINE或者OFFLINE rollback segments。這樣導致某些與undo segments相關的latch或者enqueue被hold住太長時間，導致系統很多活躍session都開始等待enq: US - contention。可以同時使用以下解決方法:
1. 設置event讓SMON不自動OFFLINE回滾段。
alter system set events '10511 trace name context forever, level 1';
2. 設置參數_rollback_segment_count ：表示有多少rollback segment要處於online的狀態；可以將該數值設置爲數據庫最繁忙的時候的回滾段數目。
alter system set "_rollback_segment_count"=;
這裏以‘_’開頭的爲隱藏參數，通過show parameter 是看不到的，可以通過以下語句：
select a.ksppinm name, b.ksppstvl value, a.ksppdesc description
from x$ksppi a, x$ksppcv b
where a.indx = b.indx
and a.ksppinm like '%_rollback_segment_count%';
3. undo autotune bug多多。最好disable。
alter system set "_undo_autotune"= false;
這種方法就是關閉了UNDO的自動調整功能，同事也能解決掉UNDO表空間會在很長時間都一直保持着使用率是接近100%的問題。
4. 有一個patch: A fix to bug 7291739 is to set a new hidden parameter, _highthreshold_undoretention to set a high threshold for undo retention completely distinct from maxquerylen.
alter system set "_highthreshold_undoretention"=;