事因：

創(chuàng)新互聯(lián)公司公司2013年成立，先為平谷等服務(wù)建站，平谷等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為平谷企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

征信數(shù)據(jù)庫數(shù)據(jù)事件不一致導(dǎo)致數(shù)據(jù)（RAC集群）混亂，PLSQL查詢時間和數(shù)據(jù)庫時間不一致，嚴(yán)重影響業(yè)務(wù)。因為之前只是偶遇一次，再加上有過MySQL時區(qū)解決經(jīng)驗，感覺應(yīng)該可以很快解決，然而，并非我想的那么簡單。如下是整個事件的經(jīng)過，算是經(jīng)驗分享吧。（有vsp，因此只能截圖）

1、查看兩臺服務(wù)器的本地時間，以及時區(qū)。

可以看到，Asia/Shanghai CST 北京時間東八區(qū)。（GMT代表格林尼治標(biāo)準(zhǔn)時間）

2、用sysdba查看本地時間：

AM表示上午,PM表示下午。沒有什么異常。
2.1）用其它普通賬號登錄

2.2）用PLSQL登錄普通賬號遠(yuǎn)程登錄查看

注意查看箭頭：變成了-8:00，時間慢了16小時。GMT-8，但是datatimezone沒問題。

提示：SYSDATE和SYSTIMESTAMP的值并不受數(shù)據(jù)庫參數(shù)DBTIMEZONE的影響，操作系統(tǒng)時區(qū)的環(huán)境變量(如TZ)會影響它們的輸入，因為SYSDATE和SYSTIMESTAMP實際是調(diào)用操作系統(tǒng)底層接口直接返回值。操作系統(tǒng)層面TZ環(huán)境變量的設(shè)置直接影響sysdate和systimestamp的值，同時也會影響數(shù)據(jù)庫日志寫入的時戳。

DBTIMEZONE的設(shè)置會影響數(shù)據(jù)庫內(nèi)兩種數(shù)據(jù)類型的值：

1）TimeStamp with Time Zone

2）TimeStamp with Local Time Zone。

3、排查環(huán)境變量設(shè)置

由于使用相同賬號，PLSQL遠(yuǎn)程登錄-8:00，查看別的數(shù)據(jù)庫都是+8:00，本地時間都是UTC:+8:00

因此，只能從數(shù)據(jù)庫方面查。

# srvctl getenv listener -l LISTENER -envs "TZ"

3.1）數(shù)據(jù)庫時區(qū)：

也發(fā)現(xiàn)沒異常。

排查思路：

無論從系統(tǒng)時間，數(shù)據(jù)庫時間，rac監(jiān)聽，環(huán)境變量，均未發(fā)現(xiàn)異常，很可能有人修改了參數(shù)。

解決方式：

和dba溝通，修改grid環(huán)境變量時區(qū) "Asia/Shanghai"，分批重啟數(shù)據(jù)庫，監(jiān)聽恢復(fù)之后，問題解決。