[OCI] ほん怖：DBシステムを再起動したら、クライアントアプリでのsysdateの結果が日本時間からUTCになった話

# はじめに
Oracle Database Cloud ServiceのDBシステムの構築にあたって、検証環境ではストレージ管理にLVM、本番環境ではOracleが推奨するGrid Infrastructureを利用する、という話はよくあります。

ただし、OCI DBシステムのLVM環境とGrid Infrastructure環境の違いを理解していないと、予期せぬトラブルに遭遇することがありますので注意が必要です。

今回遭遇したのは、1年近く安定して稼働していたDBシステムを諸事情のため再起動したところ、OS再起動前はクライアントでsysdateを実行した際に日本時間（Asia/Tokyo）を返していたのに、OS再起動後はUTCを返すようになってしまったというトラブルです。

このケースをもとに、LVM環境とGrid Infrastructure環境の違いを確認しました。

※なお、上記のDBシステムを作成した頃は、DBシステム作成時のタイムゾーンはUTC固定でした。現在はDBシステム作成時にDBシステムのタイムゾーンを指定することができます。


# 1.LVM環境でのタイムゾーンの設定

LVM環境では、基本的に、OSのタイムゾーン設定を変更することで、ローカル（Bequeath）接続、リスナー経由接続ともにsysdate、systimestampはOSのタイムゾーンの日時を返します。
（oracleユーザの環境変数にTZが指定されていれば、そちらが優先されますが）

ストレージ管理ソフトウェアにLVMを選択し、タイムゾーンにUTCを選んで作成したDBシステムにopcユーザでログインし、現在のOSの時刻設定を確認します。

```
[opc@db19ceelvm ~]$ timedatectl
      Local time: Fri 2020-11-13 06:25:43 UTC
  Universal time: Fri 2020-11-13 06:25:43 UTC
        RTC time: Fri 2020-11-13 06:25:43
       Time zone: UTC (UTC, +0000)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
[opc@db19ceelvm ~]$ 
```
タイムゾーンがUTCであることが確認できます。
ここでtimedatectlコマンドでタイムゾーンをAsia/Tokyoに変更します。

```
[opc@db19ceelvm ~]$ sudo timedatectl set-timezone Asia/Tokyo
[opc@db19ceelvm ~]$ timedatectl
      Local time: Fri 2020-11-13 15:29:43 JST
  Universal time: Fri 2020-11-13 06:29:43 UTC
        RTC time: Fri 2020-11-13 06:29:43
       Time zone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
[opc@db19ceelvm ~]$
```
まず、ローカル（Bequeath）接続でsysdate、systimestampの結果を確認します。

```
[opc@db19ceelvm ~]$ sudo su - oracle
Last login: Fri Nov 13 15:23:13 JST 2020
[oracle@db19ceelvm ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 15:33:43 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 03.34.00.062301 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 15:34:29

SQL>exit
```
sysdate、systimestampともにOSのタイムゾーンの日時が出力されました。

次にリスナー経由で接続し、sysdate、systimestampの結果を確認します。

```
[oracle@db19ceelvm ~]$ sqlplus sys/Demo#1Demo#1@db1_nrt1nr as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 15:31:41 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 03.31.55.100308 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 15:33:12

SQL> exit
```
こちらもsysdate、systimestampともにOSのタイムゾーンの日時が出力されました。

# 2.Grid Infrastructure環境でのタイムゾーン 設定

では、Grid Infrastructureの環境で同様の操作をしてみます。

ストレージ管理ソフトウェアにGrid Infrastructureを選択し、タイムゾーンにUTCを選んで作成したDBシステムにopcユーザでログインし、現在のOSの時刻設定を確認します。

```
[opc@db19ceegi ~]$ timedatectl
      Local time: Fri 2020-11-13 07:17:37 UTC
  Universal time: Fri 2020-11-13 07:17:37 UTC
        RTC time: Fri 2020-11-13 07:17:37
       Time zone: UTC (UTC, +0000)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
```
タイムゾーンがUTCであることが確認できます。
ここでtimedatectlコマンドでタイムゾーンをAsia/Tokyoに変更します。

```
[opc@db19ceegi ~]$ sudo timedatectl set-timezone Asia/Tokyo
[opc@db19ceegi ~]$ timedatectl
      Local time: Fri 2020-11-13 16:19:02 JST
  Universal time: Fri 2020-11-13 07:19:02 UTC
        RTC time: Fri 2020-11-13 07:19:02
       Time zone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
[opc@db19ceegi ~]$ 
```
LVMの場合と同様に、まずローカル（Bequeath）接続でsysdate、systimestampの結果を確認します。

