Blog 
Vorsicht beim setzen der DBTIMEZONE!

Warum man die DBTIMEZONE nicht auf ein „Location Time Zone“ Format in Oracle setzen sollte.

Eines vorweg, die DBTIMZONE steuert nicht, zu welcher Zeit genau Scheduler Jobs anlaufen. Als ich beim letzten Mal meine Scheduler Jobs angepasst habe und lange hin und her überlegte wie ich denn jetzt meine Zeitpläne konfiguriere stieß ich auf eine ganz einfache Frage. Nach welcher Zeitzone richtet sich denn jetzt die „by hour 23“ die ich hier angedacht habe? Neben dem altbekannten SYSDATE, stieß ich auf den Parameter DBTIMEZONE. Was liegt denn näher, als dass die Datenbankzeitzone auch steuert wann meine >Datenbank!< Jobs laufen. Dann liegt es doch auch auf der Hand, dass man die Sommerzeit (Daylight Saving Time = DST) auch bedenken muss, also in meinem Fall ‚Europe/Berlin‘. Müsste doch richtig sein !?! … dachte ich mir … Falsch gedacht!

Die erste Amtshandlung war festzustellen, was für eine Datenbankzeitzone denn jetzt gesetzt ist:

SQL> select dbtimezone from dual;

DBTIME
------
+02:00

Als nächstes also die Datenbankzeitzone umstellen. So (Europe/Berlin) bitte nicht nachmachen!

SQL> ALTER DATABASE SET TIME_ZONE = 'Europe/Berlin';

ALTER DATABASE SET TIME_ZONE = 'Europe/Berlin'
*
ERROR at line 1:
ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH LOCAL TIME ZONE columns

Dank der Fehlermeldung stieß ich auf den eigentlichen Zweck der DBTIMEZONE. Diese ist nämlich lediglich dafür zuständig, dass sie als eine Zeitzone fungiert in der die Werte der „TIMESTAMP WITH LOCAL TIME ZONE“ Datentypen zur aktuellen Datenbankzeitzone normalisiert abgespeichert werden können. Die abgespeicherten Werte werden bei einem Insert oder der Abfrage trotzdem immer in die aktuelle Session Time Zone konvertiert, somit relatviert sich auch hier die Datenbank Zeitzone nochmals. Sie ist also erstmal nicht so wichtig wie sie klingt.

Dennoch sollte man die DBTIMEZONE nicht auf eine Zeitzone stellen, die von der Sommerzeit bzw. Daylight Saving Time (DST) beeinflusst wird. Es empfiehlt sich also ein „OFFSET“ +00:00 ( -07:00, +02:00) oder eine statische Zeitzone, die nicht von der Sommerzeit betroffen ist bspw. UTC oder GMT. Das beste Setting ist einfach +00:00. Haben sie ein OFFSET +02:00 oder ähnliches, welches im Zweifel mit dem CREATE DATABASE gesetzt wurde, können sie das auch stehe lassen. In meinem Fall oben (+02:00) war also alles gut.

SQL> ALTER DATABASE SET TIME_ZONE = '+00:00';

DATABASE SET TIME_ZONE = 'UTC';

Für das tatsächliche Umsetzen ist zudem ein Durchstarten der Datenbank notwendig. Wollen Sie die DBTIMEZONE trotzdem umsetzten oder haben wirklich einen „falschen“ Wert, also eine Location Time Zone mit Sommerzeit und bekommen die gleiche Fehlermeldung wie ich, müssen Sie zunächst herausfinden, welche Tabellen dem Datentyp LOCAL TIME ZONE WITH LOCAL TIMESTAMP nutzen:

ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH LOCAL TIME ZONE columns

select t.owner, t.table_name, t.column_name, t.data_type
  from dba_tab_cols t, dba_objects o
 where t.data_type like '%WITH LOCAL TIME ZONE'
   and t.owner=o.owner
   and t.table_name = o.object_name
   and o.object_type = 'TABLE'
order by 1
/

Im zweiten Schritt sollten Sie die entsprechenden Tabellen exportieren und droppen. DBTIMEZONE setzen, die Datenbank runterfahren, wieder hochfahren und Tabellen wieder importieren. Wollen Sie nicht droppen, weil es nur ein Sample Schema ist, können Sie alternativ die betreffende Spalte auf DATE setzen und anschließend wieder auf TIMESTAMP(6) WITH LOCAL TIME ZONE zurücksetzen. Achtung, bei der letzten Variante gehen Informationen verloren!

Und was ist jetzt mit meinen Scheduler Jobs? Die richten sich schlicht nach der Zeit, die auf meinem Server eingestellt ist. Wenn man also Probleme hat, dass Datenbank Jobs nicht anlaufen wann sie eigentlich sollen, gilt es die Servereinstellungen zu überprüfen:

$ date

Sun Apr 24 14:36:01 CEST 2016

OS Zeiteinstellung aus der Datenbank heraus auslesen mit SYSTIMESTAMP:

SQL> select SYSTIMESTAMP from dual;

SYSTIMESTAMP
----------------------------------------------------------
24-APR-16 02.36.20.699547 PM +02:00

Zum Abschluß noch ein interessanter Beitrag der sich mit dem Thema Datum und Zeit in der Oracle Datenbank auseinander setzt im MOS: Doc ID 340512.1