通過shell腳本來檢視Undo中資源消耗高的sql

在檢視undo的使用率的時候,在Undo_management為auto的時候，經常會看到undo自己在不斷的伸縮擴充，自我調節。

有時候看到Undo收縮的很緊,就想知道哪些sql語句在運作，可能有哪些潛在的問題。對于線上業務系統而言，如果某一條sql語句運作時間較長,而且消耗的undo資源極高的情況下,sql語句很可能是有問題的。

可以通過如下的sql語句來簡單定位，找到一個sql_id清單，可以看到每個sql_id消耗的Undo資源情況。

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進行一定範圍内的監控，相信會有一定的收獲。