一环境跑压力测试的时候，标题所述等待事件在top N中。不用查，也知道是因为undo竞争的事件。
根据metalink文档解释，是由于undo表空间不足引起的。
This implies that sessions are struggling to find new undo extents and are having to steal.
"ktusm_stealext_2" is used to steal undo extents. As _undo_autotune is FALSE then the undo retention should be static.
In conclusion, this problem could occur if available undo space is not enough.
"ktusm_stealext_2" is used to steal undo extents. As _undo_autotune is FALSE then the undo retention should be static.
In conclusion, this problem could occur if available undo space is not enough.
说明这个等待和隐含参数_undo_autotune设置为FALSE情况下的UNDO空间不足有关
当前数据库确实关闭了_undo_autotune功能。且LATCH undo global data最多的等待发生在ktusm_stealext: KSLBEGIN处，这说明会话在寻找新的UNDO EXTENTS时，不得不Steal未过期的UNDO EXTENTS。
解决方案有三个：减少UNDO_RETENTION参数设置的时间长度；增加UNDO_TABLESPACE的空间大小；将_undo_autotune隐含参数设置为TRUE。