重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
事因:
创新互联公司坚持“要么做到,要么别承诺”的工作理念,服务领域包括:网站设计、网站制作、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的鼓楼网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!征信数据库数据事件不一致导致数据(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",分批重启数据库,监听恢复之后,问题解决。
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。