溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
事因：
征信數據庫數據事件不一致導致數據（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"，分批重啟數據庫，監聽恢復之后，問題解決。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
