首先我们确定一点，一般情况下ORACLE UNDO表空间90%以上甚至99%以上是没有任何问题的

    一般情况下？什么是一般情况下，这里我们需要搞清楚一个概念，那就是GUARANTEE，先记住，后面讲，先了解一下UDUO的工作原理。

    undo_retention设的为900秒是指undo数据留在undo段里面至少要900秒以后才能被覆盖掉，因为Undo段是循环的，如果一个DML操作产生了大量的undo信息时，可能undo空间不够用，此时就要覆盖掉一些Undo块，undo_retention就是保证900秒后那些块才能被覆盖（这是一般情况）

如何查看undo_retention大小

SQL>SHOW PARAMETER UNDO_RETENTION;
    undo其实里面有N个段，不同的session会共用这些段而已。只不过这些段的其中一部分会被标注成可以覆盖，用多少覆盖多少，所以我们看到的就是undo好像只增长是不能简单的缩小，undo_retention:指定事物commit后undo 将要保存的时间(秒)，在ORACLE10g中默认的是900秒。
GUARANTEE ：保证undo_retention参数所设定的时间有效，这个是10g的新功能。
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
    在没有guarantee的保证下，ORACLE并不能保证能够将undo信息存储900秒，如果undo表空间不足，那么ORACLE将忽略undo_retention的设置，直接覆盖掉以前的undo,这个时候有可能会产生ORA-01555错误。如果undo表空间空间足够，那么undo将会保存很长一段时间，直到undo表空间达到maxsize，这个时候才会覆盖undo信息，而且ORACLE会从最古老的undo信息开始覆盖。
    ORACLE推荐我们将undo 表空间中的datafile 设定MAXSIZE ，不要让它一直自动扩展，如果ORACLE获得了自动扩展的能力，那么旧的undo不会被覆盖，到后来undo表空间会越来越大，越来越大，直到将磁盘空间耗尽。
    在有guarantee的保证下，ORACLE将会保证undo信息能够保存到undo_retention设定的值之后才被覆盖，如果这个时候同时执行了很多事物，将undo表空间耗完了，那么那个事物会失败，会报ORA-30036 错误，所以使用guarantee一定要慎用，如果非要使用guarantee，那么尽量将undo 表空间设大一点。
    Oracle10g开始，如果你设置UNDO_RETENTION为0，那么Oracle启用自动调整以满足最长运行查询的需要。当然如果空间不足，那么Oracle满足最大允许的长时间查询。而不再需要用户手工调整。

如果非得清理undo tablespace
可以采用如下步骤
1。新建一个undo_tablespace
2.alter system set undo_tablespace = new_undo_tbs
3.drop old undo_tablespace

这个操作的后果想必大家都知道，最好不要这么操作，如果操作了但愿这900秒内你没有要UNDO的事情
    最后需要注意一点：这个功能很少用，毕竟ORACLE没有强烈推荐，可能是一个过渡的，而且我们不知道它有没有什么BUG。

就是说一个库运行时间长了以后undo表空间的使用率达到90%以上那属于正常的现象了！