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空间的自动扩展 + 限制文件大大小的方式来解决。

文章名称：Oracle—undo回滚段长时间不释放-创新互联
本文路径：http://lszwz.com/article/jddso.html