你的undo data太多了，两方面考虑，一是你的事务太长了，这个牵涉到你的应用的问题；二是你的undo data保留时间太长了，可以适当减少undo_retention的值，单位为秒。
查询v$undostat看看什么时候undo data增长最快，时间太久了就没有记录了。回滚段在Undo表空间分配，其数据在Buffer Cache内存中的管理方式与用户数据一致，同样按照相同的规则写出到Undo表空间的数据文件上。Undo表空间中的存储空间同样按照Segment来分配和使用。回滚段的作用除了回退事务外，还要参与事务恢复，以及提供读一致性。
查询v$undostat看看什么时候undo data增长最快，时间太久了就没有记录了。回滚段在Undo表空间分配，其数据在Buffer Cache内存中的管理方式与用户数据一致，同样按照相同的规则写出到Undo表空间的数据文件上。Undo表空间中的存储空间同样按照Segment来分配和使用。回滚段的作用除了回退事务外，还要参与事务恢复，以及提供读一致性。
关于Undo表空间文件为什么会达到3G的数据量还是不太明白?
按书上所讲,如果在AUM模式下. 一个事务申请Undo空间的处理逻辑如下:
1: 先获取表空间可用的或空的Extents.
2: 获取其它Undo Segment里的Expired状态的Extents.
3: 如果Undo表空间的数据文件启用自动扩展,则数据文件自动扩展.
4: 如果Undo表空间的数据文件没有启用自动扩展,则获取Undo Segment里的Inactive状态的Extents.
5: 如果还没有获取可用空间,则报空间不足错误.数据库的undo_retention设置为900秒. 按理讲，就算事务太长, 也应该是先在其它 Undo Segement中取得状态为Expired状态Extents的空间. 而不是先扩展数据文件. 而Undo表空间数据文件都达到3G. 应该是绝大部份的数据状态都是Expired. 为何还不够用,而要扩展Undo表空间的数据文件? 求解