CNDBA社区
环境
当前RAC环境系统时间整体慢了7分钟，客户反馈说不希望停机修改，故采用如下正确流程修改，但是呢，不管时间快还是慢，停集群停库修改都是最稳妥的…
错误流程
1、关闭节点2数据库、集群
2、修改节点2时间到正确时间
3、启动集群、数据库
4、关闭节点1
5、修改节点1时间到正确时间
6、启动集群、数据库
该流程看着没问题，其实是有问题的，因为RAC内部是ctss进程同步的，关闭某个节点，再启动集群，加入集群，需要通过ctss同步集群时间，这样一来，再执行第3步骤之后，等到ctss进程启动，你会发现你修改后的节点2时间还是节点1差不多的时间，也就是更改失效….
后面有个验证流程，也就是正确的流程…
关闭节点2
ORACLE用户：
shutdown immediate
root用户:
$GRID_HOME/bin/crsctl stop has -f
调整时间（修改停止2节点时间)
[root@rac2 bin]# timedatectl set-time "2018-08-30 13:05:05"
[root@rac2 bin]# date
Thu Aug 30 13:05:06 CST 2018
[root@rac2 bin]# hwclock --systohc
[root@rac2 bin]# hwclock --show
Thu 30 Aug 2018 01:05:19 PM CST -0.036329 seconds
[root@rac2 bin]# clock -w
[root@rac2 bin]# date
Thu Aug 30 13:05:32 CST 2018
启动集群数据库
$GRID_HOME/bin/crsctl start has
startup
验证时间
oracle@rac2:/home/oracle>date
Thu Aug 30 13:03:53 CST 2018
[root@rac2 bin]# date
Thu Aug 30 13:05:36 CST 2018
[root@rac2 bin]#
惊奇发现，被修改过的节点时间仍然变慢了，应该是备存活节点RAC中ctss时间同步给同步造成的,
正确流程
1、关闭2节点数据库
2、关闭2节点集群
3、修改存活1节点系统时间
4、启动关闭的2节点集群
5、验证系统时间
6、启动关闭的2节点数据库
其实，第4步骤，是可以手动到关闭的2节点修改时间，再去启动2节点的集群、数据库也是可以的，毕竟手工还是存在的误差更大些，这种的自己同步存在的时间误差更小….
1、关闭2节点：
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
2、关闭2节点集群
root用户:
$GRID_HOME/bin/crsctl stop has -f
3、修改1节点系统时间(存活节点)
[root@rac1 ~]# timedatectl set-time "2018-08-30 13:27:45"
[root@rac1 ~]# hwclock --systohc
[root@rac1 ~]# hwclock --show
Thu 30 Aug 2018 01:27:46 PM CST -0.971565 seconds
[root@rac1 ~]# clock -w
[root@rac1 ~]# date
Thu Aug 30 13:27:50 CST 2018
查看关闭2节点系统时间
[root@rac2 bin]# date
Thu Aug 30 13:23:55 CST 2018
4、启动关闭2节点集群
root用户:
$GRID_HOME/bin/crsctl start has
切换GRID用户,查看CTSS进程是否启动
当前未启动
ora.ctssd
1 ONLINE ONLINE rac2 ACTIVE:-370200
当前已启动
ora.ctssd
1 ONLINE ONLINE rac2 ACTIVE:0
5、再次验证查看2节点时间（需要等待ctssd进程启动)
grid@rac2:/home/grid>date
Thu Aug 30 13:34:21 CST 2018
[root@rac2 bin]# date
Thu Aug 30 13:34:24 CST 2018
可以看到二节点的时间已经被一节点的时间，利用CTSS时间同步进程同步了,至此，之前的为什么关闭的节点修改时间后，会被同步回去的原因找到了，而且我得应用网页也可以正常打开
6、oracle用户起库(2节点)
startup
版权声明：本文为博主原创文章，未经博主允许不得转载。
