grid管理的数据库实例修改时区问题

问题描述

由于安装创建数据库之前没将操作系统的时区设置为本地正确的时区（Pacific/Apia），使用的是GMT时间（UTC时区），后续将操作系统和数据库修改成正确时区之后，发现sysdate显示有误。

服务端（sqlplus / as sysdba）访问显示的sysdate正确：

客户端访问数据库的sysdate显示的还是UTC时间：

操作系统修改时区命令：

timedatectl set-timezone "Pacific/Apia"

数据库修改时区命令：

alter database set time_zone='+13:00';

且修改完时区数据库已重启

hwclock --show显示的硬件时间也正确

ll /etc/localtime显示的时区也正确

问题排查思路：

（1）首先确定sysdate的取值定义

即sysdate取的是oracle数据库所在服务器上的操作系统时间

（2）检查服务端OS时区和时间

检查操作系统的时间和时区配置，其中有个RTC的配置有warning，建议关闭RTC再重连试下

timedatectl set-local-rtc 0

RTC关闭后，客户端重连sysdate依旧显示UTC时间

（3）建议服务端通过监听再连接下看sysdate

 从而确定通过监听连接的sysdate都有问题

检查监听配置：grid用户的$ORACLE_HOME/dbs目录下配置了listener.ora,oracle用户下没有，且listener.ora配置正常，怀疑是grid管理下的某些时区相关的配置没修改

（4）查询相关文档

参考文档<2831909.1>和<1209444.1>，在grid管理的数据库修改操作系统时区后，需要更改grid用户下的$ORACLE_HOME/crs/install/s_crsconfig_${HOSTNAME}_env.txt文件中的TZ配置

原来的配置为GMT：

更改为Pacific/Apia

然后grid用户重启has服务即可

crsctl stop/start has

重启之后，再次通过监听连接数据库，发现sysdate显示不再是UTC时间

如果有备机，也需要修改备机配置

问题总结

grid管理的数据库实例，修改操作系统时区配置后，需要将grid的某些配置文件也需要同步更新

但最好避免后期的更改时区操作，尽量在安装grid之前就将操作系统时区确定好，避免不必要的麻烦

问题2描述：

dbca新建的数据库发现dbtimezone与操作系统时区不同

经查阅文档，发现与dbca选择了/oracle/product/19c/assistants/dbca/templates/General_Purpose.dbc有关，可以选择/oracle/product/19c/assistants/dbca/templates/New_Database.dbt避免数据库时区和操作系统时区不一致问题