我要评论修复已损坏定时任务，可根据下面步骤进行恢复
诊断：为什么job 23会损坏？
一个job被标记为“损坏”(broken)，最常见的原因是它连续多次执行失败（failures次数累积）。这通常是因为它调用的存储过程、sql语句或内部逻辑出了错，系统为了保护资源，自动将其暂停。
修复：三步让job 23恢复正常
你可以按照下面的步骤来修复它：
第一步：找出病因（查看具体错误）
首先，我们需要知道是什么错误导致了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，就表示是“表或视图不存在”的错误）。
第二步：釜底抽薪（修复job内部逻辑）
根据第一步查出的错误，你需要去修复job 23内部调用的what内容（比如是一个存储过程sdhxem_mdi_temp;）。这通常意味着你需要：
- 登录到数据库，找到job 23所执行的pl/sql代码或存储过程。
- 修正其中的sql语法错误、权限问题或引用了不存在的对象。
- 这个过程需要在数据库内部完成，你需要有相应的权限去修改这些数据库对象。
第三步：手动唤醒（清除损坏标记）
当底层的代码逻辑被修复后，我们就可以“唤醒”这个沉睡的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里具体是哪个错误代码。如果查到了具体的错误但不确定如何修复，可以把错误代码发给我，我帮你看看～
以上就是oracle修复已损坏定时任务(jobs)的方法步骤的详细内容，更多关于oracle修复已损坏定时任务的资料请关注代码网其它相关文章！
发表评论