DBA手記:OEM罪幾何？-空間監控的性能問題

在某金融行業用戶的ERP數據庫中，一個小時的采樣報告，位于Elapsed Time消耗排行第二位的SQL消耗了19.41%的DB Time，該SQL同樣是OEM發出來的，其SQL

Module是Oracle

Enterprise Manager.Metric Engine，這個SQL每次執行需要245.77秒的時間，是極其緩慢的，數據庫環境是Oracle Database

10g 10.2.0.4版本：

該SQL的文本內容是：

insert into mgmt_db_size_gtt

select tablespace_name, NVL(sum(bytes) / 1048576, 0) sz

from sys.dba_free_space

group by tablespace_name

這顯然是通過dba_free_space來計算各表空間的Free空間，這個SQL同樣是OEM發出的，其執行計劃可以通過AWR獲得：

SQL> select *

from table(dbms_xplan.display_awr('4d6m2q3ngjcv9'));

insert into

mgmt_db_size_gttselecttablespace_name,NVL(sum(bytes)/1048576, 0)

sz

from

sys.dba_free_spacegroup by

tablespace_name

Plan hash value: 2413628916

---------------------------------------------------------------------------------

| Id| Operation| Name| Rows| Bytes | Cost|

---------------------------------------------------------------------------------

|0 | INSERT STATEMENT||||82 |

|1 |SORT GROUP BY||189 |5670 |82 |

|2 |VIEW|

DBA_FREE_SPACE|189 |5670 |35 |

|3 |UNION-ALL|||| |

|4 |NESTED LOOPS||68 |2584 |6 |

|5 |NESTED LOOPS||68 |2176 |6 |

|6 |TABLE ACCESS FULL| TS$|1 |23 |5 |

|7 |TABLE ACCESS CLUSTER| FET$|136 |1224 |1 |

|8 |INDEX UNIQUE SCAN|

I_FILE2|1 |6 ||

|9 |NESTED LOOPS||119 |5355 |6 |

|10 |NESTED LOOPS||119 |4641 |6 |

|11 |TABLE ACCESS FULL| TS$|19 |551 |5 |

|12 |FIXED TABLE FIXED INDEX| X$KTFBFE (ind:1)

|6 |60 |1 |

|13 |INDEX UNIQUE SCAN|

I_FILE2|1 |6 ||

|14 |NESTED LOOPS||1 |126 |20 |

|15 |NESTED LOOPS||1 |120 |20 |

|16 |NESTED LOOPS||1 |68 |3 |

|17 |TABLE ACCESS FULL| RECYCLEBIN$|1 |39 |2 |

|18 |TABLE ACCESS CLUSTER| TS$|1 |29 |1 |

|19 |INDEX UNIQUE SCAN| I_TS#|1 |||

|20 |FIXED TABLE FIXED INDEX| X$KTFBUE

(ind:1) |100 |5200 |17 |

|21 |INDEX UNIQUE SCAN| I_FILE2|1 |6 ||

|22 |NESTED LOOPS||1 |81 |3 |

|23 |NESTED LOOPS||1 |58 |2 |

|24 |NESTED LOOPS||1 |52 |2 |

|25 |TABLE ACCESS FULL| RECYCLEBIN$|1 |39 |2 |

|26 |TABLE ACCESS CLUSTER| UET$|1 |13 ||

|27 |INDEX UNIQUE SCAN| I_FILE#_BLOCK#|1 |||

|28 |INDEX UNIQUE SCAN| I_FILE2|1 |6 ||

|29 |TABLE ACCESS CLUSTER| TS$|1 |23 |1 |

|30 |INDEX UNIQUE SCAN| I_TS#|1 |||

---------------------------------------------------------------------------------

通過執行計劃可以看到，在Oracle

Database 10g引入了回收站功能后，會將回收站(RECYCLEBIN$)中的空間計算為自由空間，加入到dba_free_space字典中。

如果數據庫中存在大量的回收站對象，則這部分回收站空間的計算將會極為耗時，在這個數據庫環境中，共有5萬多個回收站對象：

SQL> select

count(*) from RECYCLEBIN$;

COUNT(*)

----------

51986

清理這些回收站對象可以大幅提升這個SQL查詢的性能，在OEM中禁用這個Metric監控則可以徹底去除這個SQL訪問。

在SQL報告中，顯示了該SQL如下的詳細信息：

在$ORACLE_HOME/rdbms/admin/catspace.sql腳本中，可以找到創建DBA_FREE_SPACE視圖的腳本：

create or replace

view DBA_FREE_SPACE

(TABLESPACE_NAME, FILE_ID, BLOCK_ID,BYTES,

BLOCKS, RELATIVE_FNO)

as

select ts.name,

fi.file#, f.block#, f.length * ts.blocksize, f.length, f.file#

from sys.ts$ ts,

sys.fet$ f, sys.file$ fi

where ts.ts# = f.ts#

and f.ts# = fi.ts# and f.file# = fi.relfile# and ts.bitmapped = 0

union all

select/*+ ordered use_nl(f) use_nl(fi) */ ts.name, fi.file#, f.ktfbfebno,

f.ktfbfeblks * ts.blocksize,

f.ktfbfeblks, f.ktfbfefno

from sys.ts$ ts,

sys.x$ktfbfe f, sys.file$ fi

where ts.ts# =

f.ktfbfetsn and f.ktfbfetsn = fi.ts# and f.ktfbfefno = fi.relfile#

and ts.bitmapped <> 0 and ts.online$ in

(1,4) and ts.contents$ = 0

union all

select /*+ ordered use_nl(u) use_nl(fi) */ ts.name,

fi.file#, u.ktfbuebno,

u.ktfbueblks * ts.blocksize,

u.ktfbueblks, u.ktfbuefno

from sys.recyclebin$ rb, sys.ts$ ts,

sys.x$ktfbue u, sys.file$ fi

where ts.ts# =

rb.ts# and rb.ts# = fi.ts# and u.ktfbuefno = fi.relfile#

and u.ktfbuesegtsn = rb.ts# and

u.ktfbuesegfno = rb.file# and u.ktfbuesegbno = rb.block#

and ts.bitmapped <> 0 and ts.online$ in

(1,4) and ts.contents$ = 0

union all

select ts.name,

fi.file#, u.block#,u.length * ts.blocksize, u.length, u.file#

from sys.ts$ ts,

sys.uet$ u, sys.file$ fi, sys.recyclebin$

rb

where ts.ts# = u.ts#

and u.ts# = fi.ts# and u.segfile# = fi.relfile#

and u.ts# = rb.ts# and u.segfile# = rb.file#

and u.segblock# = rb.block# and ts.bitmapped

= 0

/

以上腳本中，后面兩個UNION

ALL查詢塊是Oracle 10g引入的，并且為了修正這個視圖帶來的Bug，Oracle一直不停的在改進視圖語句。注意視圖中Hints的制定對于執行計劃的強制影響。

我們要時刻牢記的是：當Oracle引入了某個新功能之后，同時也會引入很多問題，所以在使用新功能、新特性時要加強監控，及時發現和解決可能出現的問題。

By eygle on 2011-02-21 08:30 |

Comments (2) |

Case | 2731 |

2 Comments

曾經，我說的是曾經。

一套跑在p595滿配上的10g rac系統

因為有了GC來監控，直接宕機

從此以后，所有的服務器上不準用GC

總結

以上是生活随笔為你收集整理的oracle oem 监控,DBA手记:OEM罪几何？-空间监控的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。