一，问题描述：

早晨点检双节点ORACLE 10.2.0.5 RAC数据库发现undo(AUM模式)表空间在不断扩展:

时间：2011/07/07 07:50

Undo表空间使用情况：

(undotbs1:容量27G,利用率78%; undotbs2:容量26G,利用率84%)

二，初步分析：

 起初怀疑是存在对大数据量进行DML操作，而使Oracle数据库产生大量的回滚数据以支持多版本，保障数据一致性；查看v$session_longops视图未发现长时间操作对象；

然后做出AWR报表，分析TOP 5事件和查看sql_statistics信息，并未发现异常状况，同时查看v$transaction视图也未发现大量并行操作事务；难道又遇到BUG了！

查看undo表空间面前使用率：

时间：2011/07/07 08:30

Undo表空间使用情况：

(undotbs1:容量27G,利用率82%; undotbs2:容量26G,利用率85.6%)

UNDO 表空间还在增长，并没有收缩！在这样下去，数据库会出现latch / US enqueue contention, 严重影响性能甚至崩溃！

三，原因探索

查看v$undostat视图发现一下异常：

Sql> select begin_time,txncount,maxquerylen,

unexpiredblks,expiredblks,tuned_undoretention

from v$undostat

order by begin_time;

  begin_time,txncount,maxquerylen,unexpiredblks,expiredblks,tuned_undoretention

  … …

  … …

… …

     顺便提到, 本数据库undo_retention参数设定为3小时(10800)，也即是undo blocks会在10800s后自动回收reused, 同时V$UNDOSTAT.TUNED_

UNDORETENTION值应为10800，但是从2011/07/06 下午 12:01:57开始tuned_undoretention值就在不断增加，阻止undo blocks过期，查看dba_undo_extents视图，发现以下异常：

Sql> select count(*) from dba_undo_extents

    where status in ('ACTIVE','UNEXPIRED')

    and tablespace_name='UNDOTBS1'

count(*)

3327

Sql> select count(*) from dba_undo_extents

    where status in ('ACTIVE','UNEXPIRED')

    and tablespace_name='UNDOTBS2'

count(*)

3112

对比正常状态下的数据:

Sql> select count(*) from dba_undo_extents

    where status in ('ACTIVE','UNEXPIRED')

    and tablespace_name='UNDOTBS1'

count(*)

146

查看undo表空间当前使用率：

时间：2011/07/07 09:20

Undo表空间使用情况：

(undotbs1:容量27G,利用率86.4%; undotbs2:容量26G,利用率92%)

    看来数据库真正遇到大问题了，立刻去MOS上寻找案例！

四，根本原因与问题解决

    在MOS上找到以下类似案例ID 7291739.8, 并且找到对应Bug: 7291739;

按照临时解决方案：

Disable auto tuning by setting "_undo_autotune" = false

SQL> Alter system set "_undo_autotune" = false;

等待十几分钟后，查看undo表空间面前使用率：

时间：2010/11/09 10:30

Undo表空间使用情况：

(undotbs1:容量27G,利用率64%; undotbs2:容量26G,利用率73%)

五，总结

按MOS文件描述, 此异常应该在ORACLE 10.2.0.5已经修复了, 看来有可能又一次是Oracle的”伪修复”… …