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，問題解決

10.總結

估計為安裝oracle CRS的時候作業系統時區為CST6CDT，安裝之後有人修改過作業系統時區和資料庫時區

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/21605631/viewspace-720087/，如需轉載，請註明出處，否則將追究法律責任。