当然要是schedule-job那么在这张表内是查不到的,要去dba_scheduler_jobs里面查。还有一个 user_scheduler_job_run_details这里可以查询scheduler_job的运行情况。
oracle数据库采用SNP进程来管理和运行JOB,SNP进程和实例中其他进程最大区别是这个进程被杀掉后,系统就会自动重新启动一个SNP,因此并不影响oracle实例运行.SNP进程本身也是被系统周期性地调用去查看数据字典中的JOB序列目录,看是否有JOB需要去运行,运行之后SNP就进入休眠状态.唤醒,SNP被调用的时间的设置是在数据库初始化文件里通过参数job_queue_interval设置进行的,数据库在打开的时候根据初始化文件去初始化SNP进程。一、SNP参数说明参数
job_queue_interval的粒度不能太大,不要大于JOB执行的间隔(由参数interval来决定),否则的话可能造成有的作业无法执行.粒度也不能太细,否则会使系统频繁调用SNP而增加了系统的吞吐量,所以一定要根据具体环境中JOB而设定.
参数job_queue_interval的设定了系统中最多可运行的SNP数量。
二、当SNP开始执行一个任务时,其过程如下:
1.以任务所有者的用户名开始一个新的数据库会话。
2.当任务第一次提交或是最后一次被修改时,更改会话NLS设置和目前就绪的任务相匹配。
3.通过interval日期表达式和系统时间,计算下一次执行时间。
4.执行任务定义的PL/SQL。
5.如果运行成功,任务的下一次执行日期被更新,否则,失败则日志文件中的计数加1。
6.经过JOB_QUEUE_INTERVAL秒后,又到了另一个SNP运行时间,重复上边的过程。
三、作业失败如何处理
网上和书本上理论讲,当作业失败后,系统会在1分钟后重新运行这个JOB,如果还是失败,就在和第1次失败间隔2分钟的时候继续运行这个JOB,如果还是失败,就在和第2次失败相隔4分钟后运行这个JOB(可以用T=2t-1表 示,t表示第1次失败后检测的次数),直到T≥interval(JOB正常工作的时间设置参数)后,系统检测的时间间隔就为interval.直到第16次失败就会将这个job置为broken.但是这些介绍都很粗略,如果需要真正设计一些合理的job的时候就会忽略一些细微的问题,而这些细微的问题恰好是关键的地方.
提出问题:说明在oracle后台有这样的机制,就是需要判断T是否T≥interval,那么在job失败后是先判断呢,还是等1分钟后检测之后才判断.
实验之后得出结果:先判断,然后才检测,其中由于 *** 作误差,和理论值稍有轻微偏差.
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)