在查看undo的使用率的时候,在Undo_management为auto的时候，经常会看到undo自己在不断的伸缩扩展，自我调节。
有时候看到Undo收缩的很紧,就想知道哪些sql语句在运行，可能有哪些潜在的问题。对于在线业务系统而言，如果某一条sql语句运行时间较长,而且消耗的undo资源极高的情况下,sql语句很可能是有问题的。
可以通过如下的sql语句来简单定位，找到一个sql_id列表，可以看到每个sql_id消耗的Undo资源情况。
sqlplus -s $DB_CONN_STR@$SH_DB_SID set pages 53
select sum(undoblks)*8/1024 total_size_MB from v\$undostat ;
select *from (
select maxqueryid,
round(sum(undoblks )*8/1024) consumed_size_MB
from v\$undostat group by maxqueryid order by consumed_size_MB desc
) where rownum EOF
Exit
脚本运行结果如下：
TOTAL_SIZE_MB
-------------
70299.2188
MAXQUERYID CONSUMED_SIZE_MB
------------- ----------------
7wx3cgjqsmnn4 39990
210ndtcx5fwgs 20738
648600hq1s1s8 5795
cjqdgd14xjwjm 1116
4ad8ypr3nf6vm 869
0my2xfpqrk6gw 597
f3pq3mdycwcd2 455
cwp9zk1y7cthy 312
ddtx15a9nzmjt 139
csrj5pnpx4wtr 72
6tshctswzutbk 49
3a4vsqkf8yaxs 49
gpzkq2kv9vhan 27
fa311gg43yjyf 21
cysbbg2h86xc6 19
fjzknc02f7019 18
aty7a3bvqfxxx 17
ftmvqxfzq1fv0 16
可以看到sql_id为7wx3cgjqsmnn4 的sql 消耗资源情况最严重,很有可能存在一定的性能问题。在查看执行计划后发现,确实如此。
具体的细则就不罗列了,此处略去几百字。
总之通过undo的使用情况来查看可能存在的性能sql也是一种方式。当然了undo的使用情况是频繁变更的，可以根据自己的情况来对undo进行一定范围内的监控，相信会有一定的收获。
