背景
近期有客户的环境，发现ORACLE中已建立的新意P_ALL_JOBS作业不能自动运行。这个作业长期没有运行，会使得自动创建分区、自动进行表索引失效重建与表分析、重组等优化操作没有运行，最终影响到清算和数据查询的性能。想到这里，不禁暗自庆幸，还好我们的服务人员发现的及时。
其实在新意系统里，也有一些业务方面的作业，如资金结算、投保、结算运营的数据采集、日终归档等，这些作业没有运行，那影响的就是正常业务。
所以定期的检查作业的状态，遇到异常时能及时解决，保证作业的正常持续的运行，是很重要的，今天就为大家介绍下这方面的操作。先用开头提到的案例来还原下事件经过。
案例现象
更换数据库服务器，重建新意DBA优化作业后，以SYS或者ES_DBA用户登录PLSQL，发现自动作业没有正常运行（正常每天的凌晨都会运行）：
select * from dba_jobs where WHAT=’ ES_DBA.P_ALL_JOBS;
select * from dba_jobs where WHAT=’ ES_DBA.P_ALL_JOBS;’
--WHAT代表作业执行的内容一般是存储过程。
--通过作业没有LAST_DATE上次执行日期与LAST_SEC上次执行时间都没值，判断未正常执行。
故障排查与解决
1、 作业状态检查
怀疑时作业状态不对，因为存储过程，函数等问题没有编译通过或者执行异常，导致作业也会被broken。可是通过上面的语句检查，BROKEN字段值是‘N’，说明状态是没问题的。而且检查FALURES字段，也没有具体的错误数值而是0；作业调用的过程，ES_DBA.P_ALL_JOBS也没有存在任何编译不通过的问题。
2、重启作业
上帝和耶稣都说过，重启是解决技术故障最直接的办法，这里我们尝试重启作业，先看NEXT_DATE与NEXT_SEC是否有更新为下次应该正确执行的日期与时间，再看晚上作业是否正常执行。
--禁止作业
BEGIN dbms_job.broken(64,true); --填实际的作业号，取这条作业记录的JOB字段的值
END;
--启动作业
BEGIN dbms_job.broken(64,false); --填实际的作业号
END;
可是当天晚上，也没有正常运行。
3、检查作业队列的参数
以SYS或者ES_DBA用户登录，执行show parameter job_queue_process看看结果是不是0；--这个参数是控制ORACLE可启动的JOB进程数量，如果被系统重置恢复为0，则不能正常运行。如果是这个原因，可以修改此参数。
ALTER SYSTEM SET job_queue_processes = 10; --看JOB的数量，调再大一点没问题。
4、检查SNP进程是否死掉
不是上述参数的原因，继续往下，通过借助强大的百度，很有可能是SNP进程死了造成JOB不跑，可通过下面的语句来确定：
select * from v$bgprocess where name like 'SNP%' OR NAME LIKE 'CJQ%';
查询结果中，如果PADDR字段为’00’，则可确定确实是SNP进程死掉了，重启即可，方法如下：
alter system set job_queue_processes=0;
alter system set job_quene_processes=10;
PS：可惜，查询结果也不是上述原因，至此，笔者已经开始有些紧张了，居然几板斧都不起作用，这个脸可丢不起，硬着头皮再上吧。
5、以SYS用户在数据库服务器端登录SQLPLUS，检查sga 变量kkjsre 的值。
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kkjsre
word kkjsre_ [20B7480, 20B7484) = 00000000
就是由于这个kkjsre值为0才导致作业不能自动运行，手动执行命令让这个值变为1，作业才能自动运行
SQL> exec dbms_ijob.set_enabled(true);
再次检查
SQL> oradebug dumpvar sga kkjsre
word kkjsre_ [20B7480, 20B7484) = 00000001
确认当晚job 已开始自动运行。
最终：要有上次执行日期与时间，下次执行日期与时间， FAILURES为0没有报错，才正常。
运维提醒
1、 在切换数据库服务器，或备份数据还原到另一个实例上后，要检查下DBA作业是否正常运行，如果已经丢失可以联系新意服务工程师帮忙补建。
2、 日常运行过程中，可以每周检查下作业运行的情况，除了正文中的查看作业状态的语句，也可以通过select * from all_jobs_log来检查新意的P_ALL_JOBS是否正常运行。
3、 业务系统的作业，通常在前台是可以查看作业任务的执行结果与时间的，可以在任务结束后的时间段，检查下上一次的任务是不是正常完成，避免影响第二天的业务开展。
参考技术说明
1、SNP进程
任务队列（SNP）后台过程随着Oracle实例的启动而同时启动。在文章前面已经谈到初始化文件init.ora中的参数JOB_QUEUE_PROCESSES，用来设置有几个队列过程。这里设置了几个过程，系统中就会有几个SNP过程被启动。JOB_QUEUE_PROCESSES这个参数，可以是0到36中的任何一个数，也就是说对于每个Oracle实例最多可以有36个SNP过程，也可以不支持队列过程（＝0）。在大多数操作系统中，SNP三个字母常作为过程名的一部分出现。如，在unix系统中，如果该Oracle实例名为ora8，有三个任务队列过程，则这三个任务队列过程名称为：
ora_ora8_snp0 ora_ora8_snp1 ora_ora8_snp2 |
SNP后台过程和其他的Oracle后台过程的一个重要区别就是杀掉一个SNP过程不会影响到Oracle实例。当一个任务队列过程失控或者消耗太多的资源时，就可以将其杀掉，当然这种情况不是经常遇到的。当一个SNP过程被杀掉或者失败时，Oracle就自动启动一个新的SNP过程来代替它。
2、 oradebug setmypid 与命令oradebug dumpvar sga的解释。
oradebug工具是Oracle数据库调优和诊断的利器，合理运用oradebug可以大幅减少我们收集诊断信息所花费的时间。利用oradebug工具我们不仅可以做到对这些内部变量的窥视，还可以做到修改。当然前提是合理运用，对于初级DBA有这样一个忠告，不要在生产环境中去接触或修改自己所不熟悉的领域的东西，这一点很重要..
在oradebug命令执行之前，你必须加入一个目标进程。这个目标进程有如下3种情况：
1）oradebug setmypid
连接到为你的sql*plus提供服务的进程
2）oradebug setorapid pid
连接到一个外部服务进程，且pid=v$process.pid
3）oradebug setospid spid
连接到一个外部服务进程，且spid=v$process.pid
---------------------
oradebug的dumpvar命令，该命令用于打印转储固定的PGA/UGA/SGA的变量.
本例中的kkjsre 就是作业执行的一个必要的变量条件。
-- The SGA variable kkjsre must be 1 for jobs to execute automatically.
3、关于ORACLE作业定时任务的详细的知识，感觉有一篇还是说的不错的，可以参考：https://blog.csdn.net/rain_gao/article/details/51790581
