客戶生產(chǎn)數(shù)據(jù)庫服務(wù)器重啟后，本地時間和通過listener連接時間不相同的問題,比我們實際時間要慢13個小時。

背景

客戶生產(chǎn)數(shù)據(jù)庫服務(wù)器重啟后，本地時間和通過listener連接時間不相同的問題,比我們實際時間要慢13個小時。

操作系統(tǒng)版本:AIX 6.1

數(shù)據(jù)庫版本

Oracle 11.2.0.2 RAC

問題描述和診斷過程

1.使用本地直接登陸和在本地通過listener查詢時間相差13個小時，初步定位為時區(qū)問題

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> selectto_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.根據(jù)上面推論，查看操作系統(tǒng)時區(qū)和數(shù)據(jù)庫時區(qū)，發(fā)現(xiàn)時區(qū)都一致，都是正8區(qū)，說明操作系統(tǒng)時區(qū)或者數(shù)據(jù)庫設(shè)置沒有問題，這時候推斷可能是listener有問題或者是sysdate遠(yuǎn)程取值有問題

bash-2.05b$ echo $TZ

Asia/Shanghai

bash-2.05b$

查看數(shù)據(jù)庫時區(qū)

SQL> select dbtimezone from dual;

DBTIMEZONE

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

+08:00

3.根據(jù)上面推斷可能是listener有問題或者sysdate取值有問題，我們先看一下sysdate的取值的原理，，根據(jù)metalink [ID 227334.1],SYSDATE和 SYSTIMESTAMP只是簡單調(diào)用操作系統(tǒng)去取得時間，也就是說sysdate的取值來源于操作系統(tǒng)，oracle不會對sysdate的值進(jìn)行處理，sysdate沒有問題

4. sysdate問題排除，那就是listener的問題了，繼續(xù)往下看，發(fā)現(xiàn)這這篇文檔中也提到，操作系統(tǒng)時間和通過listener時間不一致的情況，出現(xiàn)這種情況可能是數(shù)據(jù)庫啟動時的時區(qū)和現(xiàn)在操作系統(tǒng)的時間不一致導(dǎo)致的，需要重啟數(shù)據(jù)庫和listener,在另一篇文檔中[ID 301420.1]也說是這種情況導(dǎo)致的，解決方案也是重啟數(shù)據(jù)庫和listener

5.由于是RAC環(huán)境，打算一個節(jié)一個節(jié)點的重啟，于是把兩個節(jié)點的實例和CRS一個一個的進(jìn)行重啟

停節(jié)點2實例

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

切換到root用戶下面停CRS

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

上面crs啟來之后再把實例啟來，接下來我們重復(fù)上面操作，重啟第一個節(jié)點

停實例1

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

切換到root用戶停CRS

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

6.重啟之后發(fā)現(xiàn)和原來一樣，說明不是這個問題，是不是和grid用戶下管理ASM的實例時區(qū)也有關(guān)系呢？兩個節(jié)點grid下面實例時區(qū)都是’+00.00’,于是查詢公司另外的11G RAC環(huán)境,發(fā)現(xiàn)其它環(huán)境也一樣，但是其它環(huán)境沒有這個問題，基本可以排除這個問題

7.問題還沒有解決，只能繼續(xù)查了，最后找到了下面這篇文檔How To Change Timezone for 11gR2Grid Infrastructure [ID 1209444.1]，文檔上面說在oracle 11.2.0.1 grid直接讀取操作系統(tǒng)時區(qū)，在oracle 11.2.0.2 grid的時區(qū)放在$GRID_HOME/crs/install/s_crsconfig__env.txt這個文件中，如果需要調(diào)整時間需要修改這個文件

8.根據(jù)文檔查看s_crsconfig__env.txt發(fā)現(xiàn)時區(qū)為TZ=CST6CDT,剛好和我們時區(qū)相差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 settingNLS_LANG=JAPANESE_JAPAN.UTF8

### Do not modify this file except to change NLS_LANG, or under thedirection 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 (別忘記兩個節(jié)點都需要修改)

9.修改好之后重啟database和CRS，問題解決

10.總結(jié)

估計為安裝oracleCRS的時候操作系統(tǒng)時區(qū)為CST6CDT，安裝之后有人修改過操作系統(tǒng)時區(qū)和數(shù)據(jù)庫時區(qū)。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com