ITPub博客

首页 > 数据库 > Oracle > Oracle作业(JOB)更新next_date的探讨

Oracle作业(JOB)更新next_date的探讨

原创 Oracle 作者:lifewise 时间:2007-09-28 15:31:17 0 删除 编辑

Oracle作业(JOB)更新next_date的探讨

本文作者:kamus(kamus@itpub.net)

本文可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://blog.csdn.net/kamus/archive/2004/12/02/201377.aspx

摘要:本文通过实验和事件跟踪来分析Oracle Job执行过程中修改下次执行时间的机制。

[@more@]

Oracle作业(JOB)更新next_date的探讨

本文作者:kamus(kamus@itpub.net)

本文可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://blog.csdn.net/kamus/archive/2004/12/02/201377.aspx

摘要:本文通过实验和事件跟踪来分析Oracle Job执行过程中修改下次执行时间的机制。

有些人问,OracleJOB在设定完next_dateinterval之后,到底是什么时候决定下一次运行时间的。可以归纳成以下几个问题。

1. 假设我们的JOB设定第一次运行的时间是12:00,运行的间隔是1小时,JOB运行需要耗时30分钟,那么第二次运行是在13:00还是13:30

2. 如果是在13:00那是不是说明只要JOB一开始运行,next_date就被重新计算了?

3. JOB的下一次运行会受到上一次运行时间的影响吗?如果受到影响,如何可以避免这个影响而让JOB在每天的指定时刻运行?

4. 假设我们的JOB设定第一次运行的时间是12:00,运行的间隔是30分钟,JOB运行需要耗时1小时,那么第二次运行是在12:30还是13:00还是根本就会报错?

本文通过一些实验和跟踪来解释上面的所有问题。

首先我们选择一个测试用户,假设该用户名为kamus

由于我们在实验用的存储过程中会用到dbms_lock包,所以需要由sys用户先授予kamus用户使用dbms_lock包的权限。

d:Temp>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.5.0 - Production on 星期三 12 1 23:56:32 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:

Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.5.0 - Production

SQL> grant execute on dbms_lock to kamus;

授权成功。

然后用kamus用户登录数据库,创建我们测试使用的存储过程sp_test_next_date

create or replace procedure sp_test_next_date as
p_jobno number;
P_nextdate date;
begin
--将调用此存储过程的jobnext_date设置为30分钟以后

select job into p_jobno from user_jobs where what =
'sp_test_next_date;';
execute immediate
'begin dbms_job.next_date(' || to_char(p_jobno) || ',sysdate+1/48);commit;end;'
;
--修改完毕以后检查user_jobs视图,输出job目前的next_date

select next_date
into P_nextdate
from user_jobs
where what =
'sp_test_next_date;';
dbms_output.put_line(
'JOB执行中的next_date: '
||
to_char(p_nextdate,
'YYYY-MM-DD HH24:MI:SS'
));
--等待10秒再退出执行

dbms_lock.sleep(seconds =>
10);
end sp_test_next_date;

创建调用该存储过程的JOB,定义interval为每天一次,也就是这次执行以后,下次执行时间应该在1天以后。

SQL> variable jobno number;

SQL> BEGIN

2 DBMS_JOB.SUBMIT(job => :jobno,

3 what => 'sp_test_next_date;',

4 next_date => SYSDATE,

5 interval => 'SYSDATE+1');

6 COMMIT;

7 END;

8 /

PL/SQL 过程已成功完成。

jobno

---------

1

然后我们手工执行存储过程,执行完毕以后再手工从user_jobs视图中获得JOB的下次执行时间,可以看到在存储过程中修改的JOB的下次执行时间已经生效,变成了当前时间的30分钟以后,而不是默认的1天以后。

SQL> conn kamus

请输入口令:

已连接。

SQL> set serverout on

SQL> exec sp_test_next_date();

JOB执行中的next_date: 2004-12-02 00:44:11

PL/SQL 过程已成功完成。

SQL> col next_date for a20

SQL> select to_char(next_date,'YYYY-MM-DD HH24:MI:SS') next_date from user_jobs

