资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/JOB不自动运行的排查方法

JOB不自动运行的排查方法

IT那活儿 / 3131人阅读
JOB不自动运行的排查方法
点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

  
事件起因是这样的，有一套12.1.0.1的库，应用人员多次反应JOB不自动运行，手动调用JOB的存储过程却是正常的。
检查数据库发现，数据库的作业队列进程Jnnn产生等待事件“enq: JD - contention”，收集相关信息提交SR分析后，得出结论是实例2上的作业队列调度进程CJQ0阻塞了实例1上的J010等进程的会话，而CJQ0本身在等待并行从属进程的加入响应，在PX Deq: Join ACK等待上夯了 147 min 46 sec。
也就是说CJQ0进程被阻塞，进而阻塞了Jnnn进程，导致JOB无法调度。


一

解决过程

SR方面，怀疑是“Bug 27223075 - Wait for PX Deq: Join Ack when no active QC but PPA* slaves show as busy”，建议是升级数据库到19C或者定期重启。
确实，12.1不是一个长期稳定版本，bug也确实比较多，但生产环境，岂是说升级就升级的，虽然这套库不是核心库，但也不是能随便折腾的。
无奈之下，当晚联系业务重启数据库后，问题暂时得到解决。好景不长，几天过后，类似问题又重现，但我总不能每次遇到这个问题都去重启数据库吧。
既然是CJQ0的问题，是否可以考虑重新启动一下CJQ0进程呢，CJQ0这种非核心进程，杀掉之后，数据库会自动拉起。

于是，通过ps -ef|grep ora_cjq0找到spid，直接kill之后，观察到数据库自动拉起了CJQ0进程，一段时间之后，JOB恢复了正常调度。

二

常见排查方法

根据MOS上的文章Jobs Not Executing Automatically (Doc ID 313102.1)，对JOB不自动执行的情况，列举了可能的原因排查方法：

2.1 Instance in RESTRICTED SESSIONS mode

检查实例是否为受限模式：
select instance_name,logins from v$instance;
If logins=RESTRICTED, then:
alter system disable restricted session;

2.2 JOB_QUEUE_PROCESSES=0

确认参数大于0。
show parameter job_queue_processes

2.3 _SYSTEM_TRIG_ENABLED=FALSE

确认参数“_system_enabled_trigger”是否为false：
col parameter format a25
col value format a15
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv b
where a.indx=b.indx and ksppinm=_system_trig_enabled;
如果_system_trig_enabled=false,则
alter system set "_system_trig_enabled"=TRUE scope=both;

2.4 Is the job BROKEN?

select job,broken from dba_jobs where job=;
如果JOB为broken，检查相关日志确认原因。

2.5 Is the job COMMITTED?

确认提交JOB之后是否缺少commit：
DECLARE X NUMBER;
BEGIN
SYS.DBMS_JOB.SUBMIT
(
job => X
,what => dbms_utility.analyze_schema
(SCOTT,COMPUTE,NULL,NULL,NULL);
,next_date => to_date(08/06/2005 09:35:00,dd/mm/yyyy hh24:mi:ss)
,no_parse => FALSE
);
COMMIT;
END;
/

If the job executes fine if forced (i.e., exec dbms_jobs.run();), then likely a commit
is missing.

2.6 UPTIME > 497 days

确认服务器主机是否已运行超过497天：
For SUN, use uptime OS command.

在oracle老版本9i和10g中，如果服务器启动时间大于497天，可能会命中bug-3427424 (Jobs may stop running after 497 days uptime)，需要重启服务器解决。

2.7 DBA_JOBS_RUNNING

查看视图dba_jobs_running视图查看JOB是否还在运行：
select * from dba_jobs_running;

如果JOB状态是running,检查以下两个视图 v$access、v$locked_object，找出JOB使用的资源被什么进程锁定了。

2.8 LAST_DATE and NEXT_DATE

确认JOB的last_date和next_date设置是否正确：
select Job,Next_date,Last_date from dba_jobs where job=;
2.9 NEXT_DATE and INTERVAL
Next_date is changing properly as per the interval set in dba_jobs:
查看dba_jobs视图，检查next_date是否根据interval正确变更：
select Job,Interval,Next_date,Last_date from dba_jobs where job=;

2.10 Toggle value for JOB_QUEUE_PROCESSES

设置job_queue_processes=0，等待一段时间后，重新设置回原来的值。
alter system set job_queue_processes=0 ;
alter system set job_queue_processes=4 ;
*此操作实际上就是重启CJQ0进程。

2.11 DBMS_IJOB(Non-documented)

最后的尝试--重启数据库或尝试下面的操作：
exec dbms_ijob.set_enabled(true);


本文作者：许 珣（上海新炬王翦团队）

本文来源：“IT那活儿”公众号

云服务器 GPU云服务器 云服务器ecs linux io占用高问题排查方法 查看服务器的job 自动运行 同时运行两个方法

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129377.html

相关文章

  • 如何利用秒级监控进行mongodb故障排查

    摘要：而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度，全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集，实时数据展示。最后，秒级监控已经在阿里云控制台开放，云的用户可以自主进行监控开启，体验秒级监控带来的高清体验。 在我们平时的数据库使用当中，监控系统，作为排查故障，告警故障的重要辅助系统，对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...

    kyanag 评论0 收藏0

  • 如何利用秒级监控进行mongodb故障排查

    摘要：而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度，全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集，实时数据展示。最后，秒级监控已经在阿里云控制台开放，云的用户可以自主进行监控开启，体验秒级监控带来的高清体验。 在我们平时的数据库使用当中，监控系统，作为排查故障，告警故障的重要辅助系统，对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...

    Taonce 评论0 收藏0

  • 如何利用秒级监控进行mongodb故障排查

    摘要：而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度，全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集，实时数据展示。最后，秒级监控已经在阿里云控制台开放，云的用户可以自主进行监控开启，体验秒级监控带来的高清体验。 在我们平时的数据库使用当中，监控系统，作为排查故障，告警故障的重要辅助系统，对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...

    reclay 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<