oracle修改时区

本文记录了在ORACLERAC环境中修改时区时遇到的问题,包括停服、系统时间设置、sysdate不一致以及发现CRS参数文件影响。最终通过备份并修改参数文件,重启CRS解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

记录一次生产环境修改时区的坑

生产环境发现ORACLE时区不正确,RAC环境

客户自己提出的修改方案如下步骤

1、停止数据库

srvctl stop database -d 库名

2、停止CRS集群服务

/u01/app/19c/grid/bin/crsctl disable crs
/u01/app/19c/grid/bin/crsctl stop crs

3、停止完成后,修改系统时区

timedatectl set-timezone "Asia/Shanghai"
 timedatectl
 reboot

这边重启了一下服务器,其实没有必要

4、重启完成后,业务发现查看sysdate的时间还是不对,但是我们数据库本地查看的时间的对的

select to_char(sysdate,'yyyy-mm-dd hh24:mm:ss') from dual;

发现:远程客户端查询的结果跟 本地sqlplus 查寻的结果不同。

第一反应是检查数据库内置的时区,后发现数据库内置时区虽然不对,但是参考mos说明。内置时区不影响正常select结果。

第二反应可能是监听问题,修改时区如果监听不重启,或者不重启PMON进程。会出现sysdate依然不正确的情况。但是我们CRS都重启过的呀

5、后查询资料,发现CRS本身也存在时区信息的参数文件

cd $GRID_HOME/crs/install目录下 s_crsconfig_<nodename>_env.txt文件

6、找到可能问题原因后,备份并修改此参数文件,关库,重启CRS后sysdate恢复正常


 

Oracle 34时区补丁是针对Oracle数据库时区信息更新的一个补丁。在2019年,世界各地进行了一次全球时区信息调整,这次调整为了反映出国际标准的UTC时间,使得全球的时区信息得到了修改和更新。Oracle数据库作为一个全球性的数据库系统,自然也要跟随这次时区信息调整进行相应的更新。 然而,这次更新并不是一次简单的更新。由于全球时区的复杂性和历史悠久性,时区信息的更新覆盖面非常广,涉及到数据库中大量的时间函数和时区组件等,如何确保所有组件和函数的正确性和兼容性,是一个极具挑战性的问题。因此Oracle公司发布了针对这次时区信息调整的34时区补丁,以解决这个问题。 这个补丁主要包含了两个方面的内容。首先,它会更新Oracle数据库中的时区组件,确保时区信息更新后的正确性和兼容性;其次,它还会更新数据库中已有的时间函数和日期数据,防止出现时间计算错误等问题。 对于使用Oracle数据库的用户而言,安装这个补丁对于保证数据的正确性和完整性至关重要。因此,Oracle公司也对这个补丁的安装给出了详细的指导和说明,用户在进行更新前,应该先认真阅读文档和备份数据,以避免出现不可预期的问题。 总之,Oracle 34时区补丁是为了保证Oracle数据库系统中时区信息的正确性和兼容性而发布的,对于使用Oracle数据库的用户来说是十分重要和必要的。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值