DBMS_SCHEDULER und die Sommerzeit, DB-Job richtig timen

-

Bei der Weiterentwicklung eines Projektes ist aufgefallen, dass ein DB-Job 1 Stunde zu früh ausgeführt wird.
Geplant für 06:20Uhr wird er bereits um 05:20Uhr ausgeführt:

-- Ausführungshistorie
select to_char(l.log_date,'dd.mm.yyyy hh24:mi:ss.ff TZR') "Log Date TZ"
          , to_char(r.req_start_date,'dd.mm.yyyy hh24:mi:ss.ff TZR') "Required Start Date TZ"
          , to_char(r.actual_start_date,'dd.mm.yyyy hh24:mi:ss.ff TZR') "Actual Start Date TZ"
    from ALL_SCHEDULER_JOB_LOG L, ALL_SCHEDULER_JOB_RUN_DETAILS R
  where l.Owner = 'my'
      and l.job_name = 'myJob'
      and l.log_id = r.log_id (+)
  order by 1 desc;
liefert
Log Date TZ Required Start Date TZ Actual Start Date TZ
31.12.2022 05:21:06.062526 +01:00 31.12.2022 06:20:00.366020 +02:00 31.12.2022 06:20:00.445268 +02:00
30.12.2022 05:22:15.510405 +01:00 30.12.2022 06:20:00.160237 +02:00 30.12.2022 06:20:00.354385 +02:00
29.12.2022 05:21:29.299165 +01:00 29.12.2022 06:20:00.019715 +02:00 29.12.2022 06:20:00.135502 +02:00
Eigentlich ist alles korrekt:
Ein für 06:20Uhr in Zeitzone +02:00 geplanter Start startet in Zeitzone +01:00 eben um 05:20Uhr.
Nur war das anders gedacht!

Erstellt wurde der Job per Script im Sept 2022:

-- DB-Job erstellen - Fehlerhaft!
SYS.DBMS_SCHEDULER.CREATE_JOB
  (
    job_name => 'myJob'
    ,start_date => TO_TIMESTAMP_TZ('20220928','yyyymmdd')
    ,repeat_interval => 'FREQ=DAILY; BYHOUR=6; BYMINUTE=20; BYSECOND=0'
    ,end_date => NULL
    ,job_class => 'DEFAULT_JOB_CLASS'
    ,job_type => 'STORED_PROCEDURE'
    ,job_action => 'myProc'
    ,comments => 'myProc-Kommentar'
    ,enabled => false
  );

Dabei scheint dem START_DATE eine größere Rolle zuzukommen, als vermutet.

Die Prüfung per

-- Ausführung prüfen
select to_char (START_DATE, 'yyyy/mm/dd hh24:mi:ss.ff tzr') START_DATE
          , REPEAT_INTERVAL
          , LAST_START_DATE
          , NEXT_RUN_DATE
    from SYS.ALL_SCHEDULER_JOBS
  where JOB_NAME = 'myJob';
zeigt, das für den Start
28.09.2022 00:00:00,000000 +02:00
verwendet wird.
Und eben dieses +02:00 ist das Problem. Da NEXT_RUN_DATE basierend auf START_DATE berechnet wird, gibt es eine Verschiebung bei der Zeitumstellung. Im September befindet sich die Datenbank in Zeitzone UTC+02:00, weil Sommerzeit. Im Winter liegt sie in UTC+01:00. Da +02:00 hart vorgegeben ist, startet der Job im Winter früher.

Was kann man tun?

Grundsätzlich gibt es für SYS.DBMS_SCHEDULER.CREATE_JOB folgende Optionen:

  1. ,start_date => TO_TIMESTAMP_TZ('20230101','yyyymmdd') --> wie oben, nicht gut!
  2. ,start_date => TO_TIMESTAMP_TZ('20230101 EUROPE/BERLIN','yyyymmdd TZR') --> Zeitzonenregion (TZR) mit angeben -> beste Lösung, da eindeutig!
  3. Parameter start_date weglassen --> dann bestimmt die Datenbank über verschiebende Ebenen den Wert. (Siehe dazu den Blogeintrag von Martin Preiss.)

Im Beispiel ergeben sich für die drei Varianten folgende START_DATE:

Option NEXT_RUN_DATE START_DATE
1 04.01.2023 06:20:00,628493 +01:00 2023/01/01 00:00:00.000000 +01:00
2 04.01.2023 06:20:00,946355 +01:00 2023/01/01 00:00:00.000000 Europe/Berlin
3 04.01.2023 06:20:00,588781 +01:00 2023/01/03 10:59:59.588781 Europe/Vienna
(Nicht verwirren lassen: Jetzt bei Test ist Winterzeit, daher die +01:00).

