一,问题描述:
早晨点检双节点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
… …
07/06/2011 11:21:57 | 21,288 | 7,999 | 393,352 | 474,880 | 10800 |
07/06/2011 11:31:57 | 28,494 | 8,600 | 378,760 | 498,944 | 10800 |
07/06/2011 11:41:57 | 17,746 | 9,201 | 385,800 | 513,408 | 10800 |
07/06/2011 11:51:57 | 30,349 | 9,803 | 375,688 | 533,248 | 10800 |
07/06/2011 12:01:57 | 24,125 | 10,404 | 385,544 | 542,848 | 11184 |
07/06/2011 12:11:57 | 23,797 | 11,005 | 405,768 | 532,608 | 11725 |
07/06/2011 12:21:57 | 31,482 | 11,606 | 420,616 | 510,976 | 12326 |
07/06/2011 12:31:57 | 21,492 | 12,207 | 441,352 | 507,008 | 12927 |
… …
07/07/2011 07:53:40 | 5,231 | 218,597 | 882,944 | 39,032 | 219,317 |
07/07/2011 08:03:40 | 8,326 | 219,199 | 883,968 | 40,056 | 219,919 |
07/07/2011 08:13:40 | 7,404 | 219,800 | 886,016 | 40,056 | 220,520 |
07/07/2011 08:23:40 | 9,087 | 220,401 | 887,040 | 41,080 | 221,122 |
07/07/2011 08:33:40 | 8,397 | 221,003 | 893,184 | 39,032 | 221,723 |
07/07/2011 08:43:40 | 10,338 | 221,604 | 894,208 | 39,032 | 222,325 |
07/07/2011 08:53:40 | 10,479 | 222,206 | 896,256 | 39,032 | 222,926 |
… …
顺便提到, 本数据库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的”伪修复”… …