Oracle_JOB参数详解

Oracle_JOB参数详解

 DECLARE
v_job  NUMBER;
BEGIN
dbms_job.submit(job       => v_job,
what      => 'begin
pkg_databak_bak.p_serv_flag_gsm_m_bak;
pkg_databak_bak.p_serv_flag_m_bak;
end;',
next_date => SYSDATE,
INTERVAL  => 'add_months(trunc(SYSDATE), 1)');
                    DBMS_OUTPUT.PUT_LINE(v_job);
END;


select * from DBA_JOBS;
select * from DBA_JOBS_RUNNING;

1、job

参数job是一个整数，用来唯一地标示一个任务。该参数既可由用户指定也可由系统自动赋予，这完全取决于提交任务时选用了那一个任务提交过程。DBMS_JOB.SUBMIT过程通过获得序列SYS.JOBSEQ的下一个值来自动赋予一个任务号。该任务号是作为一个OUT参数返回的，所以调用者随后可以识别出提交的任务。而DBMS_JOB.ISUBMIT过程则由调用者给任务指定一个识别号，这时候，任务号的唯一性就完全取决于调用者了。

 

除了删除或者重新提交任务，一般来说任务号是不能改变的。即使当数据库被导出或者被导入这样极端的情况，任务号也将被保留下来。所以在执行含有任务的数据的导入/导出操作时很可能会发生任务号冲突的现象。

 

2、what

what参数是一个可以转化为合法PL/SQL调用的字符串，该调用将被任务队列自动执行。在what参数中，如果使用文字字符串，则该字符串必须用单引号括起来。 what参数也可以使用包含我们所需要字符串值的VARCHAR2变量。实际的PL/SQL调用必须用分号隔开。在PL/SQL调用中如果要嵌入文字字符串，则必须使用两个单引号。

 

what参数的长度在Oracle7.3中限制在2000个字节以内，在Oracle 8.0以后，扩大到了4000个字节，这对于一般的应用已完全足够。该参数的值一般情况下都是对一个PL/SQL存储过程的调用。在实际应用中，尽管可以使用大匿名Pl/SQL块，但建议大家最好不要这样使用。还有一个实际经验就是最好将存储过程调用封装在一个匿名块中，这样可以避免一些比较莫名错误的产生。我来举一个例子，一般情况下，what参数可以这样引用：

 

what =>’my_procedure(parameter1);’

 

但是比较安全的引用，应该这样写：

 

what =>’begin my_procedure(parameter1); end;’

 

任何时候，我们只要通过更改what参数就可以达到更改任务定义的目的。但是有一点需要注意，通过改变what参数来改变任务定义时，用户当前的会话设置也被记录下来并成为任务运行环境的一部分。如果当前会话设置和最初提交任务时的会话设置不同，就有可能改变任务的运行行为。意识到这个潜在的副作用是非常重要的，无论何时只要应用到任何DBMS_JOB过程中的what参数时就一定要确保会话设置的正确。

 

3、next_date

Next_date参数是用来调度任务队列中该任务下一次运行的时间。这个参数对于DBMS_JOB.SUBMIT和DBMS_JOB.BROKEN这两个过程确省为系统当前时间，也就是说任务将立即运行。

 

当将一个任务的next_date参数赋值为null时，则该任务下一次运行的时间将被指定为4000年1月1日，也就是说该任务将永远不再运行。在大多数情况下，这可能是我们不愿意看到的情形。但是，换一个角度来考虑，如果想在任务队列中保留该任务而又不想让其运行，将next_date设置为null却是一个非常简单的办法。

 

Next_date也可以设置为过去的一个时间。这里要注意，系统任务的执行顺序是根据它们下一次的执行时间来确定的，于是将next_date参数设置回去就可以达到将该任务排在任务队列前面的目的。这在任务队列进程不能跟上将要执行的任务并且一个特定的任务需要尽快执行时是非常有用的。

 

4、Interval

Internal参数是一个表示Oracle合法日期表达式的字符串。这个日期字符串的值在每次任务被执行时算出，算出的日期表达式有两种可能，要么是未来的一个时间要么就是null。这里要强调一点：很多开发者都没有意识到next_date是在一个任务开始时算出的，而不是在任务成功完成时算出的。

 

