五一假期期间接到运维同学的微信,说应用报错了,跟数据库有关的,发过来截图一看报错的信息是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小时),应用恢复正常。


参考:http://blog.itpub.net/4227/viewspace-1060723/

http://blog.csdn.net/dba_waterbin/article/details/8646982