关于EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS()的问题

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;问题解决!!!

时间: 2024-09-06 13:54:25

关于EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS()的问题的相关文章

EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS的删除创建

     在最近的一次优化过程中发现了ORACLE 10g中一个作业EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS执行相当频繁,其实以前也看到过,只是没有做过多 的了解和关注.这个任务在某些版本或某些情况会引起一些性能问题.其实 EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS这个作业是为Database Control收集相关数据的一个作业,如果没有使用Database Control,完全可以删除.下面是官方介绍资料  

Oracle RAC环境中EXECUTE_EM_DBMS_JOB_PROCS

今天一个客户咨询,他们的RAC环境中,EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS过程频繁启动,而且占用了大量的系统资源. 这个任务每分钟运行一次,而且每次都排在top中的前面. 这个job是EM用了维护管理工作的JOB,而这个JOB导致性能问题的相关bug也不再少数,比如Bug 7759386. 和客户确认,发现他们根本不使用EM,那么解决这个问题的最简单的办法就是删除这个维护JOB. 利用SYSMAN用户登陆执行这个SQL: SQL> conn sysm

如何查看数据库中的job任务

在数据库的日常维护中会使用job来定期完成某些任务如何查看已经定义的job呢我们可以通过如下语句 SQL> col interval format a10 SQL> col log_user format a10 SQL> col segment_user format a10 SQL> col what format a40 SQL> select job,instance,interval,next_date,   2  next_sec,failures,broken,

如何分析解读systemstat dump产生的trc文件

    ORACLE数据库的systemstat dump生成trace文件虽然比较简单,但是怎么从trace文件中浩如烟海的信息中提炼有用信息,并作出分析诊断是一件技术活,下面收集.整理如何分析解读systemstat dump产生的trace文件.     如果要人工去解读systemstat dump生成的trace文件,真是一件体力活,因为这些trace文件动不动就几百M甚至更大,它产生的跟踪文件包含了系统中所有进程的进程状态等信 息.每个进程对应跟踪文件中的一段内容,反映该进程的状态信

ORACLE--逻辑架构(一)

上一次在说到数据库体系架构时已经提及数据库逻辑架构,逻辑架构主要包含:tablespace->segment->extent->block->os-block以及datafile,也说明了其中数据文件的部分管理方式,这里接着从这里开始说起比较好:   1.系统提供每一个表空间说明 2.大文件表空间 3.表空间文件主从关系 4.EXTENTS与SEGMENTS 5.高水位线介绍 6.DELETE.TRUNCATE.DROP.SHRINK SPACE区别 7.BLOCK存储原理   付

ocp听课总结之5——表空间

1.temp表空间: temp表空间可以认为是PGA的SWAP区,这样就一下子明了了.PGA里放不下的都可以放到这个temp表空间中,来顺便回忆一下pga的结构,pga大致分为三个部分,分别是会话内存,私有sql区,游标和sql区(这个还不太了解...)这三个最重要的还是私有sql区,这部分区域占据了一个PGA的大部分空间,这里面有一个固定区域(persistent area)用来存储绑定的数据,还有就是运行时区域(runtime area)这是主要的工作区域,进行sort .hash.还有位图

DBMS_APPLICATION_INFO包的使用

DBMS_APPLICATION_INFO是一个非常有用的程序包,他提供了通过V$SESSION 跟踪脚本运行情况的能力,该包允许你在v$session中的如下三列中填值: CLIENT_INFO,MODULE,ACTION,该包不仅提供了设置这些列值的过程,还提供了 返回这些列值的过程,在CLIENT_INFO列中适合存放允许你的程序的客户端信息, MODULE列适合存放你的主程序名,如包的名称,ACTION列适合存放你的程序包中 的过程名,现在我们先简单了解一下DBMS_APPLICATIO

system表空间不足的问题分析(二)

今天收到一条不太起眼的报警邮件,大体内容是某个表空间的空间有些紧张了.大体内容如下:Tablesapce: CMBI_SNZG_DATA: 92.2%  [Warning!] 根据这个信息,很明显是需要添加数据文件了,但是同时还有一个警告就是磁盘空间也告警了,那么这个看起来简单的问题得好好琢磨琢磨了,其实是几件事,一件是做一些数据清理,释放部分表空间,甚至可以通过释放数据文件的空间来进一步释放磁盘空间,第二件是给表空间告警的表空间添加数据文件. 首先查看数据库中的用户占有的数据量的情况,可以看到