我这边生产环境，一般undo表空间都会预先设置一个大小，并且保留数据文件的自动扩展，一直也相安无事。最近有套系统的undo表空间一直报警，使用率超过85%。看了下表空间大小，才5个G，以后确实是undo表空间过小了，于是扩到10G。结果第二天又报警了，嘿，不信了，于是扩到20g。哎呦，跟我杠上了，第二天又报警了。

      没办法，生了个awr报告，看到到底是哪个倒霉孩子写的大事务一句一直不提交。哎呦我去，没有找到嫌疑语句，啥情况。找来开发人员，交流一下，不存在批量之类的业务。怪了。

     查了下undo状态：select status,sum(bytes)/1024/1024/1024 from dba_undo_extents group by status;发现未过期的undo竟然占了表空间的百分之九十左右。但是我实时查看数据库状态，确实没有发现正在活动的大事务。于是怀疑，莫非是遇到undo方面的bug了，是不是存在未过期undo一直没释放的情况？

    在MOS上看到一篇文档doc：413732.1，有如下解释：

When the UNDO tablespace is created with NO AUTOEXTEND, following the allocation algorithm, here is the explanation for this correct behavior:

For a fixed size UNDO tablespace (NO AUTOEXTEND), starting with 10.2, we provide max retention given the fixed undo space, which is set to a value based on the UNDO tablespace size. 
This means that even if the undo_retention is set to a number of seconds (900 default), the fixed UNDO tablespace supports a bigger undo_retention time interval (e.g: 36 hours), based on the tablespace size, thing that makes the undo extents to be UNEXPIRED. But this doesn't indicate that there are no available undo extents when a transaction will be run in the database, as the UNEXPIRED undo segments will be reused.

大致意思是如果数据文件设置成非自动扩展的，oracle不会按照undo_retention参数所设置的值，对undo数据进行过期。我测试了下，在12.2.0.1版本，依然存在这样的情况。将上述存在问题的undo表空间数据文件设置成自动扩展后，过了一会，未过期的undo数据逐渐减少，直至undo表空间使用率恢复正常。

  oracle当真是博大精深，总有一些知识点很难触及，遇到了，总要记录一番。