```
[opc@db19ceegi ~]$ sudo su - oracle
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:23:11 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 04.23.24.351472 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 16:23:46

SQL> exit
```
sysdate、systimestampともにOSのタイムゾーンの日時が出力されました。

次に、リスナー経由の接続です。

```
[oracle@db19ceegi ~]$ sqlplus sys/Demo#1Demo#1@DB1_NRT1NW as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:21:35 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 07.21.44.710928 AM +00:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 07:22:15

SQL> exit
```

おっと、リスナー経由の接続ではsysdate、systimestampともにUTCの時間が返ってきました。
ここで、oracleユーザの環境変数にTZ=Asia/Tokyoを設定し、DBインスタンスを再起動してみます。

```
[oracle@db19ceegi ~]$ export TZ=Asia/Tokyo
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:25:51 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> 
SQL> startup
ORACLE instance started.

Total System Global Area 6442449472 bytes
Fixed Size		    9148992 bytes
Variable Size		 1140850688 bytes
Database Buffers	 5268045824 bytes
Redo Buffers		   24403968 bytes
Database mounted.
Database opened.
SQL> exit
```
DBインスタンスの再起動が完了したので、再度確認してみます。
まずはローカル（Bequeath）接続から。

```
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:31:52 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 04.32.28.892999 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 16:33:01

SQL> exit
```
次にリスナー経由の接続です。

```
[oracle@db19ceegi ~]$ sqlplus sys/Demo#1Demo#1@DB1_NRT1NW as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:30:20 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 04.30.35.318216 PM +09:00

SQL> SELECT dbtimezone FROM dual;

DBTIME
------
+00:00

SQL> SELECT sessiontimezone FROM dual;

SESSIONTIMEZONE
---------------------------------------------------------------------------
+09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 16:30:56

SQL> exit 
```
今度はリスナー経由でもsysdate、systimestampともにOSのタイムゾーン （Asia/Tokyo）での日時が返ってきました。めでたし、めでたし。

**と言いたいところですが、そうは問屋がおろしません。**

oracleユーザの環境変数にTZ=Asia/Tokyoを設定したことでOSのタイムゾーンがsysdate、systimedateに反映されたので、こちらを.bash_profileに設定します。

```
[oracle@db19ceegi ~]$ vi .bash_profile

# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH
umask 022

#以下を行を追加
TZ=Asia/Tokyo

```
oracleユーザの環境変数の設定ができたので、oracleユーザからopcユーザに戻り、OSを再起動します。

```
[oracle@db19ceegi ~]$ exit
[opc@db19ceegi ~]$ sudo shutdown -r now
```
まずはローカル（Bequeath）接続から確認します。

```
[opc@db19ceegi ~]$ sudo su - oracle
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:44:29 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 04.44.46.473568 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 16:45:10

SQL> exit
```
次にリスナー経由の接続です。

```
[oracle@db19ceegi ~]$ sqlplus sys/Demo#1Demo#1@db1_nrt1nw as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:46:25 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 07.46.37.436989 AM +00:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 07:46:59

SQL> exit
```

なんと、oracleユーザの環境変数にTZ=Asia/Japanを設定しているにも関わらず、sysdate、systimestampはUTCの時間を返してきました。

なんでだろ〜、なんでだろ〜ということで、まずはリスナープロセスを確認してみます。

LVM環境のリスナープロセスがこちら。

```
[oracle@db19ceelvm ~]$ ps -ef | grep lsnr                             
oracle    1807     1  0 15:50 ?        00:00:00 /u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr LISTENER -inherit
oracle   38136  3835  0 16:50 pts/0    00:00:00 grep --color=auto lsnr
```
リスナープロセスのオーナーはoracleです。

GI環境のリスナープロセスがこちらです。

```
[oracle@db19ceegi ~]$ ps -ef | grep lsnr
grid      8927     1  0 16:42 ?        00:00:00 /u01/app/19.0.0.0/grid/bin/tnslsnr LISTENER -no_crs_notify -inherit
grid      8948     1  0 16:42 ?        00:00:00 /u01/app/19.0.0.0/grid/bin/tnslsnr ASMNET1LSNR_ASM -no_crs_notify -inherit
oracle   27762  4042  0 16:50 pts/0    00:00:00 grep --color=auto lsnr
```
おっと、こちらはリスナープロセスのオーナーがgridになっています。

