这篇文章将为大家详细讲解有关时区调整对job的运行时间有什么影响，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
调整时区既可以在操作系统调整，也可以在session 调整，那么不同的方式对于job的计划时间是否有影响呢，
我们用实际例子来验证一下：
Test1:
1.首先看一下默认系统时区:
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 03:50:10 GMT 2016 <'TJ1',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<1hour 之后开始运行
enabled => true,
auto_drop => true
);
end;
/
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB
TJ1 JOB_PRO_TEST1
11/19/2016 4:51:26.000000 AM +00:00
SCHEDULED
<< 03:51提交的，计划在GMT的上午4:51开始运行
Test2:
1.检查一下当前时间
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 03:54:30 GMT 2016 << alter SESSION set time_zone='+08:00'; <<<
begin
dbms_scheduler.create_job(
job_name=>'TJ2',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<仍然1hour 之后开始运行
enabled => true,
auto_drop => true
);
end;
/
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB
TJ2
JOB_PRO_TEST1
11/19/2016 4:54:34.000000 AM +08:00
RUNNING
<<刚刚提交的job，居然计划在中国时区的4:54:34+08:00运行，因为系统当前时间是03:54:30 GMT，对应中国时区的11:54:30+08:00,所以
显然是之前的时间，所以等于过期了，于是scheduler发现需要立即运行，也就处于RUNNING状态了
Test3:
1.检查一下当前时间并通过操作系统设置时区
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 04:02:42 GMT 2016 < begin
dbms_scheduler.create_job(
job_name=>'TJ3',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<仍然1hour 之后开始运行
enabled => true,
auto_drop => true
);
end;
/
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB
TJ3
JOB_PRO_TEST1
11/19/2016 1:02:57.000000 PM +08:00
SCHEDULED
新job计划时间是北京时间1:02:57，这个正式符合要求的
综上所述，正常在操作系统层面调整时区是不会影响job时间的，但是对于通过alter sessoin 调整时区
需要谨慎，因为server process还是fork起来时候的时间(GMT)我们突然把session的时区给修改了，但是时间
是不会变的，所以start_date就是变成GMT的时间和新时区的组合体了。
关于时区调整对job的运行时间有什么影响就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
