Oracle恢复已损坏定时任务(Jobs)

修复已损坏定时任务，可根据下面步骤进行恢复

诊断：为什么Job 23会损坏？

一个Job被标记为"损坏"(Broken)，最常见的原因是它连续多次执行失败（FAILURES次数累积）。这通常是因为它调用的存储过程、SQL语句或内部逻辑出了错，系统为了保护资源，自动将其暂停。

修复：三步让Job 23恢复正常

你可以按照下面的步骤来修复它：

1. 第一步：找出病因（查看具体错误）

   首先，我们需要知道是什么错误导致了Job失败。通过以下SQL语句，可以查看Job 23的详细信息和最近一次执行失败的错误代码（LAST_ERR或查看数据库的告警日志alert.log）。

   -- 查看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，就表示是"表或视图不存在"的错误）。

2. 第二步：釜底抽薪（修复Job内部逻辑）

   根据第一步查出的错误，你需要去修复Job 23内部调用的WHAT内容（比如是一个存储过程SDHXEM_MDI_TEMP;）。这通常意味着你需要：

   • 登录到数据库，找到Job 23所执行的PL/SQL代码或存储过程。
   • 修正其中的SQL语法错误、权限问题或引用了不存在的对象。
   • 这个过程需要在数据库内部完成，你需要有相应的权限去修改这些数据库对象。

3. 第三步：手动唤醒（清除损坏标记）

   当底层的代码逻辑被修复后，我们就可以"唤醒"这个沉睡的Job了。最直接的方法是手动执行一次，成功后，损坏标记通常会被自动清除。

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

   如果手动执行成功，你再查询 DBA_JOBS，应该会看到 BROKEN 列变为了 N，FAILURES 变为了 0。

   如果手动执行后损坏标记依然存在，可以执行强制修复命令：

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

重要提醒

• 别忘了提交 ：在使用DBMS_JOB包进行操作（如RUN、BROKEN）后，一定要执行COMMIT;，否则更改不会生效。
• 检查进程 ：正如我们上次讨论的，也顺便确认一下数据库的Job队列进程是开启的：SHOW PARAMETER JOB_QUEUE_PROCESSES;，这个参数值必须大于0。

你可以先执行第一步，看看LAST_ERR里具体是哪个错误代码。如果查到了具体的错误但不确定如何修复，可以把错误代码发给我，我帮你看看～