oracle中的job能为你做的就是：在你规定的时间格式里定时执行存储过程，定时执行一个任务
–创建job及运行：
variable job2010 number; begin dbms_job.submit(:job2010,'spgenchanneluseroneday;',sysdate,'sysdate+1/24'); end; / begin dbms_job.run(:job2010); end; / commit;–重启job（可以用上面那个方式也可以直接启动） select * from user_jobs b where b.WHAT like ‘%5secdelete%’; 根据存储过程名字 找出job(数字)
begin dbms_job.run(356); end; / commit；–停掉job
exec dbms_job.broken(job.id,true); exec dbms_job.remove(job.id); commit；当用exec时需要在命令行窗口执行；当用begin XXX end;这种可以在sql窗口执行，实际效果是一样的
—修改job间隔时间
begin dbms_job.interval('438','trunc(sysdate,''Mi'')+1/24'); /*job job的ID,interval: 计算下一次任务执行的时间表达式*/ commit; end;这些的执行方式同上面，就不再一一概述了: 删除job:dbms_job.remove(jobno); 修改job:dbms_job.what(jobno,what); 修改下次执行时间：dbms_job.next_date(job,next_date); 修改间隔时间：dbms_job.interval(job,interval); 停止job:dbms_job.broken(job.id,true); 启动job:dbms_job.run(jobno);
job中的小问题（以下部分参考https://blog.csdn.net/cqu63737/article/details/100236969）： 有些人问，Oracle的JOB在设定完next_date和interval之后，到底是什么时候决定下一次运行时间的。可以归纳成以下几个问题。
1． 假设我们的JOB设定第一次运行的时间是12:00，运行的间隔是1小时，JOB运行需要耗时30分钟，那么第二次运行是在13:00还是13:30？（13:00）
JOB在运行结束之后才会更新next_date，但是计算的方法是JOB刚开始的时间加上interval设定的间隔。 则第二次运行是在13:00。
2． 如果是在13:00那是不是说明只要JOB一开始运行，next_date就被重新计算了？
JOB在运行结束之后才会更新next_date。一般情况是：next_date=JOB刚开始的时间+interval设定的间隔，但是当执行时间大于设置的间隔的时候可能直接取当前时间
3． JOB的下一次运行会受到上一次运行时间的影响吗？如果受到影响，如何可以避免这个影响而让JOB在每天的指定时刻运行？
JOB的下一次运行时间是会受上一次影响的，如果我们的interval仅仅是sysdate+1/24这样的形式的话，无疑，上次执行的时间再加上1小时就是下次执行的时间。那么如果JOB因为某些原因延迟执行了一次，这样就会导致下一次的执行时间也同样顺延了，这通常不是我们希望出现的现象。
解决方法很简单，只需要设定正确的interval就可以了。
比如，我们要JOB在每天的凌晨3:30执行而不管上次执行到底是几点，只需要设置interval为trunc(SYSDATE)+3.5/24+1即可。
4． 假设我们的JOB设定第一次运行的时间是12:00，运行的间隔是30分钟，JOB运行需要耗时1小时，那么第二次运行是在12:30还是13:00还是根本就会报错？(13:00)
更新next_date字段的公式是greatest(:3, sysdate)，此处的:3绑定的是job的this_date+interval。所以我们猜测实际上应该是有一个跟当前时间的比较机制，如果在执行完JOB之后的时间比按照this_date+interval计算出的时间更晚一些，那么next_date就更新为当前时间，也就是几乎会立刻再重新执行JOB。
也就是说，next_date,如果JOB 开始时间+间隔时间 小于 当前时间，那么则取 当前时间，否则取 开始时间+间隔时间。
