今天同事说有个项目生产环境的目录老是满。查看了一下bdump目录，发现确实是平均1分钟生成一个8M左右的trace文件。查询了一下alert日志，发现是个job的报错引起的。具体查看了一下trace文件，可以查找到具体的job号。

首先去查询了一下dba_jobs，发现这个job的描述是EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS。这个job是sysman用户的用于收集em相关信息的，可以考虑把这个job先停了。执行命令如下：

EXEC DBMS_JOB.BROKEN(job#,TRUE);

发现执行上述命令后，要报错：

ORA: 递归 SQL 级别  出现错误
ORA：未找到索引关键字，对象号  ,文件1,块
ORA: 自动执行作业  出错
ORA：未找到索引关键字，对象号  ,文件1,块 

又根据反馈的obj#，查询了一下dba_objects，发现是对象I_JOB_NEXT，类型为index，它所属的表为job$。查询了下mos，发现有个文章对此有描述ORA-08102: TRYING TO MANIPULATE A JOB IN DBA_JOBS (文档 ID 1036858.6)：

You are trying to manipulate a job in the job queue
(DBA_JOBS/USER_JOBS) and you receive:

ORA-08102: index key not found, object...
Cause: Internal error: possible inconsistency in index
Action: Send trace file to your customer support representative, along
with information on reproducing the error8102: TRYING TO MANIPULATE A JOB IN DBA_JOBS (文档 ID 1036858.6)

根据文章上的操作来执行：

Solution Description:
=====================

You need to recreate the inex I_JOB_NEXT.

Script "$ORACLE_HOME/rdbms/admin/cat7103.sql" creates the I_JOB_NEXT:

Drop and recreate this index.

connect sys/<password>
drop index i_job_next;
create index i_job_next on job$ (next_date)

Note: alter index I_JOB_NEXT rebuild; Will not fix the problem.

执行完之后上述脚本重建i_job_next 后，发现在alert日志中，该job的报错已经不再出现，trace文件也不再增加。