Oracle修复损坏定时任务(Jobs)步骤

Oracle数据库中的定时任务（Job）偶尔会出现运行异常，状态显示为“损坏”（Broken）。这种情况通常有标准处理流程，按照以下步骤操作，大多数情况下可以恢复。

诊断：Job 23为何变为损坏状态

当Job连续多次执行失败时，系统会自动将其标记为损坏。FAILURES次数累积到一定阈值后，Oracle为了保护资源会暂停该Job。根本原因通常是Job调用的存储过程、SQL语句或内部逻辑出现错误。换句话说，Job本身并非主动罢工，而是因为无法正常执行而被系统暂停。

修复：三步恢复Job 23正常运行

以下操作覆盖大部分损坏场景，按顺序执行即可。

第一步：查找具体错误原因

首先需要确认失败原因。执行以下SQL语句，可以查看Job 23的详细信息，重点关注最后一次执行失败的错误代码（LAST_ERR）。

-- 查看Job 23的详细信息
SELECT JOB, WHAT, LAST_DATE, NEXT_DATE, INTERVAL, FAILURES, BROKEN, LAST_ERR
FROM DBA_JOBS WHERE JOB = 23;

重点查看两列：

• FAILURES：失败次数，数值较大说明问题已持续较长时间。
• LAST_ERR：最后一次执行失败时Oracle返回的错误代码。例如，ORA-00942表示“表或视图不存在”；ORA-06550通常表示PL/SQL语法错误。

第二步：修复Job内部逻辑

根据错误代码定位问题。Job 23的WHAT列中记录的是其要执行的代码（例如一个存储过程SDHXEM_MDI_TEMP;）。需要登录数据库，找到对应的PL/SQL代码或存储过程，修正其中的语法错误、权限问题或引用的不存在的对象。这一步虽然繁琐，但必须完成——仅清除损坏标记而不修复底层代码，下次执行时仍会失败。

第三步：手动清除损坏标记

底层逻辑修复后，手动执行一次Job，成功后损坏标记通常会自动清除。执行以下命令：

-- 手动运行Job 23
BEGIN
  DBMS_JOB.RUN(23);
  COMMIT;
END;/

如果手动执行成功，再次查询DBA_JOBS，会发现BROKEN列变为N，FAILURES归零。若手动运行后损坏标记仍未清除，则强制清除：

-- 强制清除损坏标记
BEGIN
  DBMS_JOB.BROKEN(23, FALSE);
  COMMIT;
END;/

重要注意事项

• 务必提交事务：使用DBMS_JOB包执行RUN或BROKEN操作后，必须执行COMMIT;，否则更改不会持久保存。
• 检查后台进程：确认数据库的Job队列进程是否启用：SHOW PARAMETER JOB_QUEUE_PROCESSES;，该参数值必须大于0，否则Job无法运行。

先执行第一步，查看LAST_ERR中的具体错误代码。如果确定错误原因但不确定如何修复，可以将错误代码提供出来，一起分析解决。