环境
当前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
