解决因为I_JOB_NEXT问题导致job执行不正常,不停生成trace文件问题

今天同事说有个项目生产环境的目录老是满。查看了一下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文件也不再增加。

上一篇:Android中的六大布局


下一篇:将List 中的ConvertAll的使用:List 中的元素转换,List模型转换, list模型转数组