Zeitzone für DBaaS ändern

Für ein aktuelles Projekt haben wir die nötige Infrastruktur mit Hilfe der Oracle Cloud Infrastructure (OCI) aufgebaut. Neben Applikationsservern, die als Compute Instances realisiert wurden, wurde auch eine Datenbank benötigt. Diese wurde als Bare Metal Database Service eingerichtet. Da der Kunde in Neuseeland ansässig ist, entstand die Anforderung, mit der dortigen Zeitzone zu arbeiten. In der Cloud wird jedoch die Uinversal Time (UTC) verwendet, was ja auch erst einnmal Sinn ergibt. 

[oracle@ecotes-dbt ~]$ date

Thu Nov 14 07:05:29 UTC 2019

 

SQL> select sysdate from dual;

 

SYSDATE

----------------

14.11.2019 07:06

Wir mussten die Zeitzone also ändern. Für den zugrunde liegenden Server wird dazu einfach der Link /etc/localtime entsprechend angepasst.

[root@ecotes-dbt ~]# ll /etc/localtime

lrwxrwxrwx 1 root root 23 Oct 7 06:51 /etc/localtime -> /usr/share/zoneinfo/UTC

[root@ecotes-dbt ~]# ll /usr/share/zoneinfo/NZ

-rw-r--r-- 4 root root 2434 Jan 29 2018 /usr/share/zoneinfo/NZ

[root@ecotes-dbt ~]# ll /usr/share/zoneinfo/Pacific/Auckland

-rw-r--r-- 4 root root 2434 Jan 29 2018 /usr/share/zoneinfo/Pacific/Auckland

[root@ecotes-dbt ~]# rm /etc/localtime

rm: remove symbolic link `/etc/localtime'? y

[root@ecotes-dbt ~]# ln -s /usr/share/zoneinfo/Pacific/Auckland /etc/localtime

[root@ecotes-dbt ~]# ll /etc/localtime

lrwxrwxrwx 1 root root 36 Nov 14 20:10 /etc/localtime -> /usr/share/zoneinfo/Pacific/Auckland

 

[oracle@ecotes-dbt ~]$ date

Thu Nov 14 20:11:31 NZDT 2019

Die Datenbank verwendet in der Folge nun die angepasste Zeitzone.

SQL> select sysdate from dual;

 

SYSDATE

----------------

14.11.2019 20:11

Das ist aber nur die halbe Wahrheit, denn der Scheduler der Oracle Datenbank hat eine eigene Einstellung, die die verwendete Zeitzone definiert.

SQL> SELECT *

2 FROM dba_scheduler_global_attribute

3 WHERE attribute_name = 'DEFAULT_TIMEZONE';

 

ATTRIBUTE_NAME VALUE

---------------------- -----------

DEFAULT_TIMEZONE Etc/UTC

 

SQL> select dbms_scheduler.stime from dual;

 

STIME

---------------------------------------------------------------------------

14-NOV-19 08.26.59.556872000 AM ETC/UTC

Diese muss also ebenfalls noch angepasst werden. Das geschieht mittels DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE und ist am Ende ein Einzeiler.

SQL> exec DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('default_timezone', 'Pacific/Auckland');

 

PL/SQL procedure successfully completed.

 

SQL> SELECT *

2 FROM dba_scheduler_global_attribute

3 WHERE attribute_name = 'DEFAULT_TIMEZONE';

 

ATTRIBUTE_NAME VALUE

---------------------- -----------

DEFAULT_TIMEZONE Pacific/Auckland

 

SQL> select dbms_scheduler.stime from dual;

 

STIME

---------------------------------------------------------------------------

14-NOV-19 09.31.26.365519000 PM PACIFIC/AUCKLAND

Mehr ist nicht zu tun. Der Scheduler benutzt nun ebenfalls die Zeitzone für Neuseeland.

Update 20.12.2019

Nicht zu vergessen bei der Umstellung der Zeitzone ist natürlich auch der Server selbst. Denn die Datenbank Sessions erben ihre NLS Einstellungen vom Listener, der den zugehörigen Serverprozess erzeugt. Eine komplette Checkliste zum Anpassen der Zeitzone findet sich in MOS Note 1627439.1.

Die Zeitzone wird in /etc/sysconfig/clock angepasst. Die möglichen Einstellungen für die Zeitzone finden sich unter /usr/share/zoneinfo.

$ cat /etc/sysconfig/clock

ZONE="Pacific/Auckland"

UTC=true

ARC=false

Zuvor sollte geprüft werden, ob die Uhrzeiten für UTC und die gewünschte Zeitzone stimmig sind.

$ export TZ=UTC

$ date

Fri Dec 20 11:53:48 UTC 2019

$ export TZ=Pacific/Auckland

$ date

Sat Dec 21 00:53:52 NZDT 2019

Auch in der Clusterware und den Resourceneinstellungen müssen ggf. noch Anpassungen vorgenommen werden. Die nötigen Schritte dazu finden sich im Abschnitt D) der genannten Note. Am besten setzt man die gewünschte Zeitzone nur in $GRID_HOME/crs/install/s_crsconfig_<HOSTNAME>_env.txt:

$ grep ^TZ $GRID_HOME/crs/install/s_crsconfig_$(hostname -s)_env.txt

TZ=Pacific/Auckland

Alle anderen resourcenspecifischen Einstellungen entfernt man per "srvctl unsetenv [database | asm | listener] -envs TZ", dann erben die Resourcen die Einstellung direkt von der Clusterware.

Ist all das erledigt, muss der gesamte Stack ab Oberkante Betriebssystem einmal neu gestartet werden um überall die geänderten Einstellungen zu aktivieren.


Über den Autor

Marco Mischke

Weitere Beiträge dieses Autors

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich