事因：
徵信數據庫數據事件不一致導致數據（RAC集羣）混亂，PLSQL查詢時間和數據庫時間不一致，嚴重影響業務。因爲之前只是偶遇一次，再加上有過MySQL時區解決經驗，感覺應該可以很快解決，然而，並非我想的那麼簡單。如下是整個事件的經過，算是經驗分享吧。（有vsp，因此只能截圖）
1、查看兩臺服務器的本地時間，以及時區。
可以看到，Asia/Shanghai CST 北京時間東八區。（GMT代表格林尼治標準時間）
2、用sysdba查看本地時間：
AM表示上午,PM表示下午。沒有什麼異常。 2.1）用其它普通賬號登錄
2.2）用PLSQL登錄普通賬號遠程登錄查看
注意查看箭頭：變成了-8:00，時間慢了16小時。GMT-8，但是datatimezone沒問題。
提示：SYSDATE和SYSTIMESTAMP的值並不受數據庫參數DBTIMEZONE的影響，操作系統時區的環境變量(如TZ)會影響它們的輸入，因爲SYSDATE和SYSTIMESTAMP實際是調用操作系統底層接口直接返回值。操作系統層面TZ環境變量的設置直接影響sysdate和systimestamp的值，同時也會影響數據庫日誌寫入的時戳。
DBTIMEZONE的設置會影響數據庫內兩種數據類型的值：
1）TimeStamp with Time Zone
2）TimeStamp with Local Time Zone。
3、排查環境變量設置
由於使用相同賬號，PLSQL遠程登錄-8:00，查看別的數據庫都是+8:00，本地時間都是UTC:+8:00
因此，只能從數據庫方面查。
# srvctl getenv listener -l LISTENER -envs "TZ"
3.1）數據庫時區：
也發現沒異常。
排查思路：
無論從系統時間，數據庫時間，rac監聽，環境變量，均未發現異常，很可能有人修改了參數。
解決方式：
和dba溝通，修改grid環境變量時區 "Asia/Shanghai"，分批重啓數據庫，監聽恢復之後，問題解決。