记一次ORACLE的UNDO表空间爆满分析过程

这篇文章是记录一次ORACLE数据库UNDO表空间爆满的分析过程，主要整理、梳理了同事分析的思路。具体过程如下所示：

早上收到一数据库服务器的UNDO表空间的告警邮件，最早一封是7：55发出的（监控作业是15分钟一次），从告警邮件分析，好像是UNDO表空间突然一下子被耗尽了。

DB	Tablespace	Allocated	Free	Used	%Free	%Used
192.168.xxx.xxx:1521	UNDOTBS1	16384	190.25	16193.75	1.16	99

使用一些SQL分析了undo表空间使用情况，以及undosegment状态等等，非常想定位到是哪个或那些SQL耗尽了UNDO表空间，但是没有一个SQL能实现我的想法，抑或是我不了解。

SELECTUPPER(F.TABLESPACE_NAME)AS"TABLESPACE_NAME",

ROUND(D.MAX_BYTES,2)AS"TBS_TOTAL_SIZE",

ROUND(D.AVAILB_BYTES,2)AS"TABLESPACE_SIZE",

ROUND(D.MAX_BYTES-D.AVAILB_BYTES+USED_BYTES,2)AS"TBS_AVABLE_SIZE",

ROUND((D.AVAILB_BYTES-F.USED_BYTES),2)AS"TBS_USED_SIZE",

TO_CHAR(ROUND((D.AVAILB_BYTES-F.USED_BYTES)/D.AVAILB_BYTES*100,

2),

'999.99')AS"USED_RATE(%)",

ROUND(F.USED_BYTES,6)AS"FREE_SIZE(G)"

FROM(SELECTTABLESPACE_NAME,

ROUND(SUM(BYTES)/(1024*1024*1024),6)USED_BYTES,

ROUND(MAX(BYTES)/(1024*1024*1024),6)MAX_BYTES

FROMSYS.DBA_FREE_SPACE

GROUPBYTABLESPACE_NAME)F,

(SELECTDD.TABLESPACE_NAME,

ROUND(SUM(DD.BYTES)/(1024*1024*1024),6)AVAILB_BYTES,

ROUND(SUM(DECODE(DD.MAXBYTES,0,DD.BYTES,DD.MAXBYTES))/(1024*1024*1024),6)MAX_BYTES

FROMSYS.DBA_DATA_FILESDD

GROUPBYDD.TABLESPACE_NAME)D

HERED.TABLESPACE_NAME=F.TABLESPACE_NAME

ANDD.TABLESPACE_NAME=&UNDO_TABLESPACE_NAME

RDERBY5DESC;

selectusn,xacts,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks

fromv$rollstatorderbyrssize;

既然直接入手，无法定位，那就曲线分析，首先检查、分析了一下redolog，发现在7点这段时间，日志切换了83次之多，横向、纵向对比，明显异常，如下截图所示：

SELECT

TO_CHAR(FIRST_TIME,'YYYY-MM-DD')DAY,

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'00',1,0)),'99')"00",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'01',1,0)),'99')"01",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'02',1,0)),'99')"02",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'03',1,0)),'99')"03",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'04',1,0)),'99')"04",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'05',1,0)),'99')"05",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'06',1,0)),'99')"06",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'07',1,0)),'99')"07",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'08',1,0)),'99')"0",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'09',1,0)),'99')"09",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'10',1,0)),'99')"10",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'11',1,0)),'99')"11",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'12',1,0)),'99')"12",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'13',1,0)),'99')"13",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'14',1,0)),'99')"14",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'15',1,0)),'99')"15",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'16',1,0)),'99')"16",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'17',1,0)),'99')"17",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'18',1,0)),'99')"18",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'19',1,0)),'99')"19",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'20',1,0)),'99')"20",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'21',1,0)),'99')"21",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'22',1,0)),'99')"22",

TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'23',1,0)),'99')"23"

FROM

V$LOG_HISTORY

GROUPBY

TO_CHAR(FIRST_TIME,'YYYY-MM-DD')

ORDERBY1DESC;

生成了实例在7:00~8:00时间段的AWR报告，从下面指标我们可以看出，数据库实例在这段时间呢，其实是非常空闲的，因为DBTime为9.74（mins)

另外，从TimeModelStatistics部分来看，主要时间花在backgroundelapsedtime，而不是DBTime,我们可以判断时间主要耗费在后台进程，而不是前台进程。另外sqlexecuteelapsedtime耗用了DBTime的70.36的时间。

然后我们来看SQLorderbyGets部分信息,第一个SQL是删除WRH$_SQL_PLAN的记录，当然也有删除wrh$_sqltext、WRH$_SEG_STAT_OBJ表记录的SQL，如下所示

DELETE

FROMWRH$_SQL_PLANtab

WHERE(:beg_snap<=tab.snap_id

ANDtab.snap_id<=:end_snap

ANDdbid=:dbid)

ANDNOTEXISTS

(SELECT1

FROMWRM$_BASELINEb

WHERE(tab.dbid=b.dbid)

AND(tab.snap_id>=b.start_snap_id)

AND(tab.snap_id<=b.end_snap_id)

)

DELETE

FROMwrh$_sqltexttab

WHERE(tab.dbid=:dbid

AND:beg_snap<=tab.snap_id

ANDtab.snap_id<=:end_snap

ANDtab.ref_count=0)

ANDNOTEXISTS

(SELECT1

FROMWRM$_BASELINEb

WHERE(b.dbid=:dbid2

ANDtab.snap_id>=b.start_snap_id

ANDtab.snap_id<=b.end_snap_id)

);

DELETE

FROMWRH$_SEG_STAT_OBJtab

WHERE(:beg_snap<=tab.snap_id

ANDtab.snap_id<=:end_snap

ANDdbid=:dbid)

ANDNOTEXISTS

(SELECT1

FROMWRM$_BASELINEb

WHERE(tab.dbid=b.dbid)

AND(tab.snap_id>=b.start_snap_id)

AND(tab.snap_id<=b.end_snap_id)

);

查看SQLorderedbyReads部分信息，发现主要也是删除系统表WRH$_SQL_PLAN记录（这个表是非常大的）

DELETE

FROMWRH$_SQL_PLANtab

WHERE(:beg_snap<=tab.snap_id

ANDtab.snap_id<=:end_snap

ANDdbid=:dbid)

ANDNOTEXISTS

(SELECT1

FROMWRM$_BASELINEb

WHERE(tab.dbid=b.dbid)

AND(tab.snap_id>=b.start_snap_id)

AND(tab.snap_id<=b.end_snap_id)

)

然后我们查看AWR报告的TablespaceIOStats部分，IO主要集中在SYSAUX,UNDOTBS1这两个表空间，然后你会发现那个表WRH$_SQL_PLAN就是在SYSAUX下

所以，上面种种证据显示，让我们几乎可以断定主要是下面这个SQL导致了UNDO表空间使用的暴增。当然分析过程中，还有一些旁听佐证。在此感觉没有必要一一列举了。

DELETE

FROMWRH$_SQL_PLANtab

WHERE(:beg_snap<=tab.snap_id

ANDtab.snap_id<=:end_snap

ANDdbid=:dbid)

ANDNOTEXISTS

(SELECT1

FROMWRM$_BASELINEb

WHERE(tab.dbid=b.dbid)

AND(tab.snap_id>=b.start_snap_id)

AND(tab.snap_id<=b.end_snap_id)

)

作者：潇湘隐者
出处：http://www.cnblogs.com/kerrycode/