Fazit: Mit der Umstellung auf DBMS_SCHEDULER ist die Job-Steuerung der Datenbank sehr viel leistungsfähiger geworden. Gleichzeitig gibt es aber auch mehr Punkte zu beachten.

-- DB-Job erstellen, mit korrekter Startzeitvorgabe
SYS.DBMS_SCHEDULER.CREATE_JOB
  (
    job_name => 'myJob'
    ,start_date => TO_TIMESTAMP_TZ('20230101 EUROPE/BERLIN','yyyymmdd TZR')
    ,repeat_interval => 'FREQ=DAILY; BYHOUR=6; BYMINUTE=20; BYSECOND=0'
    ,end_date => NULL
    ,job_class => 'DEFAULT_JOB_CLASS'
    ,job_type => 'STORED_PROCEDURE'
    ,job_action => 'myProc'
    ,comments => 'myProc-Kommentar'
    ,enabled => false
  );

Den bestehende Job umzustellen schaut dann so aus:

-- bestehende Job auf korrekte Startzeitvorgabe umstellen
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
  (
    name => 'myJob'
    , attribute => 'start_date'
    , value => TO_TIMESTAMP_TZ('20220928 EUROPE/BERLIN','yyyymmdd TZR')
  );
...dann passen auch die Ausführzeiten wieder.

Eine gute Erläuterung zu diesem Thema findet sich im Blog von Martin Preiss:
https://martinpreiss.blogspot.com/2012/03/dbmsscheduler-und-die-sommerzeit.html

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

trunc(sysdate) - nette Spiele mit dem Datum

-
Über die trunc-date Funktion läßt sich ausgehend von einem Datumswert sehr einfach ein abgeleiteter Datumswert ermittelt: bspw. der Jahres-, Quartals-, Monats- oder Wochenanfang. Die 11g Doku erläutert dies an zwei Stellen: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions209.htm#SQLRF06151 bzw. http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions242.htm#sthref2718 So liefert select trunc(to_date('06.02.2011'),'q') from dual; das DATUM des Quartalsersten (im Bsp. den 01.01.2011). Wichtig ist, dass trunc immer ein Datum zurückliefert, keinen String. Einige Beispiele anhand des 20.Feb 2011 (ein Sonntag in der 07 KW in 2011): select trunc(to_date('20.02.2011'),'d') from dual; select trunc(to_date('20.02.2011'),'dd') from dual; select trunc(to_date('20.02.2011'),'ddd') from dual; select trunc(to_date('20.02.2011'),'mm') from dual; select trunc(to_date('20.02.2011...
Mehr anzeigen

Zufallszahlen und -text generieren - DBMS_RANDOM

-
Um für Testzwecke etc. "zufällige" Zahlen / Strings zu erzeugen, gibt es in Oracle die Funktion dbms_random . In Verbindung mit connect by kann so sehr einfach eine beliebige Menge an Zeilen mit Zufallswerten erzeugt werden: SELECT dbms_random.value(1,1000) Z       , dbms_random.string('a',20) Txt   FROM DUAL CONNECT BY level < 101; * DBMS_RANDOM.VALUE(low, high)   + low -> untere Grenze   + high -> obere Grenze * DBMS_RANDOM.STRING(opt, len)   + opt -> Definiert, was für ein String erzeugt wird   + len -> Länge des String   + Details zu opt: 'u', 'U' - returning string in uppercase alpha characters 'l', 'L' - returning string in lowercase alpha characters 'a', 'A...
Mehr anzeigen

Laufzeiten umrechnen, Sekundenangaben lesbar darstellen

-
Hintergrund: Laufzeiten von diversen Prozessen werden (Tool-)intern in Sekunden gemessen und meist auch so dargestellt. Für Weiterberechnungen und Auswertungen ist das Ideal. Der Lesbarkeit für den geneigten Nutzer nur bedingt dienlich. Wer erkennt schon auf den ersten Blick, wie lange 14.738sec sind? Lang halt. Lösungsansätze: Für die Lesbarkeit, kann man diese Werte natürlich entsprechend umrechnen. Aber wie? 14.738sec vermutlich am Besten in Stunden: 14.738/60/60 = 4,0939 Stunden -> Aha. Aber was ist mit 249sec? 249/60/60 = 0,069 Stunden - Wie lang bitte sind 0,069Std? 249sec also besser in Minuten umrechnen: 249/60 = 4,15 Min -> schon besser Also per CASE-Statement die unterschiedliche großen Sekundenangaben passend umrechnen? Nicht schön und umständlich. Netterweise bietet Oracle mit der to_date()-Funktion auch den Formatstring 'sssss' (5x kleines 's'). Per to_char( to_date(14768,'sssss') ,'HH24:MI:SS') werden aus den Sekunden ...
Mehr anzeigen