Oracle 11G RAC 本地时间和通过listener连接时间不相同的问题

最新推荐文章于 2020-09-15 15:58:07 发布

cuge240620

最新推荐文章于 2020-09-15 15:58:07 发布

阅读量172

点赞数

Normal 0 7.8 pt 0 2 false false false MicrosoftInternetExplorer4 Oracle 11G RAC 本地时间和通过listener连接时间不相同的问题

背景

客户生产数据库服务器重启后，本地时间和通过listener连接时间不相同的问题

,比我们实际时间要慢13个小时

操作系统版本:

AIX 6.1

数据库版本

Oracle 11.2.0.2 RAC

问题描述和诊断过程

1.使用本地直接登陆和在本地通过listener查询时间相差13个小时，初步定位为时区问题

bash-2.05b$ sqlplus "/as sysdba"

SQL> select to_char(sysdate,'yyyy-MM-dd HH24:mi:ss') from dual;

TO_CHAR(SYSDATE,'YYYY-MM-DDHH24:MI:SS'

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

2012-03-27 15:17:52

bash-2.05b$ sqlplus test/testaa@spprod

SQL> select to_char(sysdate,'yyyy-MM-dd HH24:mi:ss') from dual;

TO_CHAR(SYSDATE,'YYYY-MM-DDHH24:MI:SS'

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

2012-03-27 02:18:50

SQL>

2.根据上面推论，查看操作系统时区和数据库时区，发现时区都一致，都是正8区，说明操作系统时区或者数据库设置没有问题，这时候推断可能是listener有问题或者是sysdate远程取值有问题

bash-2.05b$ echo $TZ

Asia/Shanghai

bash-2.05b$

查看数据库时区

SQL> select dbtimezone from dual;

DBTIMEZONE

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

+08:00

3.根据上面推断可能是listener有问题或者sysdate取值有问题，我们先看一下sysdate的取值的原理，根据metalink [ID 227334.1], SYSDATE 和 SYSTIMESTAMP只是简单调用操作系统去取得时间，也就是说sysdate的取值来源于操作系统，oracle不会对sysdate的值进行处理，sysdate没有问题

4. sysdate问题排除，那就是listener的问题了，继续往下看，发现这这篇文档中也提到，操作系统时间和通过listener时间不一致的情况，出现这种情况可能是数据库启动时的时区和现在操作系统的时间不一致导致的，需要重启数据库和listener,在另一篇文档中[ID 301420.1]也说是这种情况导致的，解决方案也是重启数据库和listener

5.由于是RAC环境，打算一个节一个节点的重启，于是把两个节点的实例和CRS一个一个的进行重启

停节点2实例

bash-2.05b$ srvctl stop instance -d spprod -i spprod2

切换到root用户下面停CRS

bash-2.05b# /sporacle/11202/grid/bin/crsctl stop crs

上面crs启来之后再把实例启来，接下来我们重复上面操作，重启第一个节点

停实例1

bash-2.05b$ srvctl stop instance -d spprod -i spprod1

切换到root用户停CRS

bash-2.05b# /sporacle/11202/grid/bin/crsctl stop crs

6.重启之后发现和原来一样，说明不是这个问题，是不是和grid用户下管理ASM的实例时区也有关系呢？两个节点grid下面实例时区都是’+00.00’,于是查询公司另外的11G RAC环境,发现其它环境也一样，但是其它环境没有这个问题，基本可以排除这个问题

7.问题还没有解决，只能继续查了，最后找到了下面这篇文档How To Change Timezone for 11gR2 Grid Infrastructure [ID 1209444.1]，文档上面说在 oracle 11.2.0.1 grid直接读取操作系统时区，在oracle 11.2.0.2 grid的时区放在$GRID_HOME/crs/install/s_crsconfig__env.txt这个文件中，如果需要调整时间需要修改这个文件

8.根据文档查看s_crsconfig__env.txt发现时区为TZ=CST6CDT,刚好和我们时区相差13个小时，于是修改TZ=Asia/Shanghai

bash-2.05b# more s_crsconfig_spdb1_env.txt

### This file can be used to modify the NLS_LANG environment variable, which determines the charset to be used for messages.

### For example, a new charset can be configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8

### Do not modify this file except to change NLS_LANG, or under the direction of Oracle Support Services

TZ=CST6CDT

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

RT_GRQ=ON

TNS_ADMIN=

ORACLE_BASE=

修改s_crsconfig_spdb1_env.txt的TZ=Asia/Shanghai (别忘记两个节点都需要修改)

9.修改好之后重启database和CRS，问题解决