公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-12-27 23:43:42 · 原文链接

今天开发的同学小窗口消息给我，向我咨询一个ORA错误的问题。

错误代码是ORA-30036，使用oerr ora 30036查看，由于是undo空间无法扩展导致。

这是一个统计业务的数据库，而且平时的负载其实并不高，确实有一些奇怪。首先排除了大事务导致的原因，查看数据库日志，和开发同学沟通，没有发现相关的错误信息。

所以第一感觉这是一个偶然发生的情况，不过开发的这位同学貌似碰到了问题，他说从应用端抛出了ORA-30036的错误。

java.sql.BatchUpdateException:ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'?
问题刚刚发生，问题确凿，说明插入数据出了问题。但是比较奇怪的是，我在环境中简单模拟了一下，却没有碰到这类问题。把数据量提升到百万还是可以成功。

和开发的同学做了确认，他发过来了执行失败的语句，这是一个看起来很简单的语句,当然我做了简单的脱敏。

insert into user_hh_max(id, stat_time, appkey) select seq_user_hh.nextval id, :1 stat_time, :2 appkey from dual;

 这样一个看似非常简答的INSERT看起来无论如何也不会导致很严重的性能问题，这一点我是深信不疑。除了序列的自增外，其它的地方我是真没看出来有什么性能隐患。

带着疑问，我看了下最近的数据库负载，都在正常的范围之内。查看归档的切换频率，发现问题看起来不是那么简单。

下面的图示，横轴是小时，纵轴是日期，这样就能够看到每个小时的归档切换情况，发现近些天来归档的切换频率比以前有了极大的提高。简单来说，以前基本上是一个小时2~3G的归档量，现在一下子变成了20~30G,而且还有增加的趋势。

得到了这样一个报告，让我对原本看起来不痛不痒的问题变得严峻起来，而且应用端确实有些统计出现了问题，希望我帮忙能先修复一下，这种情况下，我先扩容了Undo空间，然后静下心来分析这个奇怪的问题。