where what = 'sp_test_next_date;';

NEXT_DATE

--------------------

2004-12-02 00:44:11

我们再手工运行JOB,看看这次的结果,可以发现JOB没有运行完毕以前被修改了的下次运行时间跟JOB运行完毕以后再次手工检索user_jobs视图获得的下次运行时间已经不相同了。由此我们可以得出一个结论,next_date是在JOB运行完毕以后被Oracle自动修改的,而不是在JOB刚开始运行的时候,因为我们在存储过程中修改的next_dateJOB运行结束之后又被修改为默认的1天以后了。

SQL> exec dbms_job.run(1);

JOB执行中的next_date: 2004-12-02 00:54:52

PL/SQL 过程已成功完成。

SQL> select to_char(next_date,'YYYY-MM-DD HH24:MI:SS') next_date from user_jobs

where what = 'sp_test_next_date;';

NEXT_DATE

--------------------

2004-12-03 00:24:52

现在我们再次修改存储过程,输出存储过程开始执行的时间,便于跟执行完毕以后的JOB下次执行时间进行比较。

create or replace procedure sp_test_next_date as
p_jobno number;
P_nextdate date;
begin
--输出JOB刚开始执行的时间

dbms_output.put_line(
' JOB开始执行的时间: ' ||
to_char(sysdate,
'YYYY-MM-DD HH24:MI:SS'
));
--将调用此存储过程的jobnext_date设置为30分钟以后

select job into p_jobno from user_jobs where what =
'sp_test_next_date;';
execute immediate
'begin dbms_job.next_date(' || to_char(p_jobno) || ',sysdate+1/48);commit;end;'
;
--修改完毕以后检查user_jobs视图,输出job目前的next_date

select next_date
into P_nextdate
from user_jobs
where what =
'sp_test_next_date;';
dbms_output.put_line(
' JOB执行中的next_date: '
||
to_char(p_nextdate,
'YYYY-MM-DD HH24:MI:SS'
));
--等待10秒再退出执行

dbms_lock.sleep(seconds =>
10);
end sp_test_next_date;

重新进行测试,我们可以发现JOBnext_dateJOB开始执行时间的1天以后,而不是JOB结束时间的1天以后(因为JOB结束需要经过10秒钟)

SQL> exec dbms_job.run(1);

JOB开始执行的时间: 2004-12-02 00:38:24

JOB执行中的next_date: 2004-12-02 01:08:24

PL/SQL 过程已成功完成。

SQL> select to_char(next_date,'YYYY-MM-DD HH24:MI:SS') next_date from user_jobs

where what = 'sp_test_next_date;';

NEXT_DATE

--------------------

2004-12-03 00:38:24

至此,我们已经说明了两个问题。就是:JOB在运行结束之后才会更新next_date,但是计算的方法是JOB刚开始的时间加上interval设定的间隔。

下面我们通过trace来再次求证这个结论。

SQL> ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';

会话已更改。

SQL> exec dbms_job.run(1);

PL/SQL 过程已成功完成。

SQL> ALTER SESSION SET EVENTS '10046 trace name context off';

会话已更改。

执行完毕以后在udump目录中查看生成的trace文件。如果我们用tkprof来格式化这个trace文件然后再查看格式化后的结果,我们会感到很诧异。因为在格式化完毕的SQL执行顺序中,更新job$表的语句出现在dbms_job.next_date语句之前,也就是看上去是Oracle先按照interval自动更新了JOBnext_date,然后才继续往下执行存储过程中定义的next_date更新语句,而这样显然无法解释我们在上面的实验中看到的结果。

但是当我们跳过tkprof而直接去查看生成的trace文件,就会恍然大悟,同时也印证了steve adamsixora上提到的观点:tkprof格式化完的结果会省略一些信息,甚至在有时候会给我们错误的信息。

直接查看trace文件,我们可以看到如下的执行顺序:

1. parse cursor #10oracle根据interval和先前保存的this_date字段值更新job$

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/620862/viewspace-973474/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-01-07

  • 博文量
    52
  • 访问量
    488447