五一假期期间接到运维同学的微信，说应用报错了，跟数据库有关的，发过来截图一看报错的信息是could not get next sequence value。以为是某个sequence达到了最大值，让帮忙查是哪个sequence。
于是查了dba_sequences，没有哪个sequence达到了最大值。
于是看session的信息，查询v$session中的等待事件，发现有大量的等待事件是“latch: undo global data”。从事件名字上来看应该是undo的问题。
查询undo表空间的使用率，果然到了100%。但undo是可以重复使用的，除非有非常大的事务占满了整个undo表空间，undo表空间有460多G，占满的可能性不大。
上网搜了latch: undo global data相关的文章，有一个提到MOS上的一篇文档："LATCH: UNDO GLOBAL DATA" In The Top Wait Events (文档 ID 1451536.1)
文档中介绍这个等待事件意味着大量的session在试图找到新的undo extent和偷取未过期的undo extents。这个等待和隐含参数_undo_autotune设置为FALSE情况下的UNDO空间不足有关。
当前数据库的_undo_autotune确实为FALSE，而且undo_retention=259200，换算下来就是72小时。
先认识一下隐含参数_undo_autotune：
根据你undo tablespace的大小以及系统的繁忙程度(v$undostat中信息）自动调整undo_retention参数，所以在10g的数据库上你会经常发现undo tablespace永远是满的，因为当你undo tablespace有空闲空间时，系统自动调大undo_retention来保留更多的undo blocks。这一方法有利于时间长的查询，但是对于典型的OLTP系统来说不太适用。因为OLTP上不太可能跑如此长时间的查询，而且在很繁忙的 OLTP上还会导致上面所遇到的问题。
_undo_autotune=true时，undo_retention不再适用。而_undo_autotune=false时，undo_retention按设置的时间保留。
通过上面的解释，再加上五一假期期间在做数据清理工作，大量的undo被保留72小时，最终导致了undo表空间爆满，应用无法正常访问。
解决方法：
1、设置_undo_autotune=true，可以在线修改
2、增加undo表空间大小(resize现有数据文件或增加数据文件)
3、调小undo_retention参数
最终调小了undo_retention参数设置为43200（12小时），应用恢复正常。