事因：
征信数据库数据事件不一致导致数据（RAC集群）混乱，PLSQL查询时间和数据库时间不一致，严重影响业务。因为之前只是偶遇一次，再加上有过MysqL时区解决经验，感觉应该可以很快解决，然而，并非我想的那么简单。如下是整个事件的经过，算是经验分享吧。（有vsp，因此只能截图）
1、查看两台服务器的本地时间，以及时区。
可以看到，Asia/Shanghai CST 北京时间东八区。（GMT代表格林尼治标准时间）
2、用sysdba查看本地时间：
AM表示上午,PM表示下午。没有什么异常。 2.1）用其它普通账号登录
注意查看箭头：变成了-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"，分批重启数据库，监听恢复之后，问题解决。
原文地址：https://www.jb51.cc/oracle/207577.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
