Undo復原段中Unexpired Block遲遲不釋放掉，占用90%以上的undo表空間.
導緻資料庫事務等待嚴重. DML運作異常緩慢. JOB運作也有ora-01555錯誤.
詳細詢問了下UNDO表空間的具體設定，如下：
1、undo_retention=3600；
2、未設定表空間的retention guarantee；
3、UNDO表空間設定為非自動擴充；
4、資料庫版本11.2.0.1.0
oracle給了個參數，"_smu_debug_mode" = 33554432，改到系統中，報出一大堆ORA-01555，趕緊改了回來。
莫非是碰到bug了？查了下，在oracle 10.2.0.2-3，确實有個很類似的bug：5387030。
正常情況下，如果undo 表空間被設定為固定大小，不自動擴充，oracle會啟用Automatic Tuning of undo retention特性。
啟用Automatic Tuning of undo retention時，oracle會忽略undo_retention的設定，根據undo表空間大小、系統負載情況，自動調整undo_retention為一個合适的值。這個值一般會大于“所有事務的最長運作時間”。
10gR2的bug現象為，隻要設定了undo表空間自動管理，不管有沒開自動擴充，不管undo_retention設定為多少，都會啟用 Automatic Tuning of undo retention的新特性。
這個bug的解決辦法：
10.2.0.2/10.2.0.3有相應的patch，這個bug在10.2.0.4中已經修複，建議找時間停機打patch
設定隐含參數_smu_debug_mode=33554432，将tuned_undoretention取值算法修正為max(maxquerylen secs + 300,undo_retention )
設定隐含參數_undo_autotune=false，關閉自動undo retention調整特性
在10.2.0.4及以後，這個bug就修複了。朋友那問題，肯定不是這bug引起的。
在查閱這bug時，發現Automatic Tuning of undo retention的啟用條件，與朋友那完全吻合，莫非這跟Automatic Tuning of undo retention有關。
查了下官方文檔，确實如此。
系統查了下，果然，undo_retention被自動調整了：
最後總結下，呵，在oracle 10.2.0.4，oracle11g裡面，如果碰到undo使用率100%，不釋放的問題。不建議再通過調整隐藏參數來解決undo占用率高的問題。
更推薦設定undo空間的自動擴充 + 限制檔案最大大小的方式來解決。