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