Oracle 11.20.1.0 SE-One
Oracle Linux 5.6 x86-64
Cut to the chase. Most of our scheduler jobs are defined such that start_date, last_start_date, and next_run_date all specify the timezone with a fixed offset. As a result, the first execution after the DST time change, they ran one hour early, but then computation for the next run corrected and they fell back to running at the scheduled time.
Well, almost.
We have two application schemas that own scheduler jobs.
The jobs in one schema behaved as above.
But all of the jobs in the other schema continue to run one hour early.
the above can be observed in the output from this query:
select
instance_name
, systimestamp
from
v$instance;
--
select
owner
, job_name
, log_date
, status
from
dba_scheduler_job_log
here log_date > sysdate - 10
and owner not in ('EXFSYS',
'ORACLE_OCM',
'PERFSTAT',
'SYS'
)
order by
owner
, job_name
, log_date
;
Very easy to just go down the LOG_DATE column and see the time change.
So my first of two questions is - can anyone explain the above behavior, especially the inconsistency in the jobs of one schema 'healing' themselves after the first run after the time change, but the jobs of another schema continuing to run an hour early.
I don't know if it bears on it or not, but most of the jobs (both schemas) are scheduled with a home-grown function for 'frequency' that uses a decimal representation of time (ie: WEEKLY(.4583,'SATURDAY') )
And a second question - what are the things that influence the timezone representation in the START_DATE when defining a new job? Our programmer creates/maintains the jobs using SQL Navigator, and there is no provision in the GUI there for specifying either a specific time zone or the method (offset vs. name) of representing a timezone. I've read that there are some client-side influences but haven't pieced that together just yet.