Oracle RAC集群时间不一致怎么修？配置NTP服务同步时间

先说一个核心结论：处理Oracle RAC集群的时间同步问题，最忌讳的就是“头痛医头，脚痛医脚”。手动执行ntpdate强行对齐，或者放任部分节点开着ntpd、部分节点关着——这些做法，恰恰是时间差越滚越大的根源。问题的本质在于，只要有一个节点的ntpd在运行且未按Oracle的规则配置，整个集群的ctssd就会自动退居observer mode，彻底丧失自适应同步能力。

检查 ctssd 是不是已经掉进 observer mode

动手调整任何配置之前，第一步永远是先诊断。你得先确认集群的时间同步机制是否已经“罢工”了。

• 执行命令crsctl check ctss。如果返回结果是CTSS is in observer mode，那就意味着CTSS已经放弃了控制权，正处在“围观”状态——它以为NTP在干活，但实际情况往往是NTP自身也并不可靠。
• 同时，别忘了在所有节点上运行date命令对比一下时间。差值超过±500毫秒就已经属于高风险；一旦超过1秒，ORA-00600 [kgxgncv1]这类内部错误，甚至实例拒绝启动的情况都可能发生。
• 最后，看一眼日志确认一下：tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log。如果看到Switching to observer mode或者Failed to communicate with reference node这类信息，诊断就基本坐实了。

禁用 NTP 前必须清干净残留

很多修复尝试之所以失败，问题就出在“清理不彻底”。Oracle的判断逻辑非常死板：只要它发现/etc/ntp.conf这个文件存在，就认为NTP服务应该被启用，于是CTSS就必须退居二线。所以，清理工作必须做到位。

• 停服务：systemctl stop ntpd（或者service ntpd stop）。
• 关自启：systemctl disable ntpd，防止重启后服务自动拉起。
• 删配置：rm -f /etc/ntp.conf。这里要特别注意，必须是删除（rm），而不是移动或重命名（mv）。因为即便文件被移走了，只要还在原路径，某些检查机制仍可能认为它存在。
• 删PID文件：rm -f /var/run/ntpd.pid，清理掉可能的进程锁文件。
• 确认无残留：最后用ps -ef | grep ntp检查一下，确保没有ntpd主进程还在运行（只剩下grep自身的进程可以忽略）。

重启 ctssd 并验证 active 状态

清理完NTP的痕迹之后，CTSS并不会自动切换回active模式，需要手动触发一下。

• 执行重启：crsctl stop res ora.ctssd -init && crsctl start res ora.ctssd -init。
• 等待2到3分钟，让服务稳定下来，然后再次运行crsctl check ctss。正常情况下，这时应该返回CTSS is in Active mode，并且会显示一个毫秒级的offset（例如Offset (in msec): 3）。
• 持续观察：建议用watch -n 10 'crsctl check ctss'命令观察10分钟，确认offset的波动稳定在±10毫秒以内，没有出现大幅跳变。
• 如果状态依然显示为observer，那就要警惕了。这通常意味着某个节点漏删了/etc/ntp.conf，或者环境中使用了chronyd（同样需要停用并删除/etc/chrony.conf）。

非要共存 NTP 和 CTSS？那得按 Oracle 规则硬配

有些生产环境，比如金融行业，出于合规要求必须对接统一的中心化NTP服务器。这种情况下，可以让CTSS保持在observer模式，但前提是NTP的配置必须严格遵守Oracle的规则，否则时间漂移照样会发生。

• 在/etc/ntp.conf配置文件中，必须包含这两行：tinker stepout 0 和 disable kernel。
• 在/etc/sysconfig/ntpd文件中，OPTIONS参数里必须带上-x（例如OPTIONS="-x -u ntp:ntp"），这个选项的作用是禁止时间的大步跳变。
• 绝对禁止使用ntpdate或chronyc makestep这类命令进行手动强制校时。它们会造成瞬间超过128秒的时间跳变，会直接导致节点被CTSS“踢出群聊”。
• 验证NTP连通性与状态：运行ntpq -p，在输出中，目标server的行首应该有*（表示主用）或+（表示备用），并且offset值应长期稳定在±5毫秒内。如果频繁出现disp（离散度）大于100，或者reach值为0，那很可能意味着UDP 123端口被防火墙拦截了。

说到底，这类问题的修复，难点从来不在具体的操作命令上，而在于所有节点配置的绝对一致性。少一个-x参数，多一行未被注释的server配置，或者某个节点忘记删除ntp.conf文件，整个集群的时间信任链就会断裂。修复完成后，千万别只看一次检查结果就掉以轻心，至少持续监控crsctl check ctss的输出半小时以上，确保状态真正稳定下来。