当任务成功完成时，系统通过更新任务队列目录表将前面算出的next_date值置为下一次任务要运行的时间。当由interval表达式算出next_date是null时，任务自动从任务队列中移出，不会再继续执行。因此，如果传递一个null值给interval参数，则该任务仅仅执行一次。

 

通过给interval参数赋各种不同的值，可以设计出复杂运行时间计划的任务。附录的“任务间隔和日期算法”将对interval表达式进行详细讨论，并给出一个实际有用interval表达式的例子。

 

 

附录：任务重复运行间隔和间隔设计算法

 

任务重复运行的时间间隔取决于interval参数中设置的日期表达式。下面就来详细谈谈该如何设置interval参数才能准确满足我们的任务需求。一般来讲，对于一个任务的定时执行，有三种定时要求。

 

1) 在一个特定的时间间隔后，重复运行该任务。

2) 在特定的日期和时间运行任务。

3) 任务成功完成后，下一次执行应该在一个特定的时间间隔之后。

第一种调度任务需求的日期算法比较简单，即'SYSDATE+n',这里n是一个以天为单位的时间间隔。表1给出了一些这种时间间隔设置的例子。

 

表1 一些简单的interval参数设置例子

 

描述	Interval参数值
每天运行一次	'SYSDATE + 1'
每小时运行一次	'SYSDATE + 1/24'
每10分钟运行一次	'SYSDATE + 10/（60*24）'
每30秒运行一次	'SYSDATE + 30/(60*24*60)'
每隔一星期运行一次	'SYSDATE + 7'
不再运行该任务并删除它	NULL

 

表1所示的任务间隔表达式不能保证任务的下一次运行时间在一个特定的日期或者时间，仅仅能够指定一个任务两次运行之间的时间间隔。例如，如果一个任务第一次运行是在凌晨12点，interval指定为'SYSDATE+ 1',则该任务将被计划在第二天的凌晨12点执行。但是，如果某用户在下午4点手工(DBMS_JOB.RUN)执行了该任务，那么该任务将被重新定时到第二天的下午4点。还有一个可能的原因是如果数据库关闭或者说任务队列非常的忙以至于任务不能在计划的那个时间点准时执行。在这种情况下，任务将试图尽快运行，也就是说只要数据库一打开或者是任务队列不忙就开始执行，但是这时，运行时间已经从原来的提交时间漂移到了后来真正的运行时间。这种下一次运行时间的不断“漂移”是采用简单时间间隔表达式的典型特征。

 

第二种调度任务需求相对于第一种就需要更复杂的时间间隔(interval)表达式，表2是一些要求在特定的时间运行任务的interval设置例子。

 

表2. 定时到特定日期或时间的任务例子

 

描述	INTERVAL参数值
每天午夜12点	'TRUNC(SYSDATE + 1)'
每天早上8点30分	'TRUNC(SYSDATE + 1) + （8*60+30）/(24*60)'
每星期二中午12点	'NEXT_DAY(TRUNC(SYSDATE ), ''TUESDAY'' ) + 12/24'
每个月第一天的午夜12点	'TRUNC(LAST_DAY(SYSDATE ) + 1)'
每个季度最后一天的晚上11点	'TRUNC(ADD_MONTHS(SYSDATE + 2/24, 3 ), 'Q' ) -1/24'
每星期六和日早上6点10分	'TRUNC(LEAST(NEXT_DAY(SYSDATE, ''SATURDAY"), NEXT_DAY(SYSDATE, "SUNDAY"))) + （6×60+10）/（24×60）'

 

第三种调度任务需求无论通过怎样设置interval日期表达式也不能满足要求。这时因为一个任务的下一次运行时间在任务开始时才计算，而在此时是不知道任务在何时结束的。遇到这种情况怎么办呢？当然办法肯定是有的，我们可以通过为任务队列写过程的办法来实现。这里我只是简单介绍以下，可以在前一个任务队列执行的过程中，取得任务完成的系统时间，然后加上指定的时间间隔，拿这个时间来控制下一个要执行的任务。这里有一个前提条件，就是目前运行的任务本身必须要严格遵守自己的时间计划。