[20211203]演示job启动时间改变的情况.txt
--//生产系统出现job启动时间改变的情况,开发还是习惯使用job方式调度后台任务,实际上应该尝试使用schedule。
--//通过例子演示出来。
1.环境:
SCOTT@book> @ ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
--//GRANT EXECUTE ON SYS.DBMS_LOCK TO SCOTT;
2.建立存储过程:
CREATE OR REPLACE PROCEDURE SCOTT.foo
AS
BEGIN
NULL;
dbms_lock.sleep (600);
END;
DECLARE
X NUMBER;
BEGIN
begin
SYS.DBMS_JOB.SUBMIT
(
job => X
,what => 'SCOTT.FOO;'
,next_date => to_date('12/03/2021 17:15:02','mm/dd/yyyy hh24:mi:ss')
,interval => 'SYSDATE+1'
,no_parse => FALSE
);
:JobNumber := to_char(X);
exception
when others then
begin
raise;
end;
end;
END;
--//等17:15
SYS@book> select * from DBA_JOBS_RUNNING where job=371;
SID JOB FAILURES LAST_DATE LAST_SEC THIS_DATE THIS_SEC INSTANCE
---------- ---------- ---------- ------------------- ---------------- ------------------- ---------------- ----------
30 371 2021-12-03 17:15:02 17:15:02 0
--//已经启动。
SYS@book> select sysdate from dual ;
SYSDATE
-------------------
2021-12-03 17:16:08
SYS@book> shutdown abort
ORACLE instance shut down.
SYS@book> startup
ORACLE instance started.
Total System Global Area 643084288 bytes
Fixed Size 2255872 bytes
Variable Size 205521920 bytes
Database Buffers 427819008 bytes
Redo Buffers 7487488 bytes
Database mounted.
Database opened.
SYS@book> select * from DBA_JOBS_RUNNING where job=371;
SID JOB FAILURES LAST_DATE LAST_SEC THIS_DATE THIS_SEC INSTANCE
---------- ---------- ---------- ------------------- ---------------- ------------------- ---------------- ----------
323 371 2021-12-03 17:16:39 17:16:39 0
--//可以发现启动数据库后,job重新执行。开始时间是2021-12-03 17:16:39,查询job的定义还是:
BEGIN
SYS.DBMS_JOB.SUBMIT
( job => X
,what => 'SCOTT.FOO;'
,next_date => to_date('03/12/2021 17:15:02','dd/mm/yyyy hh24:mi:ss')
,interval => 'SYSDATE+1'
,no_parse => FALSE
);
SYS@book> select * from DBA_JOBS_RUNNING where job=371;
no rows selected
--//执行完成。
--//再次查看定义:
DECLARE
X NUMBER;
user_name varchar2(30);
BEGIN
select user into user_name from dual;
execute immediate 'alter session set current_schema = SCOTT';
BEGIN
SYS.DBMS_JOB.SUBMIT
( job => X
,what => 'SCOTT.FOO;'
,next_date => to_date('04/12/2021 17:16:39','dd/mm/yyyy hh24:mi:ss')
,interval => 'SYSDATE+1'
,no_parse => FALSE
);
SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
execute immediate 'alter session set current_schema = ' || user_name ;
EXCEPTION
WHEN OTHERS THEN
execute immediate 'alter session set current_schema = ' || user_name ;
RAISE;
END;
COMMIT;
END;
/
--//现在下次的启动实际变成了to_date('04/12/2021 17:16:39','dd/mm/yyyy hh24:mi:ss')。
--//我们生产系统遇到的情况就是这样,数据库重启后,中断的job启动,这样下次启动job时间变成新的启动时间。
--//实际上最主要的问题出现在interval => 'SYSDATE+1'定义上,如果我修改为
--//interval => 'trunc(SYSDATE+1)+17/24',这样无论何种情况都是每天启动都是17点,除了job中断的情况(比如上面的数据库异常关
--//闭)。另外注意如果写成trunc(SYSDATE)+17/24,永远都不会执行.
--//个人建议job时间设定为固定时间,而不是interval => 'SYSDATE+1'。我贴一个生产系统类似例子:
> select trunc(scsj),min(scsj) from XXXXX group by trunc(scsj) order by 1;
TRUNC(SCSJ) MIN(SCSJ)
------------------- -------------------
2021-08-19 00:00:00 2021-08-19 00:00:01
2021-08-20 00:00:00 2021-08-20 00:00:01
2021-08-21 00:00:00 2021-08-21 00:00:03
2021-08-22 00:00:00 2021-08-22 00:00:05
2021-08-23 00:00:00 2021-08-23 00:00:07 --//不知道为什么这里变大,我估计启动时还是03秒。
2021-08-24 00:00:00 2021-08-24 00:00:03
2021-08-25 00:00:00 2021-08-25 00:00:04
2021-08-26 00:00:00 2021-08-26 00:00:06
2021-08-27 00:00:00 2021-08-27 00:00:07
2021-08-28 00:00:00 2021-08-28 00:00:08
2021-08-29 00:00:00 2021-08-29 00:00:08
...
2021-11-29 00:00:00 2021-11-29 00:02:17
2021-11-30 00:00:00 2021-11-30 00:02:18
2021-12-01 00:00:00 2021-12-01 00:02:19
2021-12-02 00:00:00 2021-12-02 00:02:19
2021-12-03 00:00:00 2021-12-03 00:02:19
2021-12-04 00:00:00 2021-12-04 00:02:21
2021-12-05 00:00:00 2021-12-05 00:02:24
2021-12-06 00:00:00 2021-12-06 00:02:26
110 rows selected.
--//该job 8/19启用,scsj是执行插入的时间,但是你可以发现每天都在往后推迟一点点时间,到现在已经要2:26才开始插入,现在job的
--//next_date => to_date('07/12/2021 00:02:26','dd/mm/yyyy hh24:mi:ss').
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/267265/viewspace-2845862/ ,如需转载,请注明出处,否则将追究法律责任。