LVM環境とGrid Infrastructure環境の違いとして、Grid Infrastructure環境では、Oracle、リスナー、その他関連プロセスの起動はクラスタウェア経由で行われます。

実はそこに鍵があります。

ここでクラスタウェアの設定ファイルをみてみます。

```
[opc@db19ceegi ~]$ sudo su -
Last login: Fri Nov 13 16:32:03 JST 2020
[root@db19ceegi ~]# cd /u01/app/19.0.0.0/grid/crs/install/
[root@db19ceegi install]# vi s_crsconfig_db19ceegi_env.txt

#########################################################################
#This file can be used to set values for the NLS_LANG and TZ environment
#variables and to set resource limits for Oracle Clusterware and
#Database processes.
#1. The NLS_LANG environment variable determines the language and
#   characterset used for messages. For example, a new value can be
#   configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8
#2. The Time zone setting can be changed by setting the TZ entry to
#   the appropriate time zone name. For example, TZ=America/New_York
#3. Resource limits for stack size, open files and number of processes
#   can be specified by modifying the appropriate entries.
#
#Do not modify this file except as documented above or under the
#direction of Oracle Support Services.
#########################################################################
TZ=UTC
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
CRS_LIMIT_STACK=2048
CRS_LIMIT_OPENFILE=65536
CRS_LIMIT_NPROC=65536
TNS_ADMIN=
```
クラスタウェアの環境変数として、TZ=UTCが設定されています。
リスナー経由での接続の際にsysdate、systimestampがUTCの日時を返していたのは、この設定が影響していたわけです。

というわけで、こちらをAsia/Tokyoに書き換えます。

```
#########################################################################
#This file can be used to set values for the NLS_LANG and TZ environment
#variables and to set resource limits for Oracle Clusterware and
#Database processes.
#1. The NLS_LANG environment variable determines the language and
#   characterset used for messages. For example, a new value can be
#   configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8
#2. The Time zone setting can be changed by setting the TZ entry to
#   the appropriate time zone name. For example, TZ=America/New_York
#3. Resource limits for stack size, open files and number of processes
#   can be specified by modifying the appropriate entries.
#
#Do not modify this file except as documented above or under the
#direction of Oracle Support Services.
#########################################################################
TZ=Asia/Tokyo
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
CRS_LIMIT_STACK=2048
CRS_LIMIT_OPENFILE=65536
CRS_LIMIT_NPROC=65536
TNS_ADMIN=
```
ここで、クラスタデータベースの環境構成を確認するのに必要なDB_UNIQUE_NAMEを確認しておきます。

```
[root@db19ceegi install]# exit
logout
[opc@db19ceegi ~]$ sudo su - oracle
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 16:58:27 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT db_unique_name FROM v$database;

DB_UNIQUE_NAME
------------------------------
DB1_nrt1nw

SQL> exit
Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0
[oracle@db19ceegi ~]$ 
```

サーバ制御コマンドsrvctl getenv databaseで、現在のクラスタデータベース環境構成を確認します。

```
[oracle@db19ceegi ~]$ srvctl getenv database -d DB1_nrt1nw
DB1_nrt1nw:
ORACLE_UNQNAME=DB1_nrt1nw
TZ=UTC
```
TZ=UTCがセットされているので、こちらをsrvctl setenv databaseでTZ=Asia/Tokyoに変更します。

```
[oracle@db19ceegi ~]$ srvctl setenv database -d DB1_nrt1nw -T "TZ=Asia/Tokyo"
[oracle@db19ceegi ~]$ srvctl getenv database -d DB1_nrt1nw
DB1_nrt1nw:
ORACLE_UNQNAME=DB1_nrt1nw
TZ=Asia/Tokyo
```
これでクラスタウェア、データベース環境構成の変更が完了しました。
ここでクラスタウェアを再起動（停止/起動）します。

