一、UNDO表空间监控图
Prometheus监控的到UNDO表空间使用率超过90%(90%为所有表空间告警阈值)。从图中可以看到，多次增加UNDO表空间的DATAFILE，UNDO表空间达到40GB，没过多久UNDO使用率又会超过90%
二、查看UNDO块的使用情况
select s.STATUS,sum(s.BYTES)/1024/1024 from DBA_UNDO_EXTENTS s group by s.STATUS;
UNDO表空间当前没有ACTIVE的UNDO段，但是存在大量的UNEXPIRED的UNDO段。
UNEXPIRED的占到总空间的81%，但Oracle并没有及时的释放这些空间。
三、查看undo_retention
undo_retention设置为900s（15分钟），但是平时数据库不存在大量事务，900s时间也不可能使用大量的UNDO段。
四、查看V$UNDOSTAT
但从Oracle 10gR2开始，默认Oracle都开启了UNDO表空间的自动调整功能，查找V$UNDOSTAT.TUNED_UNDORETENTION发现最近一段时间该值都被自动调整到了800000多秒，也就是说UNDO表空间中的数据要保留接近10天才会过期，正是因为这么长的数据未过期时间，且表空间又足够的大，才导致了UNDO表空间的空间一致未被释放。
Oracle官方解释：
Why TUNED_UNDORETENTION is calculated so high making undo space grow fast ?
When non-autoextensible undo space is used, tuned_undoretention is calculated based on a percentage of the undo tablespace size. In some cases especially with large undo tablespace, This will make it to be calculated so large.
简单的说，就是当UNDO表空间对应的数据文件非自动扩展，且UNDO表空间又比较大的时候，tuned_undoretention的值是根据UNDO表空间大小的百分比来计算的，在一些情况下会将tuned_undoretention的值调整得特别大。
五、处理方法
将UNDO表空间的数据文件设置为自动扩展。
alter database datafile '/u02/paydb/oradata/undotbs01.dbf' autoextend on maxsize 10G;
其实数据文件已经是10GB，这样做的目的就是为了让表空间自动扩展属性被打开，但是不会在扩展了。