共计 1307 个字符，预计需要花费 4 分钟才能阅读完成。
五一假期期间接到运维同学的微信，说应用报错了，跟数据库有关的，发过来截图一看报错的信息是 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：
从 10.2 版本开始，Oracle 默认采用自动调整 undo retention 的方法
根据你 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 小时），应用恢复正常。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-05/143517.htm