```
[oracle@db19ceegi ~]$ exit
logout
[opc@db19ceegi ~]$ sudo su -
Last login: Fri Nov 13 16:55:37 JST 2020 on pts/0
[root@db19ceegi ~]# cd /u01/app/19.0.0.0/grid/bin/
[root@db19ceegi bin]# ./crsctl stop cluster
CRS-2673: Attempting to stop 'ora.crsd' on 'db19ceegi'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'db19ceegi'
CRS-2673: Attempting to stop 'ora.data.commonstore.acfs' on 'db19ceegi'
CRS-2673: Attempting to stop 'ora.qosmserver' on 'db19ceegi'
CRS-2673: Attempting to stop 'ora.db1_nrt1nw.db' on 'db19ceegi'
CRS-2673: Attempting to stop 'ora.chad' on 'db19ceegi'
CRS-2677: Stop of 'ora.data.commonstore.acfs' on 'db19ceegi' succeeded
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
CRS-2673: Attempting to stop 'ora.cssd' on 'db19ceegi'
CRS-2677: Stop of 'ora.cssd' on 'db19ceegi' succeeded
[root@db19ceegi bin]# 
[root@db19ceegi bin]# ./crsctl start cluster
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'db19ceegi'
CRS-2672: Attempting to start 'ora.evmd' on 'db19ceegi'
CRS-2676: Start of 'ora.cssdmonitor' on 'db19ceegi' succeeded
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
CRS-2672: Attempting to start 'ora.crsd' on 'db19ceegi'
CRS-2676: Start of 'ora.crsd' on 'db19ceegi' succeeded
[root@db19ceegi bin]#
[root@db19ceegi bin]# exit
logout
[opc@db19ceegi ~]$ 
```
ここで再度sysdate、systimestampを確認します。
まずはローカル接続から。

```
[opc@db19ceegi ~]$ sudo su - oracle
Last login: Fri Nov 13 17:04:06 JST 2020
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 17:08:17 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 05.08.32.512614 PM +09:00

SQL> SELECT dbtimezone FROM dual;

DBTIME
------
+00:00

SQL> SELECT sessiontimezone FROM dual;

SESSIONTIMEZONE
---------------------------------------------------------------------------
+09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 17:08:52

SQL> exit
```
次にリスナー経由の接続です。

```
[oracle@db19ceegi ~]$ sqlplus sys/Demo#1Demo#1@db1_nrt1nw as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 17:09:55 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 05.10.06.752437 PM +09:00

SQL> SELECT dbtimezone FROM dual;

DBTIME
------
+00:00

SQL> SELECT sessiontimezone FROM dual;

SESSIONTIMEZONE
---------------------------------------------------------------------------
+09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 17:10:26

SQL> exit
```
リスナー経由の接続でもsysdate、systimestampはAsia/Tokyoの日時で返ってきました。
では、OSを再起動してみます。

```
[oracle@db19ceegi ~]$ exit
logout
[opc@db19ceegi ~]$ sudo shutdown -r now
```
再起動が完了したら、またまた確認です。
まずはローカル接続。

```
[opc@db19ceegi ~]$ sudo su - oracle
[oracle@db19ceegi ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 17:17:17 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 05.18.03.155739 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 17:18:29

SQL> exit
```
次にリスナー経由の接続です。

```
[oracle@db19ceegi ~]$ sqlplus sys/Demo#1Demo#1@db1_nrt1nw as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Nov 13 17:18:59 2020
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.9.0.0.0

SQL> SELECT systimestamp FROM dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
13-NOV-20 05.19.08.795559 PM +09:00

SQL> SELECT TO_CHAR(sysdate, 'YYYY-MM-DD HH24:Mi:SS') FROM dual;

TO_CHAR(SYSDATE,'YY
-------------------
2020-11-13 17:19:28

SQL> exit
```
今度はOSを再起動したあとにリスナー経由で接続した場合でも、sysdate、systimestampはAsia/Tokyoの日時を返すようになりました。

# まとめ
以上の確認結果から、今回のトラブルは、Oracleユーザの環境変数にTZ=Asia/Tokyoを設定した状態でデータベースのみを再起動してそのまま運用していたので、sysdate、systimestampは日本時間を返していましたが、OS再起動によってデータベースがクラスタウェアによって起動されたため、再起動後はsysdate、systimestampがクラスタウェアのタイムゾーンであるUTCで返るようになったことが原因と推測されます。

同じDatabase CloudのDBシステムでも、ストレージ管理ソフトウェアによってシステム構成、Oracle Databaseの起動プロセスが異なります。これらの違いをきちんと理解して、思わぬトラブルが発生しないようにしたいですね。

# 参考情報
[How to change the Time Zone in Oracle Database Hosted in OCI with an Example（Doc ID 2459830.1）](https://support.oracle.com/knowledge/Oracle%20Cloud/2459830_1.html)