今天同事说有个项目生产环境的目录老是满。查看了一下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-00604: 递归 SQL 级别 1 出现错误
ORA-08102：未找到索引关键字，对象号 239 ,文件1,块 1674
ORA-12012: 自动执行作业 42 出错
ORA-08102：未找到索引关键字，对象号 239 ,文件1,块 1674

又根据反馈的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/<</span>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文件也不再增加。

http://www.cnblogs.com/suredandan/p/3509929.html

SQL> select owner,object_name,status from dba_objects where object_id=290;

OWNER

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

OBJECT_NAME

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

STATUS

-------

SYS

I_JOB_NEXT

VALID

SQL> conn /as sysdba

已连接。

SQL> drop index i_job_next;

索引已删除。

SQL> create index i_job_next on job$ (next_date);

索引已创建。

SQL> exec sysman.emd_maintenance.remove_em_dbms_jobs;

PL/SQL 过程已成功完成。

SQL> commit;

提交完成。

SQL> select * from dba_jobs_running;

未选定行

http://www.codesec.net/view/171688.html