關於EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS()的問題

lfree發表於2006-12-14

http://www.itpub.net/showthread.php?threadid=684486

select * from v$version
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - Production

前幾天使用者反映系統有點慢,但是不是很明顯,我們使用兩臺機器帶rac,我這幾天一直再查,我發現引起問題的是每分鐘執行的這個東西。EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS()

從toad看如圖,從圖中看,buffer gets很高,call rates也很高,我ssh進入linux,使用top看,發現大約一定的時間(1分鐘),有一個oracle程式cpu使用率會上升到99%。

執行 ps -ef | grep pid 檢查發現,程式是ora_j000_xxx1, 確定是這個job引起的。

我看一些相關文件,這個應該是與ADDM/AWR有關,我停止了這個job。
我發現另外一個奇怪的問題,如果我在一個例項上停止這個job,在另外一個例項看還是正常的。

查詢metalink,發現相似的文件: doc id:308291.1。

Symptoms
One of the databases has an issue with dbms job.
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS
Earlier you have been runnung sppurge.sql and removed all of statspack snapshots (for the
prior month) as the tools tablespace was almost full.
After that the
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS process started eating up the
CPU on of the monitored DB 10g.
Cause
Statspack caused an issue with EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS
process
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS process on the remote 10g DB
should not be running because grid monitors the 10g DB, not the db console

建立解決方法,我採用的是:

以sysman使用者登陸,執行exec emd_maintenance.remove_em_dbms_jobs;問題解決!!!


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-82949/,如需轉載,請註明出處,否則將追究法律責任。

相關文章